Re: [Dri-devel] newmesa branch
On Fri, Dec 05, 2003 at 09:06:33AM +, Keith Whitwell wrote: I'll look at at least the r200 and i830 drivers today. Keith, I've done the i830 driver now. I've also moved over the easy parts of the radeon and r200 drivers, but there's some significant changes in some of the vertex handling between what's in the new Mesa trunk code and the DRI trunk code, so if you can oversee that merge that'd be great. There's also the other issue of PRIM_PARITY for the tdfx and ffb drivers. Once the above is done. We're ready to merge to the trunk. Alan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] newmesa branch
Alan Hourihane wrote: On Fri, Dec 05, 2003 at 09:06:33AM +, Keith Whitwell wrote: I'll look at at least the r200 and i830 drivers today. Keith, I've done the i830 driver now. I've also moved over the easy parts of the radeon and r200 drivers, but there's some significant changes in some of the vertex handling between what's in the new Mesa trunk code and the DRI trunk code, so if you can oversee that merge that'd be great. There's also the other issue of PRIM_PARITY for the tdfx and ffb drivers. Once the above is done. We're ready to merge to the trunk. Alan. I'm getting a compile error: make[6]: Entering directory `/home/progs/xc-newtree/lib/GL/mesa/drivers/dri/comm on' rm -f mm.o gcc -m32 -c -O2 -fno-strength-reduce -fno-strict-aliasing -ansi -pedantic -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wredundant-decls -Wnested-externs -Wundef -pipe -g -I../../../../../../expor ts/include/X11 -I../../../../../../include/extensions -I../../../../.. /../lib/GL/dri -I../../../../../../exports/include/X11 -I../../../../../../lib/GL/glx -I../../../../../../lib/GL/include -I../../../../../../programs/Xserver/GL/dri -I../../../../.. /../programs/Xserver/hw/xfree86/os-support -I../../../../../../prog rams/Xserver/hw/xfree86/common -I../../../../../../lib/GL/dri/drm -I../../../../../../lib/GL/include -I../../../../../.. -I../../../../. ./../exports/include -I/home/XF4/xc-newtree/include -Dlinux -D__i386__ -D_POSIX _C_SOURCE=199309L -D_POSIX_SOURCE -D_XOPEN_SOURCE -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS -D_REENTRANT -DXUSE_MTS AFE_API-DMALLOC_0_RETURNS_NULL -DGLXEXT -DXF86DRI -DGLX_DIRECT_RENDERING -DG LX_USE_DLOPEN -DGLX_USE_MESA -DX_BYTE_ORDER=X_LITTLE_ENDIANmm.c mm.c:29:16: mm.h: No such file or directory mm.c:32: parse error before '*' token mm.c:33: warning: function declaration isn't a prototype Keith --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] newmesa branch
Alan Hourihane wrote: On Fri, Dec 05, 2003 at 09:06:33AM +, Keith Whitwell wrote: I'll look at at least the r200 and i830 drivers today. Keith, I've done the i830 driver now. I've also moved over the easy parts of the radeon and r200 drivers, but there's some significant changes in some of the vertex handling between what's in the new Mesa trunk code and the DRI trunk code, so if you can oversee that merge that'd be great. There's also the other issue of PRIM_PARITY for the tdfx and ffb drivers. Once the above is done. We're ready to merge to the trunk. It looks like you're following the XFree86 convention of linking .c files but not .h files, right? Not my favorite arrangement... I'll fix up the PRIM_PARITY code - basically it's no longer needed. Keith --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] newmesa branch
Alan Hourihane wrote: On Fri, Dec 05, 2003 at 09:06:33AM +, Keith Whitwell wrote: I'll look at at least the r200 and i830 drivers today. Keith, I've done the i830 driver now. I've also moved over the easy parts of the radeon and r200 drivers, but there's some significant changes in some of the vertex handling between what's in the new Mesa trunk code and the DRI trunk code, so if you can oversee that merge that'd be great. There's also the other issue of PRIM_PARITY for the tdfx and ffb drivers. Once the above is done. We're ready to merge to the trunk. Also, wondering if there's any reason the lib/GL/mesa/src directory is still populated? Keith --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] newmesa branch
On Mon, Dec 08, 2003 at 12:32:00PM +, Keith Whitwell wrote: Alan Hourihane wrote: On Fri, Dec 05, 2003 at 09:06:33AM +, Keith Whitwell wrote: I'll look at at least the r200 and i830 drivers today. Keith, I've done the i830 driver now. I've also moved over the easy parts of the radeon and r200 drivers, but there's some significant changes in some of the vertex handling between what's in the new Mesa trunk code and the DRI trunk code, so if you can oversee that merge that'd be great. There's also the other issue of PRIM_PARITY for the tdfx and ffb drivers. Once the above is done. We're ready to merge to the trunk. It looks like you're following the XFree86 convention of linking .c files but not .h files, right? Not my favorite arrangement... Not mine either. I think I'll fix that, so it does, otherwise you have to be in both directories to fix things up. I'll fix up the PRIM_PARITY code - basically it's no longer needed. Oh, that easy. O.k. Alan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] newmesa branch
Alan Hourihane wrote: On Mon, Dec 08, 2003 at 12:32:00PM +, Keith Whitwell wrote: Alan Hourihane wrote: On Fri, Dec 05, 2003 at 09:06:33AM +, Keith Whitwell wrote: I'll look at at least the r200 and i830 drivers today. Keith, I've done the i830 driver now. I've also moved over the easy parts of the radeon and r200 drivers, but there's some significant changes in some of the vertex handling between what's in the new Mesa trunk code and the DRI trunk code, so if you can oversee that merge that'd be great. There's also the other issue of PRIM_PARITY for the tdfx and ffb drivers. Once the above is done. We're ready to merge to the trunk. It looks like you're following the XFree86 convention of linking .c files but not .h files, right? Not my favorite arrangement... Not mine either. I think I'll fix that, so it does, otherwise you have to be in both directories to fix things up. Oh - I didn't realize (see my other post...) that there is a choice. XFree86 seems to be quite clear about only linking .c files in the few situations where I've observed any discussion about this. Keith --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] newmesa branch
Keith Whitwell wrote: Alan Hourihane wrote: On Fri, Dec 05, 2003 at 09:06:33AM +, Keith Whitwell wrote: I'll look at at least the r200 and i830 drivers today. Keith, I've done the i830 driver now. I've also moved over the easy parts of the radeon and r200 drivers, but there's some significant changes in some of the vertex handling between what's in the new Mesa trunk code and the DRI trunk code, so if you can oversee that merge that'd be great. There's also the other issue of PRIM_PARITY for the tdfx and ffb drivers. Once the above is done. We're ready to merge to the trunk. It looks like you're following the XFree86 convention of linking .c files but not .h files, right? Not my favorite arrangement... That came across a bit spoilt-brat-ish. I don't doubt that we've got any real choice about the way files are linked as there is the expecation that this will get merged (one day) to XFree86 and that therefore it has to follow their build/coding/etc standards. I personally don't enjoy trying to develop with .c, .o and .h files spread over multiple directories, but the idea behind all this is to get the driver development task out of the DRI tree anyway... Keith --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] newmesa branch
On Mon, Dec 08, 2003 at 12:45:06PM +, Keith Whitwell wrote: Keith Whitwell wrote: Alan Hourihane wrote: On Fri, Dec 05, 2003 at 09:06:33AM +, Keith Whitwell wrote: I'll look at at least the r200 and i830 drivers today. Keith, I've done the i830 driver now. I've also moved over the easy parts of the radeon and r200 drivers, but there's some significant changes in some of the vertex handling between what's in the new Mesa trunk code and the DRI trunk code, so if you can oversee that merge that'd be great. There's also the other issue of PRIM_PARITY for the tdfx and ffb drivers. Once the above is done. We're ready to merge to the trunk. It looks like you're following the XFree86 convention of linking .c files but not .h files, right? Not my favorite arrangement... That came across a bit spoilt-brat-ish. I don't doubt that we've got any real choice about the way files are linked as there is the expecation that this will get merged (one day) to XFree86 and that therefore it has to follow their build/coding/etc standards. I personally don't enjoy trying to develop with .c, .o and .h files spread over multiple directories, but the idea behind all this is to get the driver development task out of the DRI tree anyway... No problem Keith. I totally agree, and was thinking of doing the same thing anyway. I've fixed your build problem and starting linking the .h files now too. Alan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] newmesa branch
On Mon, Dec 08, 2003 at 12:35:35PM +, Keith Whitwell wrote: Alan Hourihane wrote: On Fri, Dec 05, 2003 at 09:06:33AM +, Keith Whitwell wrote: I'll look at at least the r200 and i830 drivers today. Keith, I've done the i830 driver now. I've also moved over the easy parts of the radeon and r200 drivers, but there's some significant changes in some of the vertex handling between what's in the new Mesa trunk code and the DRI trunk code, so if you can oversee that merge that'd be great. There's also the other issue of PRIM_PARITY for the tdfx and ffb drivers. Once the above is done. We're ready to merge to the trunk. Also, wondering if there's any reason the lib/GL/mesa/src directory is still populated? It's all gone, bar the references to lib/GL/mesa/src/drv/tdfx/X86/... which was holding all that stuff open. Doing a 'cvs update -d -P' should remove your empty directories. Alan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] newmesa branch
On Mon, Dec 08, 2003 at 12:46:36PM +, Keith Whitwell wrote: Alan Hourihane wrote: On Mon, Dec 08, 2003 at 12:32:00PM +, Keith Whitwell wrote: Alan Hourihane wrote: On Fri, Dec 05, 2003 at 09:06:33AM +, Keith Whitwell wrote: I'll look at at least the r200 and i830 drivers today. Keith, I've done the i830 driver now. I've also moved over the easy parts of the radeon and r200 drivers, but there's some significant changes in some of the vertex handling between what's in the new Mesa trunk code and the DRI trunk code, so if you can oversee that merge that'd be great. There's also the other issue of PRIM_PARITY for the tdfx and ffb drivers. Once the above is done. We're ready to merge to the trunk. It looks like you're following the XFree86 convention of linking .c files but not .h files, right? Not my favorite arrangement... Not mine either. I think I'll fix that, so it does, otherwise you have to be in both directories to fix things up. Oh - I didn't realize (see my other post...) that there is a choice. XFree86 seems to be quite clear about only linking .c files in the few situations where I've observed any discussion about this. There has always been a choice. I guess it's been dependent on the person who did the work. I've never seen prejudice against doing it either way. Look at libGLU in the XFree86 tree... The Imakefiles do link their include counterparts. Alan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 08:19 --- The Patch http://bugs.xfree86.org/attachment.cgi?id=723action=view with XFree-4.3.99.16 works fine, thank you. Then I get this in /var/log/XFree86.0.log: drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmGetBusid returned '' But now tried to patch XFree86-4.3.99.901 with http://bugs.xfree86.org/attachment.cgi?id=862action=view but I get no 3D. The log with 4.3.99.901 shows that drmOpenDevice fails: drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is -1, (No such device) drmOpenDevice: open result is -1, (No such device) drmOpenDevice: Open failed and so on At the patching one hunk in lib/GL/mesa/src/drv/r200/radeon_screen.c fails. I have a Radeon IGP 320M chip. Thomas Riedel -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: pbuffers, extensions to DRM
On Sat, 2003-12-06 at 19:25, Keith Whitwell wrote: Why doesn't the DRM module just send a signal on retrace? It can, you just have to tell it to. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Another compile error
Failing to compile dispatch.c in programs/Xserver/GL/mesa/main... This one looks like it is caused by the recent change to gl.h to include stddef.h in order to provide a definition for ptrdiff_t. Unfortunatly, in whacky-xfree86-world, including headers like that will lead to trouble, and what's required is to include xf86_libc.h or nothing at all. I've included a patch for this... But... unfortunately this means that we don't get the ptrdiff_t definition... So, that means that somewhere in maybe os-support/xf86_libc.h? we need something like: # define ptrdiff_t int The other option would be to change gl.h and glext.h to use int or GLint instead of ptrdiff_t... Keith Index: gl.h === RCS file: /cvsroot/mesa3d/Mesa-newtree/include/GL/gl.h,v retrieving revision 1.94 diff -u -r1.94 gl.h --- gl.h6 Dec 2003 01:49:54 - 1.94 +++ gl.h8 Dec 2003 14:36:08 - @@ -38,7 +38,9 @@ */ #if !defined(__SCITECH_SNAP__) +#ifndef XFree86Server #include stddef.h /* to get ptrdiff_t, used below */ +#endif #if defined(__BEOS__) #include stdlib.h /* to get some BeOS-isms */ Index: glext.h === RCS file: /cvsroot/mesa3d/Mesa-newtree/include/GL/glext.h,v retrieving revision 1.53 diff -u -r1.53 glext.h --- glext.h 30 Sep 2003 20:02:27 - 1.53 +++ glext.h 8 Dec 2003 14:36:09 - @@ -3290,7 +3290,9 @@ #define GL_ARB_vertex_buffer_object 1 /* GL types for handling large vertex buffer objects */ /* Only used by this extension for now; later needs to be moved earlier in glext.h */ +#ifndef XFree86Server #include stddef.h +#endif typedef ptrdiff_t GLintptrARB; typedef ptrdiff_t GLsizeiptrARB; #ifdef GL_GLEXT_PROTOTYPES --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 946] GL_NV_texture_rectangle ext is broken when dri is enabled
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=946 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |dri- ||[EMAIL PROTECTED] Component|Mesa|ATI Radeon OS/Version|Linux |All Product|XFree86 Server |Drivers --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 10:00 --- Define 'does not work'. Isn't rather the YUV extension broken? (try texrect instead of yuvrect) -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Another compile error
On Mon, Dec 08, 2003 at 02:45:30PM +, Keith Whitwell wrote: Failing to compile dispatch.c in programs/Xserver/GL/mesa/main... This one looks like it is caused by the recent change to gl.h to include stddef.h in order to provide a definition for ptrdiff_t. Unfortunatly, in whacky-xfree86-world, including headers like that will lead to trouble, and what's required is to include xf86_libc.h or nothing at all. I've included a patch for this... But... unfortunately this means that we don't get the ptrdiff_t definition... So, that means that somewhere in maybe os-support/xf86_libc.h? we need something like: # define ptrdiff_t int The other option would be to change gl.h and glext.h to use int or GLint instead of ptrdiff_t... Actually, I came up with this that I didn't commit (as I forgot about it).. I've sent an email to David to double check this is o.k. unless he has another approach. Alan. Index: programs/Xserver/hw/xfree86/os-support/xf86_libc.h === RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/xf86_libc.h,v retrieving revision 1.16 diff -u -r1.16 xf86_libc.h --- programs/Xserver/hw/xfree86/os-support/xf86_libc.h 12 Sep 2003 19:39:06 - 1.16 +++ programs/Xserver/hw/xfree86/os-support/xf86_libc.h 8 Dec 2003 14:58:42 - @@ -80,7 +80,11 @@ }; typedef struct _xf86dirent XF86DIRENT; +#if !(defined (__GNUG__) defined (size_t)) +typedef unsigned int xf86size_t; +#else typedef unsigned long xf86size_t; +#endif typedef signed long xf86ssize_t; typedef unsigned long xf86dev_t; typedef unsigned int xf86mode_t; --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Another compile error
OK, Alan - that looks like a better fix than my patch. When this goes in, we can remove the XFree86Server checks from gl.h and glext.h. Keith Alan Hourihane wrote: On Mon, Dec 08, 2003 at 02:45:30PM +, Keith Whitwell wrote: Failing to compile dispatch.c in programs/Xserver/GL/mesa/main... This one looks like it is caused by the recent change to gl.h to include stddef.h in order to provide a definition for ptrdiff_t. Unfortunatly, in whacky-xfree86-world, including headers like that will lead to trouble, and what's required is to include xf86_libc.h or nothing at all. I've included a patch for this... But... unfortunately this means that we don't get the ptrdiff_t definition... So, that means that somewhere in maybe os-support/xf86_libc.h? we need something like: # define ptrdiff_t int The other option would be to change gl.h and glext.h to use int or GLint instead of ptrdiff_t... Actually, I came up with this that I didn't commit (as I forgot about it).. I've sent an email to David to double check this is o.k. unless he has another approach. Alan. Index: programs/Xserver/hw/xfree86/os-support/xf86_libc.h === RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/xf86_libc.h,v retrieving revision 1.16 diff -u -r1.16 xf86_libc.h --- programs/Xserver/hw/xfree86/os-support/xf86_libc.h 12 Sep 2003 19:39:06 - 1.16 +++ programs/Xserver/hw/xfree86/os-support/xf86_libc.h 8 Dec 2003 14:58:42 - @@ -80,7 +80,11 @@ }; typedef struct _xf86dirent XF86DIRENT; +#if !(defined (__GNUG__) defined (size_t)) +typedef unsigned int xf86size_t; +#else typedef unsigned long xf86size_t; +#endif typedef signed long xf86ssize_t; typedef unsigned long xf86dev_t; typedef unsigned int xf86mode_t; --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Another compile error
On Mon, Dec 08, 2003 at 03:17:22PM +, Keith Whitwell wrote: OK, Alan - that looks like a better fix than my patch. When this goes in, we can remove the XFree86Server checks from gl.h and glext.h. O.k. Here's a slighly modified version that I'll hope to commit soon. Alan. Index: xf86_libc.h === RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/xf86_libc.h,v retrieving revision 1.16 diff -u -r1.16 xf86_libc.h --- xf86_libc.h 12 Sep 2003 19:39:06 - 1.16 +++ xf86_libc.h 8 Dec 2003 15:25:14 - @@ -80,7 +80,14 @@ }; typedef struct _xf86dirent XF86DIRENT; +#if !(defined (__GNUG__) defined (size_t)) +#ifndef __SIZE_TYPE__ +#define __SIZE_TYPE__ long unsigned int +#endif +typedef __SIZE_TYPE__ xf86size_t; +#else typedef unsigned long xf86size_t; +#endif typedef signed long xf86ssize_t; typedef unsigned long xf86dev_t; typedef unsigned int xf86mode_t; --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Another compile error
Alan, Does this actually address the issue - ie. how does this fit in with ptrdiff_t? Keith Index: programs/Xserver/hw/xfree86/os-support/xf86_libc.h === RCS file: /cvs/dri/xc/xc/programs/Xserver/hw/xfree86/os-support/xf86_libc.h,v retrieving revision 1.16 diff -u -r1.16 xf86_libc.h --- programs/Xserver/hw/xfree86/os-support/xf86_libc.h 12 Sep 2003 19:39:06 - 1.16 +++ programs/Xserver/hw/xfree86/os-support/xf86_libc.h 8 Dec 2003 14:58:42 - @@ -80,7 +80,11 @@ }; typedef struct _xf86dirent XF86DIRENT; +#if !(defined (__GNUG__) defined (size_t)) +typedef unsigned int xf86size_t; +#else typedef unsigned long xf86size_t; +#endif typedef signed long xf86ssize_t; typedef unsigned long xf86dev_t; typedef unsigned int xf86mode_t; --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Another compile error
On Mon, Dec 08, 2003 at 03:32:12PM +, Keith Whitwell wrote: Alan, Does this actually address the issue - ie. how does this fit in with ptrdiff_t? For me, it's not ptrdiff_t that's the problem. It's size_t. What's the compile error your getting ? This is what I'm getting when compiling dispatch.c In file included from /X11R6/SourceForge/Mesanew/Mesa-newtree/include/GL/gl.h:41, from glheader.h:200, from dispatch.c:38: /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include/stddef.h:213: conflicting types for `xf86size_t' ./../../../../programs/Xserver/include/xf86_libc.h:83: previous declaration of `xf86size_t' Alan. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Another compile error
Alan Hourihane wrote: On Mon, Dec 08, 2003 at 03:32:12PM +, Keith Whitwell wrote: Alan, Does this actually address the issue - ie. how does this fit in with ptrdiff_t? For me, it's not ptrdiff_t that's the problem. It's size_t. What's the compile error your getting ? This is what I'm getting when compiling dispatch.c In file included from /X11R6/SourceForge/Mesanew/Mesa-newtree/include/GL/gl.h:41, from glheader.h:200, from dispatch.c:38: /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/include/stddef.h:213: conflicting types for `xf86size_t' ./../../../../programs/Xserver/include/xf86_libc.h:83: previous declaration of `xf86size_t' Ah, OK. Once I resolved this problem (by not including stddef.h from gl.h or glext.h), I ran into a further problem that ptrdiff_t isn't defined. So I guess you avoid the first problem in a way that still allows you to include stddef.h, but avoid the duplicated definition of size_t. That makes sense. Keith --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 819] accelerated 3d is not working for my Radeon 8500
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=819 [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|dri-|[EMAIL PROTECTED] |[EMAIL PROTECTED] | Summary||accelerated 3d is not ||working for my Radeon 8500 --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 11:11 --- Assigning to reporter for comment. (mmm, seems as though the summary went missing here too, readding a new one) -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 11:28 --- (In reply to comment #231) Created an attachment (id=862) -- (http://bugs.xfree86.org/attachment.cgi?id=862action=view) This one actually works There was another bug in 861; this one compiles and X starts up (no further testing done yet) This patch (862) does not work on an IGP320M. The screen initialize but the freezes the complete machine very hard. The first 100 lines or so get really distorted while the rest seems to be OK. Patch 723 worked OK here. Also dri_cvs with latest patch works fine. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 98] 3D object surfaces 'randomly' render red
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=98 [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 11:33 --- This bug still exists in DRI CVS and XFree86 CVS. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] __driConfigOptions, __driNConfigOptions
Is there any reason why these things are extern references rather than parameters to an initialization function? Basically by making them extern references, it means that the files cannot be compiled into a driver which doesn't use them - I guess this is the reason behind the recent rework of common/Imakefile.inc. It also means that you can't have two drivers for two different cards loaded in simultaneously, making hw-accelerated multihead impossible. Plus it's also just odd. Why aren't they parameters? Keith --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] __driConfigOptions, __driNConfigOptions
Keith Whitwell wrote: Is there any reason why these things are extern references rather than parameters to an initialization function? Basically by making them extern references, it means that the files cannot be compiled into a driver which doesn't use them - I guess this is the reason behind the recent rework of common/Imakefile.inc. It also means that you can't have two drivers for two different cards loaded in simultaneously, making hw-accelerated multihead impossible. This is of course not true. I'm grumpy today. But I would prefer not to have the circular situation of the driver referring to symbols in common/ and to have common/ referring back to symbols defined in the driver. Keith --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Another compile error
Keith Whitwell wrote: Failing to compile dispatch.c in programs/Xserver/GL/mesa/main... This one looks like it is caused by the recent change to gl.h to include stddef.h in order to provide a definition for ptrdiff_t. Unfortunatly, in whacky-xfree86-world, including headers like that will lead to trouble, and what's required is to include xf86_libc.h or nothing at all. I've included a patch for this... But... unfortunately this means that we don't get the ptrdiff_t definition... So, that means that somewhere in maybe os-support/xf86_libc.h? we need something like: # define ptrdiff_t int The other option would be to change gl.h and glext.h to use int or GLint instead of ptrdiff_t... Even though ptrdiff_t ended up being used in glext.h, the intention of the ARB_vao working group was that GLintptr be the same as intptr_t. If stdint.h or inttypes.h is available, one of those could be included and intptr_t be used. I think that would be the preferable forward-looking way to do it. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 946] GL_NV_texture_rectangle ext is broken when dri is enabled
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=946 --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 12:12 --- (In reply to comment #1) Define 'does not work'. I will try to attach some images soon. Isn't rather the YUV extension broken? (try texrect instead of yuvrect) I tested texrect too and it does not work too. One image (../images/reflect.rgb) is ok, it has a pot size. The other image (../images/girl.rgb) has a npot size and the resulting texture is corrupted. I mention the yuvrect because the animation of the texrect is so fast that you see almost nothing (I set animation to 0 afterward). Note that (after reading the dri-devel mailing list archive) I've tested various tex coordinate remap (usual 2D tex coor and using 1/w and 1/h in the place of w and h) but I get no success. Regards, Olivier -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 946] GL_NV_texture_rectangle ext is broken when dri is enabled
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=946 --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 12:16 --- Created an attachment (id=876) -- (http://bugs.xfree86.org/attachment.cgi?id=876action=view) ScreenShoot of texrect from Mesa-newtree cvs -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 946] GL_NV_texture_rectangle ext is broken when dri is enabled
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=946 --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 12:19 --- Created an attachment (id=877) -- (http://bugs.xfree86.org/attachment.cgi?id=877action=view) screenshoot of yuvrect from Messa-newtree cvs -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] __driConfigOptions, __driNConfigOptions
Keith Whitwell wrote: Keith Whitwell wrote: Is there any reason why these things are extern references rather than parameters to an initialization function? Basically by making them extern references, it means that the files cannot be compiled into a driver which doesn't use them - I guess this is the reason behind the recent rework of common/Imakefile.inc. It also means that you can't have two drivers for two different cards loaded in simultaneously, making hw-accelerated multihead impossible. This is of course not true. I'm grumpy today. But I would prefer not to have the circular situation of the driver referring to symbols in common/ and to have common/ referring back to symbols defined in the driver. Felix would be able to answer better, but I believe the reason was so that the config utility could load the *_dri.so and get the list of options for that driver. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] S3 Twister
Hi! I've got a notebook with S3 TwisterK, I'd like to use Linux, but only with hardware opengl support. I'd like to ask, that will next DRI driver package have ProSavage and Twister support? If not, when will have? Many Thanks! Bye! Antoine Trifonov --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 14:26 --- Hi. Can someone still exp[lain to me what to do if i get the message that it cannot find a kernel config file after i run make -f Makefile.linux radeon.o? I have the IGP 340M. Im still new to Linux as I said earlier, so if someone could just tell me what command to type to get it all working correctly? I'm using Fedora Core 1. Much appreciated, Michael. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Weekly IRC meeting reminder
This is just a friendly reminder that the weekly dri-devel IRC meeting will be starting in the #dri-devel channel on irc.freenode.net at 2100 UTC (or 4:00PM EST or 1:00PM PST, if you prefer). Time zone conversion available at: http://www.timezoneconverter.com/cgi-bin/tzc.tzc Logs of previous IRC meetings are available at: http://dri.sourceforge.net/IRC-logs/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] S3 Twister
S3/VIA released a code drop a while back for xfree86 4.2.0. it needs to be ported to mesa 5.x to work with newer versions of xfree86. that work is being done on a branch of DRI cvs. for now if you want HW 3D you will need to use 4.2.0 with s3's code drop. see these pages for more info: http://moh.oxiq.org/acer_aspire1300/index.php?p=xf86 http://dri.sourceforge.net/cgi-bin/moin.cgi/S3Savage Alex --- TA [EMAIL PROTECTED] wrote: Hi! I've got a notebook with S3 TwisterK, I'd like to use Linux, but only with hardware opengl support. I'd like to ask, that will next DRI driver package have ProSavage and Twister support? If not, when will have? Many Thanks! Bye! Antoine Trifonov __ Do you Yahoo!? New Yahoo! Photos - easier uploading and sharing. http://photos.yahoo.com/ --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 14:34 --- you need to have a copy of the kernel source available so that the kernel module can be built (it needs to know how you've configured the kernel and some of the headers). if you are using an custom kernel you need a copy of your source in /usr/src/linux or if you are using an rpm based distro, you need to install the kernel source code rpm. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 --- Additional Comments From [EMAIL PROTECTED] 2003-12-08 16:34 --- (In reply to comment #239) (In reply to comment #231) Created an attachment (id=862) -- (http://bugs.xfree86.org/attachment.cgi?id=862action=view) This one actually works There was another bug in 861; this one compiles and X starts up (no further testing done yet) This patch (862) does not work on an IGP320M. The screen initialize but the freezes the complete machine very hard. The first 100 lines or so get really distorted while the rest seems to be OK. Patch 723 worked OK here. Also dri_cvs with latest patch works fine. I also have IGP 320M. 4.3.99.16 - patch succeeded but compile failed 4.3.99.901 - patch succeeded, compile succeeded. Module can be inserted into kernel, XFree works but dri does not work. Also, if I try glxgears I get a segmentation fault. Happy to provide more information if requested. -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 314] 3D support for Radeon IGP chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=314 [EMAIL PROTECTED] changed: What|Removed |Added Attachment #861 is|0 |1 obsolete|| -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] __driConfigOptions, __driNConfigOptions
Am 08.12.2003 18:57:14 schrieb(en) Ian Romanick: Keith Whitwell wrote: Keith Whitwell wrote: Is there any reason why these things are extern references rather than parameters to an initialization function? Basically by making them extern references, it means that the files cannot be compiled into a driver which doesn't use them - I guess this is the reason behind the recent rework of common/Imakefile.inc. It also means that you can't have two drivers for two different cards loaded in simultaneously, making hw-accelerated multihead impossible. This is of course not true. I'm grumpy today. But I would prefer not to have the circular situation of the driver referring to symbols in common/ and to have common/ referring back to symbols defined in the driver. Felix would be able to answer better, but I believe the reason was so that the config utility could load the *_dri.so and get the list of options for that driver. Precisely. I forgot that myself for a moment. Anyway, it was specified that way in all the revisions of the design document and noone complained. ;-) So for the config tool they need to be external symbols somewhere in the drivers. We could still specify them as parameters to driParseOptionInfo to get rid of the dependency of common code on driver-specific stuff. However, the bigger problem is that you need to link with libexpat if you link with xmlconfig.o. I don't think we want that in drivers that don't use config (yet), after all the trouble people had with it. Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] __driConfigOptions, __driNConfigOptions
Am 08.12.2003 22:41:40 schrieb(en) Felix Kühling: Am 08.12.2003 18:57:14 schrieb(en) Ian Romanick: [snip] Felix would be able to answer better, but I believe the reason was so that the config utility could load the *_dri.so and get the list of options for that driver. Precisely. I forgot that myself for a moment. Anyway, it was specified that way in all the revisions of the design document and noone complained. ;-) So for the config tool they need to be external symbols somewhere in the drivers. We could still specify them as parameters to driParseOptionInfo to get rid of the dependency of common code on driver-specific stuff. However, the bigger problem is that you need to link with libexpat if you link with xmlconfig.o. I don't think we want that in drivers that don't use config (yet), after all the trouble people had with it. Ok, Alan just took care of the libexpat problem. :) I'm going to fix the rest soon. Regards, Felix __\|/_____ ___ - Felix ___\_e -_/___/ __\___/ __\_ You can do anything, Kühling (_\Ä// /_/ /) just not everything [EMAIL PROTECTED] \___/ \___/ Uat the same time. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: pbuffers, extensions to DRM
On Sat, 2003-12-06 at 23:24, Jon Smirl wrote: 3) FB memory allocators. Not sure these should go into the DRM system. It might be better to put this into the library with init/mode support. Mesa would need to be modified to use these allocation routines. On the other hand these might be better inside the DRM driver. Future hardware may not allow direct access to the framebuffer. I think at least the core of it definitely has to be in the kernel for enforceability, cleanup on process death etc. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Bug 788] DRI lockup on Radeon chips
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter your comments there. http://bugs.xfree86.org/show_bug.cgi?id=788 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] -- Configure bugmail: http://bugs.xfree86.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: pbuffers, extensions to DRM
My current thinking on this is to do it the DRM driver but store the allocation
data in normal system RAM. This would allow the allocation routines to function
without touching the framebuffer.
I would really like to make sure that DRM drivers can function without having to
map the framebuffer into kernel address space. We only have 1GB of kernel
address space to work with and the kernel has to live in that 1GB too. 3dlabs is
shipping a 512MB card now:
http://www.3dlabs.com/product/wildcatvp/vppro/index.htm and a 1GB model is in
the works. It is just going to be impossible to map these future cards into the
kernel.
In my earlier mail I proposed that DRM drivers automatically addmap the
registers and framebuffer. At the end of add map it ioremaps the memory:
switch ( map-type ) {
case _DRM_REGISTERS:
case _DRM_FRAME_BUFFER:
#if !defined(__sparc__) !defined(__alpha__)
if ( map-offset + map-size map-offset ||
map-offset virt_to_phys(high_memory) ) {
DRM(free)( map, sizeof(*map), DRM_MEM_MAPS );
return -EINVAL;
}
#endif
#ifdef __alpha__
map-offset += dev-hose-mem_space-start;
#endif
#if __REALLY_HAVE_MTRR
if ( map-type == _DRM_FRAME_BUFFER ||
(map-flags _DRM_WRITE_COMBINING) ) {
map-mtrr = mtrr_add( map-offset, map-size,
MTRR_TYPE_WRCOMB, 1 );
}
#endif
map-handle = DRM(ioremap)( map-offset, map-size, dev );
printk(KERN_ERR Mapping: %lx handle: %p\n, map-offset, map-handle);
break;
DRM drivers need the registers mapped but I don't think they need the
framebuffer mapped. The auto addmap would eliminate the need for an IOCTL to
return the physical address of the registers/fb. Auto addmap would add the map
entry but not do the ioremap of the framebuffer.
I've also been poking around a little in the radeon DRM driver. It seems to be
mapping the framebuffer into kernel space but I never see any place that the
driver code touches it.
--- Michel Dänzer [EMAIL PROTECTED] wrote:
On Sat, 2003-12-06 at 23:24, Jon Smirl wrote:
3) FB memory allocators. Not sure these should go into the DRM system. It
might
be better to put this into the library with init/mode support. Mesa would
need
to be modified to use these allocation routines. On the other hand these
might
be better inside the DRM driver. Future hardware may not allow direct access
to
the framebuffer.
I think at least the core of it definitely has to be in the kernel for
enforceability, cleanup on process death etc.
--
Earthling Michel Dänzer | Debian (powerpc), X and DRI developer
Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer
___
Xserver mailing list
[EMAIL PROTECTED]
http://pdx.freedesktop.org/cgi-bin/mailman/listinfo/xserver
=
Jon Smirl
[EMAIL PROTECTED]
__
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: pbuffers, extensions to DRM
--- Michel Dänzer [EMAIL PROTECTED] wrote: I think at least the core of it definitely has to be in the kernel for enforceability, cleanup on process death etc. You're and expert on the radeon driver, want to help code this up? I'm still bogged down with the mode code and making the VM86 work right. -- Earthling Michel Dänzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer = Jon Smirl [EMAIL PROTECTED] __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278alloc_id=3371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64-0-0-6-branch dri bug report
On Sun, 2003-12-07 at 18:43, Jos Fonseca wrote: On Thu, Dec 04, 2003 at 05:02:17PM -0500, Christopher Gleba wrote: It turns out that I mis-configured lilo and when I rebooted a kernel with the software suspend patch was being booted rather then a clean one as I had thought (and I *knew* that swsusp causes problems with video cards). When I booted with a clean kernel, mach64 drm worked fine (and I got 270fps with glxgears rather then the ususal 110fps :)). [...] Nonetheless, I've included the debug output, the agpgart source with the software suspend patch added as well as without it and the software suspend patch itself for both the list archives in case anyone else runs into this problem. Also, I know that 2.6.0+ uses software suspend, so the debugging information below may help when it comes time for a 2.6 port. Thanks for the info. I don't know whose's fault is that sw suspend doesn't work with mach64 dri (it could be sw suspend patch, mach64 drm, or the agpgart). I know that radeon driver has suspend/resume support, but I think it's for hardware suspend. No, it's also for software suspend (Charl wrote it to be able to use that), but it only has an effect for a suspend/resume cycle while the server is running; it's weird that the mere fact that the kernel is patched for software suspend should have an effect on DRI initialisation. -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] radeon 9000 and latest CVS produce freezes on dual opteron system with 1 GL app using texturing.
On Fri, 2003-12-05 at 00:24, [EMAIL PROTECTED] wrote: I am trying to get a Radeon 9000 pro to work using the latest DRI CVS tree, but encountering a few problems. The system in question is a pair of opterons running on a Tyan S2885 board, with Suse 9.0 Professional (AMD64) installed and the latest 2.4.21-149 kernel. I get the same results whether building/installing the whole tree, or building/installing just the radeon.o module. After manually modprobing agpgart, and starting X, glxinfo reports that direct rendering is enabled, and I can run either multiple GL apps or instances of apps that do not use textures (like glxgears, or bubble3d from the xscreensaver modules), or a single instance of a GL app that uses textures. Attempting to run more than one GL app with at least one of the apps using textures results in the apps freezing up, and the keyboard locking. The mouse cursor still responds, but not the buttons. If you have network access to the box, and you can still log in after this happens, which process hogs the CPU, and what happens when you kill it? -- Earthling Michel Dnzer | Debian (powerpc), X and DRI developer Software libre enthusiast| http://svcs.affero.net/rm.php?r=daenzer --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
