Difference between revisions of "Problems with fglrx"

From ThinkWiki
Jump to: navigation, search
(Known Troubles and Solutions)
(Troubles using software suspend: no idea what TerminateServer is, but I haven't used it back then)
Line 97: Line 97:
|{{T43p}}||Debian sid||2.6.14||8.19.10||Suspend to RAM||yes||without vbetool or UseDummyXServer, those two ''break'' the resume process here, with DRI enabled
|{{T43p}}||Debian sid||2.6.14||8.19.10||Suspend to RAM||yes||without vbetool or UseDummyXServer, those two ''break'' the resume process here, with DRI enabled
|{{T43p}}||Debian sid||||8.20.8||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled
|{{T43p}}||Debian sid||||8.20.8||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled

Revision as of 02:32, 6 January 2006

This page discusses issues with the ATI proprietary fglrx display driver.

Known Troubles and Solutions

Kernel-specific troubles

Using the current ATI driver (8.20.8) with the current release candidate 2.6.15-rc5 needs a patch. (info stolen from the table below, but put here for better visibility)

No hardware acceleration

If the ATI driver works only without the hardware acceleration, take into consideration that fglrx_dri.so was linked against libstdc++.so.5 which may not be present if your system uses gcc-3.4.

To fix this, compile gcc-3.3.5 and copy libstdc++.so.5* to /usr/lib and update the dynamic linker cache via # ldconfig.

Another possible cause for broken hardware acceleration (2D and 3D) is the radeonfb framebuffer: Switching to vesafb or vesafb-tng is reported to solve the problem on some systems. Also it has proven helpful to not perform # modprobe fglrx after boot but to have the module loaded via /etc/modules.autoload/kernel2.x at boottime instead.

Softlink hell

The fglrx installer replaces the standard X.org OpenGL implementation (Mesa) with its own files, potentially causing collisions with the distribution's file and package management. It is best to install the driver via a package built for your distribution, which will typically include the necessary kludges to make things work. See the fglrx page for pointers.


If you install the driver and type "fglrxinfo" which shows you are still using the mesa indirect software GL renderer, you likely have some misplaced softlinks. I find this *really* frustrating, and do not know why it occasionally occurs -> I think it has to do with an apt-get upgrade that sometimes replaces these links. Anyway, go to

cd /usr/X11R6/lib

and list your GL libraries and links

ls -la *GL*

You should see something like:

libGL.so -> libGL.so.1.2


libGL.so.1 -> libGL.so.1.2

If you see a link to a mesa library (something like ->libGL.mesa.1.2), then that's your problem! Restore the softlink with a command similar to:

ln -s <actual file> <softlink name>


ln -s libGL.so.1.2 libGL.so.1

For some reason, this link might "break" later, giving you the software rendering once more. I renamed the mesa library to mesa.bkup, and the system still found it and linked to it despite the name change. If you have to do this a lot, you could write a restoreGL script...


I did the above steps with no luck but it's working now so read on:


ldd /usr/X11R6/bin/glxinfo

showed that my system still uses the xorg-x11 mesa think and the above hint didn't work as expected I looked at this:

libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)

Afterwards I did:

cd /usr/lib/opengl/xorg-x11/lib/
mv libGL.so.1.2 libGL.so.1.2_backup
ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2

After another restart of X "fglrxinfo" showed that it's using the right libs now.

Alternative for Gentoo

Gentoo has built in tools for managing the OpenGL symlinks. They seem to be replacing the old tool with a new one, so one of the following should work for you:

# opengl-update ati
# eselect opengl set ati

Eselect is new, and still ~x86(as of the end of 2005), so you may not have it yet. opengl-update is the old tried-and-true method for managing the symlinks. If opengl-update doesn't fix it for you, you should probably tell Gentoo Bugzilla(assuming they don't know yet)

Troubles using software suspend

When the computer resumes from suspend, X only displays a garbled image and the computer is frozen. The problem is acknowledged in ATI's release notes and in knowledge base entry 737-218. Driver version 8.19.10 has "initial support for Suspend and Resume" but is working very nicely for most people (verified on T43, T43p and T42) without vbetool.

