<mharris> File a bug against r-c-x, and carbon copy me on it. <mharris> It should put load "dri" *ALWAYS*. <mharris> Even on Cirrus logic <mharris> *always* <mharris> I wrote 2 essays in bugzilla on this already ;o) <mharris> ok, you can add to bug report "I talked to mharris, and he said Load "dri" should be present in the config file on x86 architecture always, no matter what video hardware it is, or wether DRI supports it or not" <mharris> AMD64, ia64 also <mharris> Load "dri" does not "turn DRI on" <mharris> It loads the X server's 'dri' extension module to make the DRI extension available for use if something needs it. <mharris> So it is valid to have that line present on any architecture that the module is built for. <mharris> commenting that line out, has the side effect of disabling DRI, because it removes the module the driver(s) need for DRI to work.
mharris: wouldn't this cause problems on nvidia systems?
Just to keep everyone who might be viewing this bug report up to scratch, I discussed this briefly with Brent in IRC. Here is the summary: The only time that the dri X server module should not be loaded (not listed in XF86Config), is on OS release/architecture combinations in which we do not provide DRI support at all. The "dri" X server module does not enable DRI on hardware. It loads the ability into the X server, to permit DRI-aware video drivers to use DRI. The "nv" driver is not DRI aware, and so it will just not use the loaded DRI module's functionality. The DRI module's code effectively doing nothing at all. For RHEL, we build DRI support for x86/ia64/amd64 only. For Fedora Core, we build DRI support for x86/ia64/amd64/ppc. I enabled DRI on Fedora Core builds because there is a possibility that someone might create a full port of Fedora Core to PPC for Mac users, and that class of users is very likely to want DRI enabled on PPC even if it is not totally stable or reliable and comes "as-is". It's disabled on RHEL3/PPC because the class of hardware which RHEL3/PPC is running on (IBM pSeries/iSeries), are big server machines and most wont even have a GUI running at all. Those that do, are very unlikely to require 3D acceleration support. DRI just adds an additional complexity to these type of PPC systems which can result in unnecessary instabilities for this class of hardware, and as such, since there would be little customer demand for DRI on the PPC systems we support, and we would have little chance of being able to support DRI enabled X servers on that platform, DRI was disabled as a stability/supportability measure. So from config tool perspective, the DRI module should be loaded at all times on x86/amd64/ia64. If possible, the config tools should only load the dri module on ppc for Fedora Core, but not for RHEL. If that is an additional complexity that you'd like to avoid, just disable DRI module loading on ppc always, as we don't have a PPC Fedora port yet so it isn't an issue.
Should be fixed in rhpl-0.129-1. Thanks for your report.
*** Bug 107873 has been marked as a duplicate of this bug. ***