http://bugme.osdl.org/show_bug.cgi?id=3294
--- Additional Comments From [EMAIL PROTECTED] 2004-08-28 23:51 ---
this is due to the class stuff that was added incorrectly, we have proper code
in DRM cvs but it needs a blessing from the kernel...
--- You are receiving this mail
Hi.
Jon Smirl wrote:
I can't reproduce this, but I think I found the bug from inspection. In
the vesafb detection code a pointer wasn't set to NULL correctly. I
checked a fix into CVS. Let me know if that didn't fix it.
Yes, it fixed that particular problem, but after rmmoding and
On Sat, Aug 28, 2004 at 04:17:32PM -0700, Jon Smirl wrote:
I'm just starting to look at the bug, but the code involved has been
rewritten in a patch that isn't checked in yet. You might want to give
the new code a try.
Hi Jon - a few comments.
Sam
-
#ifndef MODULE
/** Use an
On Sun, 29 Aug 2004 09:51:41 +0200
Thomas Hellström [EMAIL PROTECTED] wrote:
OK, this means you will have to enable debug info and recompile as
shown in the last post.
Im not sure to which post you refer?
These mailing lists...
Please enable
#define DEBUG_PRINT
#define XV_DEBUG
in
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1220
--- Additional Comments From [EMAIL PROTECTED] 2004-08-29 02:51 ---
My system
Hi all,
I'm just wondering do we have a general feeling from a DRI
perspective on breaking the ATI driver (which is DRI based) from a drm
point of view,
From a kernel POV it isn't an issue, it seems to be an idea to break em
every so often just to keep them on their toes...
but the DRM
Latest Linus kernel has two warnings:
/home/dri/drm-top/linux/radeon_state.c: In function
`radeon_cp_dispatch_texture':
/home/dri/drm-top/linux/radeon_state.c:1444: warning: ignoring return
value of `copy_to_user', declared with attribute warn_unused_result
I'll take care of this one it is
/* if we haven't dma then no need for this control */
if (!(dev-driver_features DRIVER_HAVE_DMA))
return -EINVAL;
Shouldn't this be DRIVER_HAVE_IRQ ?
the old code was
#if __HAVE_IRQ || __HAVE_DMA
[DRM_IOCTL_NR(DRM_IOCTL_CONTROL)] = { DRM(control), 1, 1
},
-
#ifndef MODULE
/** Use an additional macro to avoid preprocessor troubles */
#define DRM_OPTIONS_FUNC DRM(options)
@@ -93,9 +82,6 @@
#undef DRM_OPTIONS_FUNC
#endif
As a general rule - if you need to check for MODULE you are usually
doing something wrong...
I think for 2.4
Dave Airlie wrote:
Hi all,
I'm just wondering do we have a general feeling from a DRI
perspective on breaking the ATI driver (which is DRI based) from a drm
point of view,
From a kernel POV it isn't an issue, it seems to be an idea to break em
every so often just to keep them on their
Why do you feel it will break their code? If it does, they have the option to
either update their driver to match the new code or fork off the old code
continue to use that. I wouldn't be suprised if they've already constructed a
fork at some point, as they seem to have done so for the
Dave Airlie wrote:
Why do you feel it will break their code? If it does, they have the option to
either update their driver to match the new code or fork off the old code
continue to use that. I wouldn't be suprised if they've already constructed a
fork at some point, as they seem to have done
Dave Airlie wrote:
-
#ifndef MODULE
/** Use an additional macro to avoid preprocessor troubles */
#define DRM_OPTIONS_FUNC DRM(options)
@@ -93,9 +82,6 @@
#undef DRM_OPTIONS_FUNC
#endif
As a general rule - if you need to check for MODULE you are usually
doing something wrong...
I think for 2.4
Dave Airlie wrote:
Hi all,
I'm just wondering do we have a general feeling from a DRI
perspective on breaking the ATI driver (which is DRI based) from a drm
point of view,
The ATI proprietary driver *IS* broken right now - I am running FC2,
with X updated from the mainline Xorg CVS, and
David D. Hagood wrote:
Dave Airlie wrote:
Hi all,
I'm just wondering do we have a general feeling from a DRI
perspective on breaking the ATI driver (which is DRI based) from a drm
point of view,
The ATI proprietary driver *IS* broken right now - I am running FC2,
with X updated from the
Keith Whitwell wrote:
Interesting but unlikely to be related to drm changes, first and
...
I hope this thread doesn't start some misconception that these changes
are breaking an existing binary interface - because one doesn't exist!
Though this is precisely my argument against introducing one
David D. Hagood wrote:
Keith Whitwell wrote:
Interesting but unlikely to be related to drm changes, first and
...
I hope this thread doesn't start some misconception that these changes
are breaking an existing binary interface - because one doesn't
exist! Though this is precisely my argument
Am Sonntag, 29. August 2004 17:48 schrieb Dieter Nützel:
Am Sonntag, 29. August 2004 16:54 schrieben Sie:
I'm happy to see this go in. It is probably excessively cautious to keep
it out it's certainly not getting any testing out of the tree.
/opt/Mesa cd src/mesa/drivers/dri/r200/
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1195
--- Additional Comments From [EMAIL PROTECTED] 2004-08-29 11:38 ---
(In reply
Am Sonntag, 29. August 2004 18:03 schrieb Dieter Nützel:
Am Sonntag, 29. August 2004 17:48 schrieb Dieter Nützel:
Am Sonntag, 29. August 2004 16:54 schrieben Sie:
I'm happy to see this go in. It is probably excessively cautious to
keep it out it's certainly not getting any testing out
Coulden't cause DRI/DRM to break on my non-SMP radeon preempt system.
Could this be commited, in one form or another?
cvs diff: Diffing .
Index: drm_os_linux.h
===
RCS file: /cvs/dri/drm/linux/drm_os_linux.h,v
retrieving revision
This change is not going to break a non-SMP system but it may break an
SMP one. This needs to be tested on a SMP system before it can be
committed. I thought the reports were that it breaks on SMP.
--- Mike Mestnik [EMAIL PROTECTED] wrote:
Coulden't cause DRI/DRM to break on my non-SMP radeon
Please do not reply to this email: if you want to comment on the bug, go to
the URL shown below and enter yourcomments there.
https://freedesktop.org/bugzilla/show_bug.cgi?id=1195
[EMAIL PROTECTED] changed:
What|Removed |Added
Dave Airlie wrote:
/home/dri/drm-top/linux/via_dma.c: In function
`via_dispatch_cmdbuffer':
/home/dri/drm-top/linux/via_dma.c:168: warning: ignoring return value
of `copy_from_user', declared with attribute warn_unused_result
Erdi can you fix this one as it is a bug in the via_dma.c
Dave.
Done.
24 matches
Mail list logo
