Bug 141835 - Can't enable direct rendering on Radeon M9
Summary: Can't enable direct rendering on Radeon M9
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
(Show other bugs)
Version: 3
Hardware: All Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact: David Lawrence
Depends On:
TreeView+ depends on / blocked
Reported: 2004-12-03 23:11 UTC by Jeff Cheng
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-06 14:56:22 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
xorg.conf (3.09 KB, text/plain)
2004-12-03 23:11 UTC, Jeff Cheng
no flags Details
Xorg.0.log (36.94 KB, text/plain)
2004-12-03 23:12 UTC, Jeff Cheng
no flags Details
output from glxinfo (2.65 KB, text/plain)
2004-12-03 23:12 UTC, Jeff Cheng
no flags Details

Description Jeff Cheng 2004-12-03 23:11:15 UTC
Description of problem:
I can't get direct rendering to enable with a Radeon Mobility 9000
(M9) card.  I've looked through the logs and dri and agpgart seems to
have been loaded correctly, but glxinfo says otherwise.

Version-Release number of selected component (if applicable):

How reproducible:

Comment 1 Jeff Cheng 2004-12-03 23:11:56 UTC
Created attachment 107870 [details]

Comment 2 Jeff Cheng 2004-12-03 23:12:20 UTC
Created attachment 107871 [details]

Comment 3 Jeff Cheng 2004-12-03 23:12:44 UTC
Created attachment 107872 [details]
output from glxinfo

Comment 4 Mike A. Harris 2004-12-04 06:59:22 UTC
Your X server is properly configured for DRI and indicates
DRI is enabled.  When this happens and glxinfo indicates DRI
is not enabled, it generally means one of two things:

1) Your system may have multiple libGLs installed of which are
   conflicting with the one supplied and supported by Red Hat.
   If you have old libGL's laying around from some other vendor,
   such as previous ATI or Nvidia proprietary driver installations
   this will cause this problem.  Or, if you have old builds or
   alternative installations of XFree86, X.Org, or DRI or other
   builds installed anywhere, you may be getting a libGL mismatch.


2) You are running glxinfo on a remote machine, which causes it
   to use indirect GLX as direct rendering is not supported over
   a network.

If #1 is the case, you'll need to sort out your X installation
and/or reinstall the OS on a freshly wiped disk to ensure
no old libGL installations are interfering.  Alternatively, you
can use "strace", "ltrace" or other debugging tools to determine
which libGL is being used, and ensure the correct Red Hat supplied
libGL and DRI drivers are being used.

If #2 is the case, make sure to run glxinfo locally, as remotely
DRI is not implemented in any driver, so will not work.

What does 'rpm -V xorg-x11-Mesa-libGL' report?

Comment 5 Jeff Cheng 2004-12-04 09:11:11 UTC
You were right with case 1.  I had installed/uninstalled the fglrx
driver from http://www.stanford.edu/~fenn/linux/radeon.shtml a few
weeks ago.  I reinstalled all of my xorg packages and now I got direct
rendering... yay.  But should this issue of conflicting libGL's (Mesa
vs. uninstalled ATI) be a concern?

Comment 6 Mike A. Harris 2004-12-06 14:56:22 UTC
>You were right with case 1.  I had installed/uninstalled the fglrx
>driver from http://www.stanford.edu/~fenn/linux/radeon.shtml a few
>weeks ago.  I reinstalled all of my xorg packages and now I got
>direct rendering... yay. 

Ok, thanks for the update.  Setting status to "NOTABUG".

> But should this issue of conflicting libGL's (Mesa
> vs. uninstalled ATI) be a concern?

Wether 3rd party drivers and/or libraries conflict with the OS
supplied drivers and libraries is entirely a function of the
way the 3rd party driver vendor has packaged their software, and
how it installs on the system.

It is technically possible for 3rd party vendors such as ATI,
Nvidia, etc. to use RPM packaging to install their drivers,
and to locate their libGL and other files in a location that
does not conflict with the Red Hat system supplied software,
however wether this occurs or not, is up to the 3rd party
driver vendor.

So, I'd agree that people using unsupported 3rd party drivers
should be concerned enough to ensure that the driver installation
does not conflict with the OS supplied files we provide.  This
would be easier if vendors packaged things in proper rpm
packaging, but ultimately the hardware vendor chooses how their
drivers are installed, and wether it conflicts with the OS
supplied files or not.

Unfortunately, we have no control over wether or not 3rd party
software conflicts with what we ship, nor do we have any control
with what or how users install on their systems.  As such,
the possibility of users installing unsupported software which
conflicts with the OS will always be there.

Aside from recommending users stick strictly with the supported
software we provide with the OS, the best advice I can recommend
is to use only RPM packaged software, and to never install it using
--nodeps or --force.  Also, always to read the unsupported 3rd party
vendor's instructions fully before using their software, and any
time you have problems, to seek help on mailing lists where others
may have experienced similar problems.

Hope this helps.

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