Bug 115672 - Load "dri" should always be in the generated XF86Config
Load "dri" should always be in the generated XF86Config
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rhpl (Show other bugs)
1
All Linux
medium Severity medium
: ---
: ---
Assigned To: Brent Fox
:
: 107873 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-02-14 12:59 EST by Nicholas Miell
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-03-03 19:12:18 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Nicholas Miell 2004-02-14 12:59:59 EST
<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.
Comment 1 Brent Fox 2004-03-03 17:29:19 EST
mharris: wouldn't this cause problems on nvidia systems?
Comment 2 Mike A. Harris 2004-03-03 17:47:00 EST
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.

Comment 3 Brent Fox 2004-03-03 19:12:18 EST
Should be fixed in rhpl-0.129-1.  Thanks for your report.
Comment 4 Brent Fox 2004-03-04 15:13:41 EST
*** Bug 107873 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.