Bug 141835

Created attachment 107870 [details]
xorg.conf

Created attachment 107871 [details]
Xorg.0.log

Created attachment 107872 [details]
output from glxinfo

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.

or

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?

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?

>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.