[Dri-devel] Re: Re: Downloadable Radeon Driver and libGL compatability
On Fri, 8 Mar 2002, Jens Owen wrote: I've moved this field to the end of the structure and the libGL.so compatability issue appears to be fixed. Hmmm, that might be good enough, but I'm not 100% certain. I'm worried that my hack of moving it to the end could possibly end up writing over the end of the structure allocation. So, I'd like to try your suggested fix of using the currentDrawable fied. Wasn't this stuff recently submitted to the DRI trunk? Maybe we can fix this incompatability if this hasn't propogated out to any major distros, yet. Yes, we should really fix it ASAP. Was this part of Mesa 4? So this wouldn't have gone out in XFree86 4.2 or any other source releases where we care about binary compatability, right? The latest official releases of X we've shipped are 4.1.0 with Mesa 3.4.2, so whatever you change is not likely to affect us. I've looked through several other mainstream distros, and I do not believe anyone has shipped anything yet in an official capacity using Mesa 4.0, XFree86 4.2.0. You may want to contact other distro maintainers perhaps however. It would be nice if this can be fixed the proper way as you recommend, if possible. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Mach64 DMA
On Monday 11 March 2002 01:55, Frank C. Earl wrote: On Sunday 10 March 2002 11:44 am, Jos? Fonseca wrote: I really don't know much about that, since it must happened before I subscribed to this mailing list, but perhaps you'll want to take a look to the Utah-GLX and this list archives. You can get these archives in mbox format and also filtered with just the messages regarding mach64 at http://mefriss1.swan.ac.uk/~jfonseca/dri/mailing-lists/ The problem was that the XAA driver for mach64 was setting the FIFO size up for some reason and it was leaving the chip in a state that wouldn't work for the DMA mode. If we set the size back to the default setting before we do the first DMA pass, everybody's happy. I suspect if we got with the developer of the XAA driver we can sell him on leaving that setting alone in the driver's setup. Sorry for being silent for so long gang. Been, yet again, crushed under with lovely personal business. I have started a new branch (mach64-0-0-3-dma-branch), and I'm actually putting the hacks I've been playing with into a unified DMA framework. I should be putting the first updates to the branch in over the next couple of days. Of note, when I did find some spare time, I ran tests on what we needed to do to secure the chip's DMA path. I found out some interesting facts. It will accept any values written to the registers. It will not act on any of those settings during the DMA pass unless they're a GUI specific operation when it's doing a command-type DMA. It will not act on many of the settings after a DMA pass is complete. It will not let you set up any sort of DMA pass during the operation. Junk commands, by themselves, do not seem to hose up the engine in operation. Mapping and unmapping a memory space is somewhat compute intensive. Thanks Frank, this was just what I was after... ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] First cut at downloadable Radeon TCL driver suite
From: Jens Owen [EMAIL PROTECTED] I am now using your recent Radeon driver binaries located in radeon-20020309-i386-Linux.tar.gz. Try exporting RADEON_NO_VTXFMT=1 or RADEON_NO_TCL=1 and see if that makes a difference. RADEON_NO_VTXFMT=1 only: http://document.ihg.uni-duisburg.de/Radeon/Radeon04.png RADEON_NO_TCL=1 only: http://document.ihg.uni-duisburg.de/Radeon/Radeon05.png None of both: http://document.ihg.uni-duisburg.de/Radeon/Radeon06.png Both: http://document.ihg.uni-duisburg.de/Radeon/Radeon07.png I'm placing a ready to run binary package on: http://document.ihg.uni-duisburg.de/Radeon/FlightGear-20020311.tar.gz It will appear there in about half an hour. You may skip /usr/local/lib/ and /usr/local/lib/, it's only for building the stuff. The binary is statically linked against libmk4. You should place .fgfsrc into you home directory. If you encounter difficulties with shared libraries (libglut, libstdc++) then I will create a static binary which avoids using these libraries, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] First cut at downloadable Radeon TCL driver suite
I'm placing a ready to run binary package on: Sorry, forgot two things: - The binary you want to run is /usr/local/FlightGear/bin/fgfs - Yes, you really _need_ all that stuff in /home/fgfsbase (or put it elsewhere and change the location in ~/.fgfsrc), Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] mach64 binaries: do not work
Hi all There are problems with the bleeding edge binaries: 1. First of all, the kernel module cannot be loaded because of some unresolved symbols. And even when I do rm *.o, make, the resulting mach64.o has some unresolved symbols (on depmod)! I do not know how it is possible. insmod -f manages to load this bad module, but I do not know how... 2. Well, I run updated X but glxinfo shows there is no DR - and the driver is usual mesa:( Ldd informs me about correct libGL and libGLU used for glxinfo. Any ideas? In X log, I do not see any errors reportes - it seems DRI is loaded as necessary Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 binaries: do not work
On Mon, 2002-03-11 at 14:37, Sergey V. Udaltsov wrote: Hi all There are problems with the bleeding edge binaries: 1. First of all, the kernel module cannot be loaded because of some unresolved symbols. And even when I do rm *.o, make, the resulting The .o shouldn't be packaged, or even built. I'll have to check why this is happening. mach64.o has some unresolved symbols (on depmod)! I do not know how it is possible. insmod -f manages to load this bad module, but I do not know how... hmm.. this could be caused for having a kernel source tree (/usr/src/linux-2.4) that doesn't match your installed kernel configuration. I also experienced this in RHL 7.2 with unrelated kernel modules and the only way I found to overcome was to build a new kernel from the sources and use it. Could you please past the output of insmod to see what are the failed symbols? 2. Well, I run updated X but glxinfo shows there is no DR - and the driver is usual mesa:( Ldd informs me about correct libGL and libGLU used for glxinfo. Any ideas? In X log, I do not see any errors reportes - it seems DRI is loaded as necessary Well, first let's try to figure out the first problem as this second one could be a side effect. Cheers, Sergey Jose Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: Downloadable Radeon Driver and libGL compatability
Jens Owen wrote: Brian Paul wrote: Jens Owen wrote: Jens Owen wrote: It looks like a new field was recently added to the GLXContextRec xc/lib/GL/glx/glxclient.h:407 GLXDrawable currentReadable; I added that last summer when I was implementing the GLX_SGI_make_current_read extension (glXMakeCurrentReadSGI() funcion). Keith discovered months ago that adding the new field broke backward compatibility. I told him that he could remove the field (and replace currentReadable with currentDrawable). If I change this field (everywhere it's referenced), can you recommend a test or two I can run to make sure I didn't break any expected functionality? That field should only be retrieved in the glXGetCurrentReadDrawable() function. I don't know of any demos or programs that call that function. The notion of different read and draw drawables is only used with the GLX_SGI_make_current_read extension which basically allows you to do glCopyPixels from one X window into a different X window. This feature is also available through GLX 1.3's glXMakeContextCurrent() function. But we don't implement GLX 1.3 yet, nor the GLX_SGI_make_current_read extension at this time. I had added the field in preparation of those features, but never finished them. I've moved this field to the end of the structure and the libGL.so compatability issue appears to be fixed. Hmmm, that might be good enough, but I'm not 100% certain. I'm worried that my hack of moving it to the end could possibly end up writing over the end of the structure allocation. So, I'd like to try your suggested fix of using the currentDrawable fied. Agreed. Wasn't this stuff recently submitted to the DRI trunk? Maybe we can fix this incompatability if this hasn't propogated out to any major distros, yet. Yes, we should really fix it ASAP. Was this part of Mesa 4? So this wouldn't have gone out in XFree86 4.2 or any other source releases where we care about binary compatability, right? It's not a Mesa issue, it's an XFree86 libGL issue. Just remove the field from the struct and replace any occuraces of the field with 'currentDrawable. instead. That'll work fine. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Friendly neighborhood #dri-devel meeting reminder.
Just a reminder of the weekly #dri-devel meeting on irc.openprojects.net at 4pm EST today. That's 2100 UTC, and 1pm PST. -- -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc.Phone: (705)949-2136 http://www.redhat.com ftp://people.redhat.com/mharris Red Hat XFree86 mailing list: [EMAIL PROTECTED] General open IRC discussion:#xfree86 on irc.openprojects.net -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Keithp's radeons are wedging
I've got two radeons: Radeon Mobility M6 LY in a couple laptops Radeon RV200_QW in a desktop that I'm having troubles with. On the desktop machine, I'm running the TCL-0-0 branch from DRI, built yesterday glxgears shows a black window with a reasonable frame rate (1500 FPS). The tuxracer menus work, but on starting the game, I get the background texture but none of the other objects. The background bobbles around a bit and then the game hangs. I can kill the X server and the game, but any attempt to access the console hangs the machine requiring a reboot. bzflag shows broken textures and then a hang after a few seconds of gameplay. This machine is an Athlon 1133 with a Via KT133 chipset. Kernel is vanilla 2.4.18 with the TCL-0-0 radeon kernel module. On the laptop, I'm running current XFree86 CVS (post Mesa 4.0 merge). glxgears works normally (570FPS) Tuxracer works normally, but a bit slow bzflag shows broken textures (text has the left and right edges clipped off of each glyph), and broken lines (1-pixel features are missing). This is a PIII 1200 with a Camino 2 chipset. Kernel is vanilla 2.4.16 with the current XFree86 CVS radeon kernel module. I was hoping to do some demos in the next week or two; help getting 3D working would be appreciated. Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI based X drivers; SMP testing
Hello there, I have just finished parrallelisation of Mesa vertex transformation and found that as the Vertex buffer is quite small (~100 verticies to the nearest order of magnitude) twhen using SMP vertex transformation you get no noticable performance gain because of the parrallelisation overhead. If the vertex buffer was larger ~1000 parrallelisation would be advantagous. Im now writing an interface layer that passes all ogl routine calls to another thread, there by running OGL on one thread and the client on another. This should improve performance on Q3A and other games like that. The other thing that got me thinking was this: I went the the ideal home exhibition in London over the w/e and got sight of the new I-macs; they aparently don't use vesa drivers for thier desktop, but use the 3D engine instead. This got me thinking about the console DRI port that some-one has already done. If you can get DRI to run from the console, would it be possible to write and X driver using OGL/DRI (I know that this may defeat the idea of DRI, but then again it may not). Have people like Keith, Brian and Daryll got any idea if it will run any faster/slower than vesa/svga drivers and if any 3-D like special effects would be easy to encorperate into the OGL X driver. Thanks for your time Andy ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Keithp's radeons are wedging
On Mon, 2002-03-11 at 21:17, Keith Packard wrote: I've got two radeons: Radeon Mobility M6 LY in a couple laptops Radeon RV200_QW in a desktop that I'm having troubles with. XFree86 4.2 doesn't have the cool features of the CVS code you're running but has been very solid in my experience. -- 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] DRI based X drivers; SMP testing
Q3A and RTCW don't take advantage of SMP on Linux yet. I have some patches that need to be applied and a bit of testing to do first. Things got delayed, but I'm still planning on releasing this. regards TTimo -- Linux technology contract - Id Software inc. On Mon, 11 Mar 2002 20:10:50 + Andrew James Richardson [EMAIL PROTECTED] wrote: Hello there, I have just finished parrallelisation of Mesa vertex transformation and found that as the Vertex buffer is quite small (~100 verticies to the nearest order of magnitude) twhen using SMP vertex transformation you get no noticable performance gain because of the parrallelisation overhead. If the vertex buffer was larger ~1000 parrallelisation would be advantagous. Im now writing an interface layer that passes all ogl routine calls to another thread, there by running OGL on one thread and the client on another. This should improve performance on Q3A and other games like that. The other thing that got me thinking was this: I went the the ideal home exhibition in London over the w/e and got sight of the new I-macs; they aparently don't use vesa drivers for thier desktop, but use the 3D engine instead. This got me thinking about the console DRI port that some-one has already done. If you can get DRI to run from the console, would it be possible to write and X driver using OGL/DRI (I know that this may defeat the idea of DRI, but then again it may not). Have people like Keith, Brian and Daryll got any idea if it will run any faster/slower than vesa/svga drivers and if any 3-D like special effects would be easy to encorperate into the OGL X driver. Thanks for your time Andy ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] mach64 binaries: do not work
The .o shouldn't be packaged, or even built. I'll have to check why this is happening. Well, hope the next version will be free of these wrong object files. Could you please past the output of insmod to see what are the failed symbols? Well, now it is OK. Sorry for disturbing on this issue. For some reason, it took the old version of mach64.o (bundled with tarball). Now I really rebuilt it - and still no success in point 2. The module loaded without problems. 2. Well, I run updated X but glxinfo shows there is no DR - and the driver is usual mesa:( Ldd informs me about correct libGL and libGLU used for glxinfo. Any ideas? In X log, I do not see any errors reports - it seems DRI is loaded as necessary So, still same situation... No DR, just Indirect Mesa. Can it be the problem of XFree 4.2.0 based on old Mesa? Well, first let's try to figure out the first problem as this second one could be a side effect. No, it is not... Any other ideas? Cheers, Sergey ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI based X drivers; SMP testing
On Mon, Mar 11, 2002 at 09:45:20PM +0100, Timothee Besset wrote: Q3A and RTCW don't take advantage of SMP on Linux yet. I have some patches that need to be applied and a bit of testing to do first. Things got delayed, but I'm still planning on releasing this. Heh...people have been waiting for those patches for a long time. :) In any case, his patches would give SMP at the *driver* support, and would SMP acclerate even single-threaded applications. I belive the 3Dlabs does something similar on Windows NT / 2000. -- Tell that to the Marines! ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRI based X drivers; SMP testing
Brian Paul wrote: One question to ask is: regardless of the vertex buffer size, typically how many vertices are issued between glBegin/End or state changes? Does Q3 (for example) render any objects/characters with 1000 vertices? Never. The maximum size of any locked array from the Q3 engine is ~1000 vertices (probably 1024). This is well documented in JohnC's How to write an OpenGL driver for Quake 3 doc. Typically, you see numbers in the range of 100-300 or so. -- Gareth ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
Keith Whitwell wrote: Keith Whitwell wrote: Jens Owen wrote: Michael Fitzpatrick wrote: Log message: Fix arrayelts color processing, vtxfmt_x86 Color4ubv function (red snow problem in Tuxracer) Good work Michael. You got the Red Out! :-) I am seeing some debugging messages from the FIXUP2 macro, but I don't think there is a problem. Here's the messages and a stack trace from when they are generated...just in case. radeonCreateScreen radeon_makeX86Color4ubv/438 CVAL 0 OFFSET 2 radeon_makeX86Color4ubv/439 CVAL deadbeaf OFFSET 27 radeon_makeX86Color4ubv/440 CVAL deadbeaf OFFSET 33 radeon_makeX86Color4ubv/441 CVAL deadbeaf OFFSET 55 radeon_makeX86Color4ubv/442 CVAL deadbeaf OFFSET 61 This is just me not quite finishing my job. The next step would be to turn all those FIXUP2's into FIXUP's using the results printed above. Jens - I've done this. Can you check your app is still working... I'm in the process of loading SuSE 7.3, again. When I get my devel system stable again; I'll rerun tuxracer. -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Texture compression on mach64?!?
On 2002.03.11 21:41 Gareth Hughes wrote: Seriously guys, this kind of thing is the last thing you should be worrying about, at least until you have a working DMA implementation and a fully-featured Mesa 4.x driver... Just my 2c. -- Gareth Gareth, it's not a question of worrying. I agree with you and I don't plan to look deeper into it until other things are supported, but since Ian ran into this by accident and brought the subject up, I also found it was a good oppurtinity to discuss it to be able establish some roadmap. Regards, José Fonseca ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: CVS Update: xc (branch: tcl-0-0-branch)
On Mon, 2002-03-11 at 20:37, Michael wrote: If I run X at 640x480, 800x600 or 1280x1024 I get about 86.5 fps with q3demo running @ 640x480 (86.5 because I've got debug code to print out the total texture size which was 5mb so that's not an issue) If I run X at 1024x768 (q3 still at 640x480) I only get ~76.5??? Testing a bit more, if I run q3 @ 1024x768 when X is 1024x768 I get about 36.3fps, but with X @ 1280x1024, q3@1024x768 gives me 59.8 (probably 60+ if I took out the fprintf) Is this just me? I've made similar experience with tuxracer on r128. Maybe the line pitch is a constraint somewhere? -- 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] Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
Michael wrote: On Sun, Mar 10, 2002 at 11:53:19PM +, Michael wrote: At the moment 1024x768 (which I expected to get the biggest benefit) hits lack of texture space and/or maybe depth clears / lack of hierarchical z, even with the pixmap cache set to 1 page and low texturing - at the mo this is still only a 2 or 3 fps gain there. Actually this is very strange. If I run X at 640x480, 800x600 or 1280x1024 I get about 86.5 fps with q3demo running @ 640x480 (86.5 because I've got debug code to print out the total texture size which was 5mb so that's not an issue) If I run X at 1024x768 (q3 still at 640x480) I only get ~76.5??? Testing a bit more, if I run q3 @ 1024x768 when X is 1024x768 I get about 36.3fps, but with X @ 1280x1024, q3@1024x768 gives me 59.8 (probably 60+ if I took out the fprintf) Is this just me? This might be a long shot, but try limiting your texture memory to a constant value for the various screen sizes, and see what happens. I recall from my operating systems class many years ago that there's an anomaly (Balady's anomaly, I think) where if you increase the number of page of physical memory available to a process it can actually cause an increase in the number of page faults, depending on the memory access pattern. Perhaps a similar thing is happening with textures in the first case you describe. Probably a long shot though. -Brian ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] i830/Radeon Mobility
Heya, I have a Radeon Mobility M6 LY running on a notebook using the i830 AGP Chipset.. I was wondering is support for the i830 chipset rather flakey at the moment, or is the radeon not well supported at this stage? I have been able to get DRI/3D going but not consistently.. anytime I run the X Server at a bit depth that would allow DRI (1024x768 @ 16bit or less) on my card I get strange lock ups at inconsistent times.. Sometimes during KDM start.. other's just in gnome.. sometimes i don't even get kdm to load. If the dev team would like I'm happy to test any new driver/module combos etc.. I've heard that the i830 chipset is pretty new so I figured you could use some hardware like mine to have tests run on.. cheers asqui/ldm -- Look into my eyes small child, to see what I have seen. I stare into the abyss Pokey the penguin. Does it stare back? Breakfast is the most important meal of the day. Pokey, it fills me with a hunger. Strawberry is my favorite. Let's have the toast and jelly of the soul. -- At night the ice weasels come. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Keithp's radeons are wedging
Around 20 o'clock on Mar 11, Keith Whitwell wrote: 7500's aren't working with the driver in at least two different ways. The first is the 'black window' problem - depth clears aren't working, the lockups are yet to be investigated. Thanks muchly. I'd offer to help, but I'm afraid I would ask more questions than generating sage advice. If access to an M6 machine would help, I've got a spare I could send for a couple of weeks. Life working for a hardware vendor has some benefits. At least I understand why others haven't been complaining bitterly on the lists; no-one else has a 7500. All I really wanted was something with DVI outputs, and the 7500 was *really* cheap ($80)... Keith PackardXFree86 Core TeamCompaq Cambridge Research Lab ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] odd 1024x768 behaviour was Re: [Dri-patches] CVS Update: xc (branch: tcl-0-0-branch)
On Mon, Mar 11, 2002 at 08:34:15PM +, Keith Whitwell wrote: Is this windowed or fullscreen? It's actually both, but the testing and figures above were fullscreen. glxgears is about 200fps slower in 1024x768 v 1280x1024 et al. Hmm, having thought about it, I'm pretty sure that this didn't happen with the old driver - I just didn't click and assumed 'lack of tex mem'. I've just tried AGP texturing (easy way to test Brian's suggestion as that made local tex mem a constant 0 and the agp space is constant) and the 1024x768 problem remains. So, as an aside, what I said the other week about agp texturing making the driver really slow was really about this problem. AGP texturing enabled c/w something to intelligently use both heaps will probably be a good win for 32mb cards as although it was slower, the hit wasn't massive. Enough rambling, I'll try and narrow this down to some specific change (I guess it still may turn out to be some oddity with my setup rather than a general trend) -- Michael. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
