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.
--
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
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 radeo
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 1.2
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 test
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 t
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/
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 ag
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 i
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 mainli
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 ju
Dave Airlie wrote:
It should be possible to avoid the whole DRM(fff) thing using linker
directives to designate what symbols are exported from the final drm_xyz.o
object, in the same way that static symbols don't get exported from individual
object files.
I've thought this myself and mean to inves
>
> It should be possible to avoid the whole DRM(fff) thing using linker
> directives to designate what symbols are exported from the final drm_xyz.o
> object, in the same way that static symbols don't get exported from individual
> object files.
>
I've thought this myself and mean to investigate
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 comp
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
>
> 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 th
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 toes.
> > -
> > #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...
>/* 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
> 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
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
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 s
> 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
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
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
mod
25 matches
Mail list logo