If you are using an older version of fglrx, using vbetool to save/restore the video card state before/after suspend worked for some people. If you use Software Suspend 2 (suspend2) scripts, you can simply uncomment EnableVbetool yes in /etc/hibernate/hibernate.conf. Be aware though that it breaks suspend/resume for drivers beginning with version 8.19.10, so remember to disable it again when upgrading.

tested with the following configurations
model distro kernel fglrx PM success comments
T42 SUSE 9.3 2.6.11 8.14.13 swsusp yes
T41p ??? 2.6.14 8.19.10 suspend2 2.2-rc9 yes needs a small patch
T42p Debian 2.6.10 Debian packaged suspend2 yes
T43 Debian sid 8.19.10 swsusp yes works perfectly with 8.19.10 (but not earlier versions!)
T43 Debian etch 8.19.10 swsusp yes works perfectly with 8.19.10 and without vbetool
T43 Ubuntu Breezy 2.6.12-10 8.19.10 swsusp yes Perfect. (Finally.)
T43 FC4 8.19.10 suspend2 2.2-rc9 yes needs a small patch, requires DRI disabled in xorg.conf (hence no 3D acceleration)
T43 FC4 8.19.10 suspend2 2.2-rc11 yes requires DRI disabled in xorg.conf (hence no 3D acceleration)
T43 FC4 8.19.10 suspend2 2.2-rc13 no DRI enabled
T43 FC4 8.20.8 suspend2 2.2-rc13 no DRI enabled
R50p ??? ??? 8.19.10 swsusp yes
T43p Debian sid 2.6.14 8.19.10 Suspend to RAM yes without vbetool or UseDummyXServer, those two break the resume process here, with DRI enabled
T43p Debian sid 8.20.8 Suspend to RAM yes without vbetool or UseDummyXServer, with DRI enabled
R52 Debian sid 2.6.15-rc5 8.20.8 swsup yes both vbetool and UseDummyXServer disabled, DRI enabled, needs patch

Troubles with large RAM

Version 8.14.13 (and probably earlier versions) of the driver does not seem to be able to cope with large amounts of RAM: with 512 MB it works, with 1.5 GB it crashes the machine as soon as X is started. The problem is present only if the fglrx kernel module is loaded, but independently of whether (CONFIG_HIGHMEM) is enabled. A workaround is to limit RAM by adding the mem=864m kernel parameter.

Version 8.16.20 fixes the problem.

Display switching

The switching between internal and external display doesn't work, because the driver blocks messing around with the chipset via ACPI. If you want to use this feature (i.e. during presentations), you should use the VESA server instead (experienced with a R52, Kernel 2.6.11, xorg 6.8.2, fglrx 8.16.20).

Composite Support

ATI has not officially supported composite windowing (alpha channel) enabling hardware acclerated translucent windows (primarily for 'eye candy.') Enabling Composite in KDE and the fglrx driver results in a very pretty desktop but unacceptably slow performance on a T43p with ATI's FireGL T2. It is still unusable in its current state (as of driver 8.19.10).

ATI promises support in the future when composite is officially supported by Xorg. Discussion of current status of drivers can be found in the Rage3d forums' (rage3d.com/board) Linux area. Rumor has it that the Microsoft Vista will support composite, so hopefully we will see it before then...

Hardlock on X logout

Up from driver version 8.19.10 you will expierence a system hard lock when logging out from X, if the session manager (kdm/gdm) is not properly configured. You have to tell the session manager to restart X.

In the kdm config file (gentoo: /usr/kde/<VERSION>/share/config/kdm/kdmrc) you have to add following to the section '[X-:*-Core]':


In the gdm config file add:


Information from the ATI butracker: http://ati.cchtml.com/show_bug.cgi?id=239


The following patches might be needed for certain versions of fglrx.

fglrx 8.20.8

fglrx (unspecified old version)

fglrx 8.8.25