Dave Jones wrote:
On Mon, Mar 20, 2006 at 04:49:42PM -0500, Mike A. Harris wrote: > So, R300 dri support will be something you need to compile for yourself > for the time being if desired. Also, our kernel does not have the > R300+ PCI IDs in it anymore, so you may need to recompile your kernel > as well. Not sure what davej's specific plans are for that, but I hope > he keeps the R300 PCI IDs out of the kernel at least until the r300 > DRI driver is remotely useable large-scale. not that it seems to matter. X seems to be doing a 'modprobe radeon' when it sees anything ATI.
Yeah. Not sure when exactly that changed, but it's probably because there is now OSS support for Mach64/R128/Radeon for 3D I'm guessing. We don't ship the mach64 DRI driver, or the R300+ one, but the X server still seems to have static lists of stuff which is a bit brain dead if you ask me. ;o)
Chopping the IDs out stops it being initialised, but it appears that X does _something_ differently just by having the module loaded even if its not using it.
Indeed, it is looking that way. We'll likely figure that out during FC6 and hopefully get it fixed in Xorg 7.1
I can keep them chopped out for the time being, but the downside is we're not going to get a lot of coverage testing, so how will we know when its 'good enough' ?
I'd say at a minimum - when there's a new upstream release which contains CVS checkins to the code in question as a minimum. If no fixes have went into the code that didn't work before, it's most likely still broken. ;o) For the 2D-only side of things, I'd want to wait at least until the new 2D radeon driver comes out (stable branch) and let it get tested for a while in rawhide. Then hopefully get any new regressions resolved. After that, enabling the kernel side again to see if it breaks anything would be following scientific method. I'd prefer to avoid re-enabling 2-3 things simultaneously, and then trying to guess which one caused breakage to occur though. By the time a new stable 2D driver has come out and had a reasonable shakedown period, then have a kernel DRM update which re-enables the kernel bits, and another shakedown period - a new Mesa is likely to be out, if not for the 6.4.x track, then the 6.5.x/6.6 track heading towards Xorg 7.1. I think it'd be good to wait until then before considering re-enabling R300 DRI driver support in Mesa, as we'd just be enabling known-broken code to do it before then, and getting nothing useful other than an increase in bug reports hitting Red Hat bugzilla, which should go to X.Org bugzilla instead. ;o) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
