[Dri-devel] Re:Maybe fixed shared texture object problem
A better patch without whitespace changes...
--- lib/GL/mesa/src/drv/mga/mgatexmem.c Sun Jan 27 12:59:37 2002
+++ lib/GL/mesa/src/drv/mga/mymgatexmem.c Sun Jan 27 13:12:48 2002
@@ -254,8 +254,18 @@
idx != MGA_NR_TEX_REGIONS nr MGA_NR_TEX_REGIONS ;
idx = sarea-texList[heap][idx].prev, nr++)
{
+ /* If switching texturing schemes, then the SAREA might not
+ * have been properly cleared, so we need to reset the
+ * global texture LRU.
+ */
+ if ( idx * sz mmesa-mgaScreen-textureSize[heap] ) {
+ nr = MGA_NR_TEX_REGIONS;
+ break;
+ }
+
if (sarea-texList[heap][idx].age mmesa-texAge[heap]) {
-mgaTexturesGone(mmesa, heap, idx * sz, sz, 1);
+mgaTexturesGone(mmesa, heap, idx * sz, sz,
+sarea-texList[heap][idx].in_use);
}
}
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re:Maybe fixed shared texture object problem
Panagiotis Papadakos wrote:
A better patch without whitespace changes...
--- lib/GL/mesa/src/drv/mga/mgatexmem.c Sun Jan 27 12:59:37 2002
+++ lib/GL/mesa/src/drv/mga/mymgatexmem.c Sun Jan 27 13:12:48 2002
@@ -254,8 +254,18 @@
idx != MGA_NR_TEX_REGIONS nr MGA_NR_TEX_REGIONS ;
idx = sarea-texList[heap][idx].prev, nr++)
{
+ /* If switching texturing schemes, then the SAREA might not
+ * have been properly cleared, so we need to reset the
+ * global texture LRU.
+ */
+ if ( idx * sz mmesa-mgaScreen-textureSize[heap] ) {
+ nr = MGA_NR_TEX_REGIONS;
+ break;
+ }
+
if (sarea-texList[heap][idx].age mmesa-texAge[heap]) {
-mgaTexturesGone(mmesa, heap, idx * sz, sz, 1);
+mgaTexturesGone(mmesa, heap, idx * sz, sz,
+sarea-texList[heap][idx].in_use);
}
}
Thanks for cleaning it up... I'm having real trouble applying some of the
patches I'm getting off the mailing list - I'm not sure if it's me, or what.
What I'm doing is:
- saving the message from netscape (eg to ~/mgapat)
- in a shell, changing directory to xc-trunk/lib/GL/mesa/src/drv/mga
- applying, as in patch ~/mgapat
and what I get is:
[keithw@rover mga]$ patch ~/mgapat
patching file mgatexmem.c
Hunk #1 FAILED at 254.
1 out of 1 hunk FAILED -- saving rejects to file mgatexmem.c.rej
Does your patch apply when you repeat the procedure on your side? Is the
patch against dri cvs trunk, or something else?
Obviously I could apply the changes by hand, but I'd rather know what's going
on with patch.
== Actually, 'patch -l' succeeds, so in this case at least, there's a
whitespace issue somewhere.
Anyway, applied.
Keith
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re:Maybe fixed shared texture object problem
On Son, 2002-01-27 at 13:01, Keith Whitwell wrote: I'm having real trouble applying some of the patches I'm getting off the mailing list - I'm not sure if it's me, or what. What I'm doing is: - saving the message from netscape (eg to ~/mgapat) I bet there's your problem. I sincerely hope you aren't still using Netscape 4.x? :) - in a shell, changing directory to xc-trunk/lib/GL/mesa/src/drv/mga - applying, as in patch ~/mgapat and what I get is: [keithw@rover mga]$ patch ~/mgapat patching file mgatexmem.c Hunk #1 FAILED at 254. 1 out of 1 hunk FAILED -- saving rejects to file mgatexmem.c.rej Anyway, attaching patches instead of pasting them into the body is safer because all sorts of problems can happen when doing the latter. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeonDMA functions
[ I assume you meant to follow up to the list as well ] On Sam, 2002-01-26 at 19:15, Peter Surda wrote: So I looked at the code: pid 0 doesn't exist, and r128 driver seems to be using it for optimizing searches for free buffer. So I added a buf-pid 0 [cut] Further investigations showed r128 and radeon where the only driver that actually did a buf-pending = 1, so I changed it to 0 and now the symptoms aren't ocurring anymore. Your changes sound dangerous. :) You're basically removing the tests for the errors, or am I missing something? The first one definitely wasn't correct. A process of pid 0 doesn't exist, but it has been handled as if it existed. The test ( buf-pid != current-pid ) isn't there for fun. The pid field of the buffer must contain the current process' pid. Looking at r128_freelist_get(), ( buf-pid == 0 ) means the buffer is free, i.e. not supposed to be in use by any process. As for the second one, I too am not sure I'm not breaking something, but it fixed the problem and as I said, r128 and radeon are the only drivers that actually set buf-pending to 1, no other drivers EVER do that. So I'm assuming r128 and radeon were trying to implement something new, but it hasn't been completed and is broken. Obviously _something_ related to it is broken, but does that mean the pending field shouldn't be used at all (which is the effect of your changes AFAICS)? Again looking at r128_freelist_get(), the pending field means that the buffer is currently processed by the hardware. After digging around the code a bit, my current theory is that the indirect buffer is incorrectly reused after the start of a new server generation. The only difference I see in the radeon driver (which I assume doesn't have the same problem?) is in the LeaveServer() function, where it releases the indirect buffer. Can you try if that fixes the problem? Another idea is to set info-indirectBuffer to NULL in R128CCEAccelInit(). Please test these ideas, hope one of them works. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] XAA questions
On Fre, 2002-01-25 at 14:53, Alexander Stohr wrote: 1) The document XAA.HOWTO describes nicely the functionality of the low-level hooks. Where can i find documentation on the mid-level and GC-level hooks and flags? I don't know, and I also think the Xpert list is probably a better place to ask. 2) If i do hook some of the mid-level or GC-level functions, is there any possibility to let the X11 generic routines handle the call if do find out that hardware does not cover a specific case? (I dont want to do duplication of software routines in a driver.) A common X way of doing something like that is to wrap the generic function, i.e. replace the function pointer in a structure and call the replaced function as necessary. Don't know if that applies to your problem though. 3) Does someone know what the define RENDER is intended for? I have seen it used in xaa.h for e.g. CPUToScreenTexture functions (huh, the XServer provides a texture API???), Glyphs and Composite. (Again i havent found documentation on it.) Don't tell me you haven't heard about the RENDER extension. ;) It's about image composition and related things, most popularly anti-aliased text. The mga driver has some acceleration for it, I've been trying to adapt it to the r128 driver but haven't had luck with the Rage128 CCE packets for alpha blending yet. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI-Devel-FAQ update
Dear DRI developers, I've updated the DRI-Devel-FAQ, now in http://jrfonseca.tripod.com/dri/faq/html/ because my server has been down all weekend due to (frustrating) network problems. At this moment the FAQ is pretty close of what I had idealized that it should be. It's still needing some corrections/additions that I'll eventually add but I'll not spend much time with it for a while. I gave my best but I'm a little tired of making documentation -- I need to do something different for a break. I hope now to be able to help in the mach64 development and I look forward to do so. Regards, José Fonseca _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On Sun, Jan 27, 2002 at 06:03:42PM +0100, Michel Dnzer wrote: [ I assume you meant to follow up to the list as well ] yes it is possible I failed to do so. The first one definitely wasn't correct. A process of pid 0 doesn't exist, but it has been handled as if it existed. The test ( buf-pid != current-pid ) isn't there for fun. The pid field of the buffer must contain the current process' pid. Yes, exactly. But this test fails if buf-pid == 0, which is wrong. Hence I added this test. See added, not deleted or replaced Looking at r128_freelist_get(), ( buf-pid == 0 ) means the buffer is free, i.e. not supposed to be in use by any process. Yes thats exactly what I'm talking about, this isn't tested though in other places. Obviously _something_ related to it is broken, but does that mean the pending field shouldn't be used at all Definitely, that's why I said my patch is most probably incorrect, but it solved my problems nevertheless (at least I think so). Basically I am too stupid to fix it correctly so I'm just curing the symptoms. After digging around the code a bit, my current theory is that the indirect buffer is incorrectly reused after the start of a new server generation. I too think this is the most probable cause. The only difference I see in the radeon driver (which I assume doesn't have the same problem?) Well, noone reported it so no idea. is in the LeaveServer() function, where it releases the indirect buffer. Can you try if that fixes the problem? Another idea is to set info-indirectBuffer to NULL in R128CCEAccelInit(). Sounds reasonable, I'll try it. I hope I'll be around on tomorrows irc meeting, we can try stuff in realtime then :-) Please test these ideas, hope one of them works. Sure dude. Bye, Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103, +436505122023 -- 0 and 1. Now what could be so hard about that? msg02553/pgp0.pgp Description: PGP signature
Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On Sun, Jan 27, 2002 at 06:03:42PM +0100, Michel Dnzer wrote:
After digging around the code a bit, my current theory is that the
indirect buffer is incorrectly reused after the start of a new server
generation. The only difference I see in the radeon driver (which I
assume doesn't have the same problem?) is in the LeaveServer() function,
where it releases the indirect buffer. Can you try if that fixes the
problem?
Yes this seems to have fixed it, here's the patch:
--- ati.2/r128_dri.cMon Dec 31 06:00:11 2001
+++ ati.2-shurdeek/r128_dri.c Sun Jan 27 20:50:19 2002
@@ -308,6 +308,9 @@
info-sc_bottom = INREG(R128_SC_BOTTOM);
info-aux_sc_cntl = INREG(R128_SC_BOTTOM);
}
+} else {
+ R128CCEFlushIndirect(pScrn);
+ R128CCEReleaseIndirect(pScrn);
}
}
Would please the responsible person in all projects (dri, xf86, gatos) apply it?
Bye,
Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103, +436505122023
--
The product Microsoft sells isn't the software; it's comfort.
The product that Linux vendors usually sell is freedom.
msg02555/pgp0.pgp
Description: PGP signature
Re: [GATOS]Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On Sun, Jan 27, 2002 at 08:15:29PM -0300, Davor Buvinic wrote: Works for me: ATI Xpert 128, XFree86 4.2.0, your patch against GATOS ATI drivers sources. No more messages in the kernel log like the following: [drm:r128_cce_indirect] *ERROR* process 1668 using buffer owned by 0 Yes this was exactly what it was intended to fix, and several similar errors as well. But if I play a video and run glxgears X crashes. Option UseCCEFor2D didn't appears to help... Hmm I just tried aviplay together with glxgears without crashing (though gears caused aviplay to crawl). What do the logs show? - Davor Mit freundlichen Gren Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103, +436505122023 -- ...and that is how we know the Earth to be banana-shaped. msg02557/pgp0.pgp Description: PGP signature
Re: [Xpert]Re: [GATOS]Re: [Dri-devel] Bugfix for br0ken DMA on r128and possibly radeon DMA functions
On Sun, 27 Jan 2002, Davor Buvinic wrote:
On Sunday 27 January 2002 16:53, you wrote:
On Sun, Jan 27, 2002 at 06:03:42PM +0100, Michel Dänzer wrote:
After digging around the code a bit, my current theory is that the
indirect buffer is incorrectly reused after the start of a new server
generation. The only difference I see in the radeon driver (which I
assume doesn't have the same problem?) is in the LeaveServer() function,
where it releases the indirect buffer. Can you try if that fixes the
problem?
Yes this seems to have fixed it, here's the patch:
--- ati.2/r128_dri.cMon Dec 31 06:00:11 2001
+++ ati.2-shurdeek/r128_dri.c Sun Jan 27 20:50:19 2002
@@ -308,6 +308,9 @@
info-sc_bottom = INREG(R128_SC_BOTTOM);
info-aux_sc_cntl = INREG(R128_SC_BOTTOM);
}
+} else {
+ R128CCEFlushIndirect(pScrn);
+ R128CCEReleaseIndirect(pScrn);
}
}
Would please the responsible person in all projects (dri, xf86, gatos)
apply it?
Bye,
Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103,
+436505122023
Works for me: ATI Xpert 128, XFree86 4.2.0, your patch against GATOS ATI
drivers sources. No more messages in the kernel log like the following:
[drm:r128_cce_indirect] *ERROR* process 1668 using buffer owned by 0
But if I play a video and run glxgears X crashes. Option UseCCEFor2D didn't
appears to help...
Please try latest GATOS CVS - main branch - and let me know if it works
better.
Vladimir Dergachev
- Davor
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [GATOS]Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On Sunday 27 January 2002 20:43, you wrote: On Sun, Jan 27, 2002 at 08:15:29PM -0300, Davor Buvinic wrote: Works for me: ATI Xpert 128, XFree86 4.2.0, your patch against GATOS ATI drivers sources. No more messages in the kernel log like the following: [drm:r128_cce_indirect] *ERROR* process 1668 using buffer owned by 0 Yes this was exactly what it was intended to fix, and several similar errors as well. But if I play a video and run glxgears X crashes. Option UseCCEFor2D didn't appears to help... Hmm I just tried aviplay together with glxgears without crashing (though gears caused aviplay to crawl). What do the logs show? - Davor Mit freundlichen Gren Peter Surda (Shurdeek) [EMAIL PROTECTED], ICQ 10236103, +436505122023 Yes, running glxgears cause the movie player to crawl and if I start to move or resize their windows X crashes. The movie player is MPlayer, today cvs. Here is my log file from X. As you can see, at the end of the file the following messages appears: [...] (II) R128(0): StopVideo (EE) R128(0): Idle timed out, resetting engine... [...] I found some documentation at the DRI website for debugging. I'll see if I can state more precisely the cause of the problem. - Davor --- XFree86 Version 4.2.0 (Unofficial Build: 4.2.0-0.2) / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 23 January 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.18-pre6 i686 [ELF] Build Host: eniac Module Loader present Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/XFree86.0.log, Time: Sun Jan 27 21:34:03 2002 (==) Using config file: /etc/X11/XF86Config-4 (==) ServerLayout Anaconda Configured (**) |--Screen Screen0 (0) (**) | |--Monitor Monitor0 (**) | |--Device ATI Rage 128 (generic) (**) |--Input Device Mouse0 (**) |--Input Device Keyboard0 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel pc105 (**) XKB: model: pc105 (**) Option XkbLayout la (**) XKB: layout: la (==) Keyboard: CustomKeycode disabled (**) FontPath set to unix/:7100 (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (--) using VT number 7 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.5 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.2.0, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.2.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,7190 card , rev 03 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,7191 card , rev 03 class 06,04,00 hdr 01 (II) PCI: 00:07:0: chip 8086,7110 card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:07:1: chip 8086,7111 card , rev 01 class 01,01,80 hdr 00 (II) PCI: 00:07:2: chip 8086,7112 card , rev 01 class 0c,03,00 hdr 00 (II) PCI: 00:07:3: chip 8086,7113 card , rev 02 class 06,80,00 hdr 00 (II) PCI: 00:0d:0: chip 1282,9102 card 4554,434e rev 31 class 02,00,00 hdr 00 (II) PCI: 00:0e:0: chip 9004,5078 card 9004,7850 rev 03 class 01,00,00 hdr 00 (II) PCI: 00:10:0: chip 1102,0002 card 1102,0020 rev 05 class 04,01,00 hdr 80 (II) PCI: 00:10:1: chip 1102,7002 card 1102,0020 rev 05 class 09,80,00 hdr 80 (II) PCI: 01:00:0: chip 1002,5246 card 1002,0008 rev 00 class 03,00,00 hdr 00 (II) PCI: End of PCI scan (II) LoadModule: scanpci (II) Loading /usr/X11R6/lib/modules/libscanpci.a (II) Module scanpci: vendor=The XFree86 Project compiled for 4.2.0, module version = 0.1.0 ABI class: XFree86 Video Driver, version 0.5 (II) UnloadModule: scanpci (II) Unloading /usr/X11R6/lib/modules/libscanpci.a (II) Host-to-PCI bridge: (II) PCI-to-ISA bridge: (II) PCI-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (-1,0,0), BCTRL: 0x08 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0x - 0x (0x1) IX[B] (II) Bus 0 non-prefetchable memory range: [0] -1 0x -
[Dri-devel] chown /dev/dri/card0, system crashes
Hardware: Dell Inspiron 4100, Mobile Pentium III-M 1.0 GHz, Intel 830MP chipset ATI Radeon Mobility LY (AGP), 16 Mb RAM Software: SuSE 7.3, kernel 2.4.16 with devfs, XFree86-4.2.0 (WithPam and WithPamMisc), management by xdm. agpgart.o has two patches, see URL below for details. Symlinks point to libGL.so, libGLcore.a and libglx.a from XFree86-4.2.0. XF86Config excerpt (see URL below for the whole thing): Section Module Load glx Load dri Section Device Driverradeon OptionAGPMode 4 (failure happens with or without 4X AGP) Section DRI Mode 0666 Reference: http://www.math.ucla.edu/~jimc/insp4100/X-setup.html#DRI Complete XFree86.0.log available on request. OpenGL applications successfully use DRI, e.g. glxgears gets 628 fps vs. 220 fps without DRI. I added /dev/dri/card0 to /etc/logindevperm, so xdm would chown-chmod the device to $USER 600 at login, and root 600 when the session ends. Users can log in, but when they log out the system freezes: the screen goes black, you can't switch VTs, and the Magic SysRq Key has no effect. The failure occurs if and only if that line is present in /etc/logindevperm. Having removed the line, I went through the following operations: 1. Check /dev/dri/card0, it's root 666. 2. User logs in using xdm. Still root 666. 3. User runs glxgears. It uses DRI. 4. Switch VTs, chown otheruser /dev/dri/card0, chmod 600 /dev/dri/card0. 5. Change mind, chown root /dev/dri/card0 (no second chmod) 6. Switch Vts, user runs glxgears again. Reports operation not permitted, using slow indirect rendering and runs at 230 fps. 7. Switch VTs, check /dev/dri/card0. IT'S NOT THERE! radeon kernel module is still loaded and has the same access count. Remember this is in devfs. 8. Used the Magic SysRq Key to sync, remount and reboot. I cannot recognize any relevant messages in syslog or in XFree86.0.log. There is one difference in XFree86.0.log between the one covering the above trial and an instance where the bug was not provoked: in the trial, after the usual report about mouse buttons which normally occurs at the end, it [drm] removed 1 reserved context for kernel, unmapped SAREA. Then it opened the DRI device again, seemingly identical to the first time, and [drm] created radeon driver again with identical reservations. It isn't possible to tell what happened when, but the mod date of the file was shortly before I rebooted the machine, not when the server started up. James F. Carter Voice 310 825 2897FAX 310 206 6673 UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555 Email: [EMAIL PROTECTED]http://www.math.ucla.edu/~jimc (q.v. for PGP key) ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Xpert]Re: [GATOS]Re: [Dri-devel] Bugfix for br0ken DMA on r128 and possibly radeon DMA functions
On Sunday 27 January 2002 21:59, you wrote: On Sun, 27 Jan 2002, Davor Buvinic wrote: [...] Works for me: ATI Xpert 128, XFree86 4.2.0, your patch against GATOS ATI drivers sources. No more messages in the kernel log like the following: [drm:r128_cce_indirect] *ERROR* process 1668 using buffer owned by 0 But if I play a video and run glxgears X crashes. Option UseCCEFor2D didn't appears to help... Please try latest GATOS CVS - main branch - and let me know if it works better. Vladimir Dergachev With the latest GATOS CVS - the one with changes from Peter Surda at the files radeon_driver.c, radeon_reg.h, fi1236.c, fi1236.h, msp3430.c, r128_dri.c, theatre.h and theatre_reg.h - the problem (apparently) is the same one that at first: corruption at login screen (xdm, kdm), the messages [drm:r128_cce_indirect] in the kernel log, and X crashes. With only the patch from Peter Surda to the file r128_dri.c no corruption at login screen, no messages in the kernel log but X crash with both mplayer and glxgears running, or only with mplayer after a while playing a video. BTW, which is the appropriate mailing list to discuss this stuff? I think that we're CC: to too many places... At this step we'll finish CC: to the linux kernel mailing list :) - Davor ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
