https://www.thinkwiki.org/w/api.php?action=feedcontributions&user=Blue&feedformat=atomThinkWiki - User contributions [en]2024-03-28T20:39:37ZUser contributionsMediaWiki 1.31.12https://www.thinkwiki.org/w/index.php?title=Fglrx&diff=20790Fglrx2006-03-10T15:52:36Z<p>Blue: /* Status */</p>
<hr />
<div>== ATI fglrx driver ==<br />
This is a binary-only driver which supports 3D acceleration.<br />
<br />
Home page: https://support.ati.com/ics/support/default.asp?deptID=894&task=knowledge&folderID=356<br />
<br />
== Status ==<br />
Current version: 8.23.7 (9th March 2006)<br />
<br />
Major changes:<br />
* 8.23.7: support for X850 and X800, OpenGL 2.0 Enhancement, FSAA for some chips<br />
* 8.22.5: added kernel 2.6.15 support -- patch no longer required<br />
* 8.21.7: initial OpenGL 2.0 support<br />
* 8.20.8: fixed resume issues, fixed compile problems with kernels 2.6.13 and 2.6.14<br />
* 8.19.10: has added suspend / resume and dynamic GPU power management support. Using vbetool is no longer required (tested and successful with T43p).<br />
<br />
== Known problems and solutions ==<br />
See [[Problems with fglrx]].<br />
<br />
== Packages ==<br />
The ATI drivers have explicit permission for repackaging and redistribution of the Linux drivers. Many distributions are supported within the installer, and many more repackaged by external developers. Please visit the [http://wiki.cchtml.com/index.php/Category:Distributions Distribution Page at the Unofficial ATI driver Wiki]<br />
<br />
*{{Debian}} packages: http://xoomer.virgilio.it/flavio.stanchina/debian/fglrx-installer.html<br />
** These packages have been added to Debian unstable as "fglrx-driver", so you can now apt-get them and use module-assistant to install (currently v8.20.8-1).<br />
** If you are on stable sarge with backport's kernel 2.6.15, download ATI's installer, currently v8.22.5, let it build Debian packages and proceed as usual. There's a [http://jroller.com/page/erAck?entry=lot_day_6_2_fglrx detailed description] available.<br />
*{{SUSE}} packages: ftp://ftp.suse.com/pub/suse/i386/supplementary/X/ATI/<br />
*{{Gentoo}} {{cmdroot|emerge x11-drivers/ati-drivers}}<br />
*{{Fedora}} packages: http://rpm.livna.org<br />
** For stock Fedora kernels: {{cmdroot|yum install kernel-module-fglrx-$(uname -r) ati-fglrx }}<br />
** Creating and installing a custom RPM for a custom-compiled kernel on {{Fedora}}:<br />
# yum install ati-fglrx<br />
# VER=8.20.8.1-0.lvn.1.4 # copy version string from output of above command<br />
# wget http://rpm.livna.org/fedora/4/i386/SRPMS.lvn/ati-fglrx-$VER.src.rpm<br />
# rpmbuild --rebuild --target $(uname -m) --define "ksrc /lib/modules/$(uname -r)/build" --without userland ati-fglrx-$VER.src.rpm<br />
# rpm -Uvh --replacepkgs /usr/src/redhat/RPMS/$(uname -m)/kernel-module-fglrx-$(uname -r)-$VER.$(uname -m).rpm<br />
*{{Arch Linux}}<br />
** {{cmdroot|pacman -S ati-drivers}} (Userspace tools and libraries)<br />
** {{cmdroot|pacman -S ati-drivers-arch}} (Drivers for the stock Arch Linux kernel)<br />
** {{cmdroot|pacman -S ati-drivers-archck}} (Drivers for the ArchCK Linux kernel)<br />
== User experience ==<br />
=== Speed ===<br />
How much is the speed gain versus the opensource drivers?<br />
<br />
- On the old drivers, I've noticed appx 40% speed gain with ATI fglrx vs open source drivers. However, there are issues with freezing/garbage after suspend, garbage when resizing desktop (ctrl-alt-plus, ctrl-alt-minus), and garbage while using VMware. The current 8.14.13 has shown 400% improvement over using "radeon" or "ati" in xorg.conf. 1200FPS glxgears! (''note that glxgears isnt a benchmark tool, its so simple that its value is without any meaning... you can only compare glxgears using the same drivers/machine, if you change any of then you can have higher/lower values and in real life programs/games happend the opposite. Think in the car engine rpm, higher rpm in the same car usually its a faster car, change anything and its meaningless. ie: gears, truck, wheel size, etc make it useless'')<br />
<br />
NOTE: 2D acceleration may be disabled when 3D acceleration is enabled. This comes from the Xorg.conf file the fglrx driver provides<br />
# === OpenGL Overlay ===<br />
# Note: When OpenGL Overlay is enabled, Video Overlay<br />
# will be disabled automatically<br />
Option "OpenGLOverlay" "1"<br />
<br />
Just a note to the above. The 2D acceleration for that option refers to video overlay. You can use either regular Xv video overlay or make the video an opengl texture and let the OpenGL engine scale your video. It has nothing to do with 2D drawing primitives. Further, your mileage on performance may vary depending on what card you have. The open-source drivers don't support newer cards, while the ATI drivers don't support older cards.<br />
<br />
=== Power saving ===<br />
Power saving is much better than with the <tt>radeon</tt> driver, but doesn't work in dual-screen configuration (see [[How to make use of Graphics Chips Power Management features]]).<br />
<br />
== Useful links == <br />
* [http://www.ati.com/products/catalyst/linux.html ATI Linux Driver FAQ]<br />
* [http://www.rage3d.com/content/articles/atilinuxhowto/ ATI Radeon Linux How-To]<br />
* [http://www.rage3d.com/board/forumdisplay.php?f=61&daysprune=30&order=asc&sort=title Rage3D Linux Discussion Forum]<br />
* [http://www.driverheaven.net/forumdisplay.php?f=103 Radeon Driver Forum at Driverheaven]<br />
* [http://odin.prohosting.com/wedge01/gentoo-radeon-faq.html Gentoo ATI Radeon FAQ]<br />
* [http://forums.gentoo.org/viewtopic-t-374745-highlight-t42+ati+dri.html Gentoo T42 ATI. DRI + xorg driver]<br />
* [http://ati.cchtml.com/ Unofficial community ATI bugzilla] - tracks bugs in the driver. Might be monitored by ATI ([http://www.rage3d.com/board/showpost.php?p=1333438751&postcount=386], [http://www.rage3d.com/board/showpost.php?p=1333439009&postcount=390]).<br />
<br />
== ThinkPads that may be supported ==<br />
Supported chips, as found in select IBM ThinkPads:<br />
* [[ATI Mobility FireGL 9000]]<br />
** {{T40p}}<br />
* [[ATI Mobility FireGL T2]]<br />
** {{R50p}}<br />
** {{T41p}}, {{T42p}}<br />
* [[ATI Mobility FireGL V3200]]<br />
** {{T43p}}<br />
* [[ATI Mobility Radeon 9000]]<br />
** {{R50}}, {{R51}}<br />
** {{T40}}, {{T41}}, {{T42}}<br />
* [[ATI Mobility Radeon 9600]]<br />
** {{T42}}<br />
* [[ATI Mobility Radeon X300]]<br />
** {{R52}}<br />
** {{T43}}<br />
** {{Z60m}}<br />
* [[ATI Mobility Radeon Xpress 200M]]<br />
** {{R51e}}<br />
* [[ATI Mobility Radeon X600]]<br />
** {{Z60m}}<br />
<br />
[[Category:Drivers]]</div>Bluehttps://www.thinkwiki.org/w/index.php?title=Talk:Problems_with_fglrx&diff=19932Talk:Problems with fglrx2006-02-14T10:01:15Z<p>Blue: /* Compile ATI driver??? */</p>
<hr />
<div>== using kernel AGP vs fglrx AGP ==<br />
<br />
Anyone know whether this makes a performance and/or stability difference?<br />
<br />
== 8.20.8 and later works with current Debian sid packages ==<br />
<br />
<pre><br />
spiney@t43p:~$ dpkg -l xserver-xorg<br />
Desired=Unknown/Install/Remove/Purge/Hold<br />
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed<br />
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)<br />
||/ Name Version Description<br />
+++-============================-============================-==================<br />
ii xserver-xorg 6.9.0.dfsg.1-2 the X.Org X server<br />
spiney@t43p:~$ fglrxinfo <br />
display: :0.0 screen: 0<br />
OpenGL vendor string: ATI Technologies Inc.<br />
OpenGL renderer string: MOBILITY FireGL V3200 Pentium 4 (SSE2) (FireGL) (GNU_ICD)<br />
OpenGL version string: 1.3.5519 (X4.3.0-8.20.8)<br />
</pre><br />
<br />
--[[User:Spiney|spiney]]<br />
----<br />
<br />
Ahh - thanks for the info. You perhaps compiled the modules for the drivers yourself and did not use the debian packaged fglrx-driver? Thus, it must be an unneeded limitation on the debian packaged driver which limits its installation... Full listing at http://packages.debian.org/unstable/x11/fglrx-driver which lists as required packages:<br />
<br />
xserver-xorg (<< 6.8.99)<br />
the X.Org X server <br />
xserver-xorg (>= 6.8.0) <br />
<br />
The first limitation (<<6.8.99) is what prevents installation. I'm sure I could force apt to install it, but I may go back to compiling the modules myself, as using fglrx 8.20.8 with kernel 2.6.15 needs a small patch to compile correctly anyway... --[[User:gsmenden|gsmenden]]<br />
<br />
Spiney, where exactly do you have your package from? I re-build the 8.20.8-package from debian with the <<6.8.99 dependecy removed, but when I try to run X, I get <br />
[R200Setup] X version mismatch - detected X.org 7.0.0.0, required X.org 6.8.0.0<br />
(EE) Failed to load module "fglrx" (module requirement mismatch, 0)<br />
Any hints? --[User:nomeata|nomeata]<br />
<br />
I used the ati-installer (the huge download), created a Debian sid package and installed it, but got the same error. The installer seems to fetch the wrong driver version from the archive, so I extracted it with<br />
<br />
{{cmd|./ati-driver-installer-8.20.8-i386.run --extract <sometempdir>|}}<br />
<br />
and put the necessary files from the created {{path|<sometempdir>/x690}} subdirectory into {{path|/usr}} by hand. All IIRC, it's been some time since. :)<br />
<br />
--[[User:Spiney|spiney]] 07:29, 11 Jan 2006 (CET)<br />
<br />
Thanks for the pointer. This is how you get proper debian packages out of the ati-installer:<br />
./ati-driver-installer-8.20.8-i386.run --extract fglrx-tmp<br />
cd fglrx-tmp<br />
$editor packages/Debian/ati-packager.sh # in the line "sid|unstable) X_DIR=x680;;", put a x690 for the x680<br />
./fglrx-tmp/packages/Debian/ati-packager.sh --buildpkg sid<br />
cd ..<br />
sudo dpkg -i fglrx-kernel-src_8.20.8-1_i386.deb fglrx-driver_8.20.8-1_i386.deb<br />
--[[User:Nomeata|Nomeata]] 00:35, 13 Jan 2006 (CET)<br />
<br />
<br />
----<br />
<br />
Nice - confirmed works on my T43p running sid. From then on (or until 8.21.x comes out) you'll have to tell apt to hold back fglrx-driver package, or it will try to "update" fglrx-driver to 8.20.8-1.1 and therefore revert back to the problematic drivers.<br />
--[[User:gsmenden|gsmenden]]<br />
----<br />
<br />
Thanks for the info, Nomeata, that's a lot cleaner a solution than my manual way.<br />
<br />
--[[User:Spiney|spiney]] 08:32, 13 Jan 2006 (CET)<br />
----<br />
<br />
To get this working under 2.6.15 with x.org 6.9, you will also need to apply a small patch - there is a link on the main article page. After you install the fglrx-driver package with the 6.9 versioning hack above, go to<br />
/usr/src/modules<br />
and copy the patch here. Modify the first two lines of the patch file to take out the "build_mod" directory, e.g. first line should begin with<br />
--- fglrx.orig/firegl_public.c <br />
and call it with the -p0 strip option. It should patch the firegl_public.c file cleanly. You can then install as usual for your kernel (2.6.14.x or 2.6.15) using module-assistant.<br />
<br />
Update - although X will come up in kernel 2.6.15 with the fglrx drivers patched as above, there is some strange behavior exhibited in all of X apllications - frequent hanging of applications when closing windows. Reverting back to the radeon driver in 2.6.15 solves these - so it is likely the ATI proprietary driver causing some problems.<br />
<br />
Yet another update - fglrx 8.21.7 is out as of 1/19/2006, now supporting OpenGL 2.0, so eventually we will have beautiful complex shading / fog effects on Linux, too. It works well with X.Org 6.9 out of the box.<br />
<br />
Unfortunately, this version gives the same problems when used (unpatched) with kernel 2.6.15 with strange lockups occasionally requiring reset of X. I have not tried this with the ~10 line patch listed on the main site, but that patch not work for me with 8.20.8. Anybody else have experience with 2.6.15 and fglrx?<br />
<br />
Yay - new version out - 8.22.5 - works well with 2.6.15.x. Finally, running a plain-vanilla kernel on a T43p! (SATA+libata passthrough+SMART in mainline, 3d accel drivers up to date. Linux life is good.)<br />
<br />
--[[User:gsmenden|gsmenden]] 12:39, 9 Feb 2006 (EST)<br />
----<br />
<br />
I don't know which patch you mean exactly (10 lines? the patch from lkml is just one line changed, no?), but I've been using 8.20.8 with 2.6.15 for quite some time (actually started with some -rc version IIRC), no lockups at all. No idea about 8.21.7 though, because I switched to 2.6.16-rc1 and can't compile the fglrx module at the moment, need to investigate the cause.<br />
<br />
--[[User:Spiney|spiney]] 07:24, 21 January 2006 (CET)<br />
----<br />
<br />
Ok - strange. Yeah, the actual change is only one line, the rest is just commenting, etc. The lockups that I get are quite rare, but flightgear occasionally gives a hard lock. glxgears and fgl_glxgears work fine, netscape occasionally will hard-lock, and strangely enough issuing a shutdown command often makes the display blank and hard lock. I can't reproduce them too consistently, but these _never_ occur with the radeon driver / mesa or under 2.6.14.x.<br />
<br />
Unfortunately vanilla 8.21.7 with kernel 2.6.15.1 (Xorg 6.9) gives the same X lockups.<br />
<br />
--[[User:gsmenden|gsmenden]] 11:36, 21 Jan 2006 (EST)<br />
----<br />
<br />
I can't compile the 8.21.7 driver modules with 2.6.15.1 at all. They compile with 2.6.14.4 cleanly and 8.20.8 compile with 2.6.15.1. <br />
What I don't understand though is, that when I let the ATI installer build debian packages, it does so without hassle, but the packages don't work. <br />
(this is about 8.21.7 - 2.6.15.1) Also patching doesn't seem to help. It shouldn't of course.<br />
<br />
--[[User:Rasto|Rasto]] 15:04, 23 Jan 2006 (CET)<br />
<br />
I looked at the compile problems last night. I have no idea, how it is possible that it works for other people with 2.6.15, perhaps when you install <br />
precompiled modules? I don't really understand how that ati-installer thing works. Anyway. This may solve the problems with 8.21.7 and 2.6.15- <br />
it is just two minor line changes (+ the one line patch with little extra), but now it compiles. pm_register and similar were moved to linux/pm_legacy.h <br />
in 2.6.15, so that's one problem. It also reports unknown symbol verify_area, but this should not pose a problem, as it is already obsolete and redundant. <br />
If you feel, that the one line should be left as the separate patch, copy it somewhere else and change it. It's here [http://people.ksp.sk/~rasto/fglrx_with_2.6.15.patch], but I'll put it on the main page as well.<br />
<br />
--[[User:Rasto|Rasto]] 18:29, 25 Jan 2006 (CET)<br />
<br />
== Disabling the external VGA port? ==<br />
<br />
Does anyone know how disable the VGA port ''completely'' even when a cable is attached? Fiddling around with the DesktopSetup and ForceMonitor options didn't do the trick for me, and the MonitorLayout option found in some documentation is no longer valid in the current fglrx driver.<br />
<br />
--[[User:Spiney|spiney]] 19:42, 10 Jan 2006 (CET)<br />
----<br />
<br />
== Debian-specific script to switch fglrx<->radeon ==<br />
<br />
Don't know where to put it exactly, but if someone's interested (and using Debian), I've put up a [http://linux.spiney.org/debian_gnu_linux_on_an_ibm_thinkpad_t43p_graphics_card_switching_fglrx_radeon script for easily switching graphics driver configurations]. Feedback appreciated (altho I haven't got any to the xscreensaver patch ;)), especially if someone could do something similar for other distributions (Gentoo being half-way there it seems) and incorporate it into the script.<br />
<br />
--[[User:Spiney|spiney]] 15:25, 17 January 2006 (CET)<br />
----<br />
<br />
----<br />
==Compile ATI driver???==<br />
How can you compile a binary only distributed driver? If I'm not getting something wrong, please change the formulation of the just added info.<br />
[[User:Wyrfel|Wyrfel]] 20:10, 25 January 2006 (CET)<br />
----<br />
[http://xoomer.virgilio.it/flavio.stanchina/debian/fglrx-installer.html#overview1]<br />
"The driver as a whole is made of three main components: the driver proper, a replacement libGL and a kernel module. The driver and libGL are in the fglrx-driver package, the kernel module's source code is in the fglrx-kernel-src package."<br />
--[[User:Dunno|Dunno]] 23:49, 13 February 2006 (CET)<br />
----<br />
Yepp, my fault, didn't think of the kernel part when i wrote that. [[User:Wyrfel|Wyrfel]] 02:50, 14 February 2006 (CET)<br />
----</div>Bluehttps://www.thinkwiki.org/w/index.php?title=Problems_with_fglrx&diff=19799Problems with fglrx2006-02-11T14:12:42Z<p>Blue: /* Acceleration lost after driver update */</p>
<hr />
<div>This page discusses issues with the ATI proprietary [[fglrx]] display driver.<br />
<br />
== Known Troubles and Solutions ==<br />
<br />
=== X-specific issues ===<br />
<br />
ATI proprietary drivers version 8.21.7 and later work with x.org 6.9.<br />
<br />
If you are running an older version (8.20.8) under Debian sid and you upgrade your xserver-xorg, apt will force you to remove any debian-packaged fglrx drivers (package fglrx-driver depends on x.org << 6.8.99). You can just download the driver from the ATI site and install after modifying the Debian packager script to allow dependencies to be satisfied by x.org 6.9, or just download 8.21.7 and install manually. See talk page for step-by-step commands.<br />
<br />
After installing the fglrx driver, you can use module-assist to build the appropriate kernel module.<br />
<br />
=== Kernel-specific troubles ===<br />
<br />
Using ATI driver 8.21.7 and earlier with kernel 2.6.15 or later needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead. <br />
<br />
If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|fglrxinfo}} - if your shell hangs at the end of this command, you may have an issue and should try the patch.<br />
<br />
Although unproven, there is a substantial amount of user / developer concern that the above patches prevent hard lockups but do not provide full reliability with 2.6.15 and there are larger / redisgn issues preventing compatibility. It seems surprising that ATI would not have implemented such a simple page count fix in their latest two driver releases since kernel 2.6.15 has been available. Given the closed-source nature of the driver, it is difficult to know for sure. As of now only 2.6.14.x kernels are officially supported by the fglrx driver.<br />
<br />
=== No hardware acceleration ===<br />
<br />
====Acceleration lost after driver update====<br />
If you lose hardware acceleration after a driver update this can be caused by an old fglrx kernel module being loaded.<br />
<br />
Check out {{path|1=/var/log/Xorg.0.log}} for a message like:<br />
:<code>(WW) fglrx(0): Kernel Module version does *not* match driver.</code><br />
:<code>(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work</code><br />
<br />
You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:<br />
:<code>(II) fglrx(0): Kernel Module Version Information:</code><br />
:<code>(II) fglrx(0): Name: fglrx</code><br />
:<code>(II) fglrx(0): Version: 8.10.19</code><br />
<br />
The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path.<br><br />
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=grep fglrx modules.dep}}.<br><br />
If grep finds multiple lines you nailed down the problem. All you have to do now is to delete any versions of the module (look at the filedate) but the most current one. Then run {{cmdroot|1=depmod}} and you are done.<br />
<br />
{{HINT|Newer versions (8.21.7) of the fglrx module seem to be installed in the <code>extra/</code> subdirectory.<br><br />
Older versions (8.19.10) used to be located in the <code>kernel/drivers/char/drm/</code> subdirectory.}}<br />
<br />
====GCC 3.4====<br />
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|fglrx_dri.so}} was linked against libstdc++.so.5 which may not be present if your system uses gcc-3.4.<br />
<br />
To fix this, compile gcc-3.3.5 and copy <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.<br />
<br />
====radeonfb framebuffer====<br />
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 {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/etc/modules.autoload/kernel2.x}} at boottime instead.<br />
<br />
=== Softlink hell ===<br />
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.<br />
<br />
====Discussion====<br />
If using {{cmduser|fglrxinfo}} after installing [[fglrx]] indicates that you are still using the mesa indirect software GL renderer, you likely have some misplaced softlinks. It seems like it has to do with an apt-get upgrade that sometimes replaces these links. Anyway, go to<br />
:{{cmdroot|cd /usr/X11R6/lib}}<br />
and list your GL libraries and links<br />
:{{cmdroot|ls -la *GL*}}<br />
You should see something like the following two lines amoung others:<br />
:{{cmdresult|libGL.so -> libGL.so.1.2}}<br />
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}<br />
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):<br />
:{{cmdroot|ln -s libGL.so.1.2 libGL.so.1}}<br />
<br />
For some reason, this link might "break" later, giving you the software rendering once more. Even after renaming the mesa library to something like <tt>mesa.bkup</tt>, the system might still find it and link to it despite the name change. If you have to do this a lot, you could write a restoreGL script.<br />
<br />
=====Gentoo=====<br />
{{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:<br />
:{{cmdroot|opengl-update ati}} or<br />
:{{cmdroot|eselect opengl set ati}}<br />
Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. <tt>opengl-update</tt> is the old tried-and-true method for managing the symlinks. If <tt>opengl-update</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).<br />
<br />
If {{cmdroot|ldd /usr/X11R6/bin/glxinfo}} shows that your system still uses the xorg-x11 mesa libs after trying one of the above commands, i.e. a line like this:<br />
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}<br />
you will also need to relink {{path|libGl.so.1.2}}:<br />
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}<br />
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}<br />
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}<br />
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.<br />
<br />
=== Troubles using software suspend ===<br />
When the computer resumes from suspend, X only displays a garbled image and the computer is frozen.<br />
The problem is acknowledged in ATI's release notes and in knowledge base entry [https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 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.<br />
<br />
If you are using an older version of fglrx, using [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/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.<br />
<br />
{| cellspacing="0" cellpadding="2" border="1"<br />
|+ tested with the following configurations<br />
!model!!distro||kernel!!fglrx!!PM!!success!!comments<br />
|-<br />
|{{T42}}||SUSE 9.3||2.6.11||8.14.13||swsusp||yes||<br />
|-<br />
|{{T41p}}||???||2.6.14||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch]<br />
|-<br />
|{{T42p}}||Debian||2.6.10||Debian packaged||suspend2||yes||<br />
|-<br />
|{{T43}}||Debian sid||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 (but not earlier versions!)<br />
|-<br />
|{{T43}}||Debian etch||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 and without vbetool<br />
|-<br />
|{{T43}}||Ubuntu Breezy||2.6.12-10||8.19.10||swsusp||yes||Perfect. (Finally.)<br />
|-<br />
|{{T43}}||FC4||2.6.14.1||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)<br />
|-<br />
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)<br />
|-<br />
|{{T43}}||FC4||2.6.14.3||8.19.10||suspend2 2.2-rc13||no||DRI enabled<br />
|-<br />
|{{T43}}||FC4||2.6.14.3||8.20.8||suspend2 2.2-rc13||no||DRI enabled<br />
|-<br />
|{{R50p}}||???||???||8.19.10||swsusp||yes||<br />
|-<br />
|{{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<br />
|-<br />
|{{T43p}}||Debian sid||2.6.14.3||8.20.8||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled<br />
|-<br />
|{{R52}}||Debian sid||2.6.15-rc5||8.20.8||swsup||yes||both vbetool and UseDummyXServer disabled, DRI enabled, needs [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]<br />
|}<br />
<br />
=== Troubles with large RAM ===<br />
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 <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|mem|864m}} kernel parameter.<br />
<br />
Version 8.16.20 fixes the problem.<br />
<br />
===Display switching ===<br />
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 <tt>vesa</tt> server instead (experienced with a R52, Kernel 2.6.11, xorg 6.8.2, fglrx 8.16.20).<br />
<br />
===Composite Support===<br />
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).<br />
<br />
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.<br />
<br />
There were some rumors that composite support was fast with the open-source 2d accelerated drivers in x.org 6.9 (as opposed to 6.8.x). Alas, trying this gives better results than the proprietary drivers, but it is still too slow to be reasonably useful.<br />
<br />
===Hardlock on X logout===<br />
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.<br />
<br />
In the kdm config file (gentoo: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>: <br />
TerminateServer=true<br />
<br />
In the gdm config file add:<br />
AlwaysRestartServer=true<br />
<br />
Information from the ATI bugtracker: http://ati.cchtml.com/show_bug.cgi?id=239<br />
<br />
===Error messages in system log===<br />
<br />
If you find something like the following in {{path|/var/log/messages}}:<br />
<br />
:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}<br />
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}<br />
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}<br />
<br />
try to execute the following line and reload the fglrx module:<br />
<br />
:{{cmdroot|1=echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr}}<br />
<br />
More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 here].<br />
<br />
===Hang when logging out===<br />
<br />
A common problem is that when logging out from X, instead of gettign the KDM or GDM prompt, the system hangs.<br />
<br />
This is discussed, including workarounds here: http://ati.cchtml.com/show_bug.cgi?id=239<br />
<br />
===No power saving when CRT in use===<br />
<br />
When both CRT and LCD are in use, power saving cannot be enabled.<br />
<br />
This is reported here: http://ati.cchtml.com/show_bug.cgi?id=304<br />
<br />
== Patches ==<br />
The following patches might be needed for certain versions of fglrx.<br />
<br />
===fglrx 8.21.7===<br />
<br />
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]<br />
<br />
===fglrx 8.20.8===<br />
<br />
* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]<br />
or<br />
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]<br />
<br />
===fglrx (problem met at least with version 8.18.8)===<br />
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug<br />
<br />
===fglrx 8.8.25 ===<br />
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]<br />
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]</div>Bluehttps://www.thinkwiki.org/w/index.php?title=Problems_with_fglrx&diff=19007Problems with fglrx2006-01-26T16:22:48Z<p>Blue: /* Acceleration lost after driver update */</p>
<hr />
<div>This page discusses issues with the ATI proprietary [[fglrx]] display driver.<br />
<br />
== Known Troubles and Solutions ==<br />
<br />
=== X-specific issues ===<br />
<br />
The current ATI proprietary driver (8.21.7) works with x.org 6.9.<br />
<br />
If you are running an older version (8.20.8) under Debian sid and you upgrade your xserver-xorg, apt will force you to remove any debian-packaged fglrx drivers (package fglrx-driver depends on x.org << 6.8.99). You can just download the driver from the ATI site and install after modifying the Debian packager script to allow dependencies to be satisfied by x.org 6.9, or just download 8.21.7 and install manually. See talk page for step-by-step commands.<br />
<br />
After installing the fglrx driver, you can use module-assist to build the appropriate kernel module.<br />
<br />
=== Kernel-specific troubles ===<br />
<br />
Using the current ATI driver (8.21.7) with 2.6.15 or later needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead. <br />
<br />
If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|fglrxinfo}} - if your shell hangs at the end of this command, you may have an issue and should try the patch.<br />
<br />
Although unproven, there is a substantial amount of user / developer concern that the above patches prevent hard lockups but do not provide full reliability with 2.6.15 and there are larger / redisgn issues preventing compatibility. It seems surprising that ATI would not have implemented such a simple page count fix in their latest two driver releases since kernel 2.6.15 has been available. Given the closed-source nature of the driver, it is difficult to know for sure. As of now only 2.6.14.x kernels are officially supported by the fglrx driver.<br />
<br />
=== No hardware acceleration ===<br />
<br />
====Acceleration lost after driver update====<br />
If you lose hardware acceleration after a driver update this can be caused by an old fglrx kernel module being loaded.<br />
<br />
Check out {{path|1=/var/log/Xorg.0.log}} for a message like:<br />
:<code>(WW) fglrx(0): Kernel Module version does *not* match driver.</code><br />
:<code>(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work</code><br />
<br />
You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:<br />
:<code>(II) fglrx(0): Kernel Module Version Information:</code><br />
:<code>(II) fglrx(0): Name: fglrx</code><br />
:<code>(II) fglrx(0): Version: 8.10.19</code><br />
<br />
The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path.<br><br />
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=grep fglrx modules.dep}}.<br><br />
If grep finds multiple lines you nailed down the problem. All you have to do now is to delete any versions of the module (look at the filedate) but the most current one. Then run {{cmdroot|1=depmod}} and you are done.<br />
<br />
{{HINT|The current version (8.21.7) of the fglrx module seem to be installed in the <code>extra/</code> subdirectory.<br><br />
Older versions (8.19.10) used to be located in the <code>kernel/drivers/char/drm/</code> subdirectory.}}<br />
<br />
====GCC 3.4====<br />
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|fglrx_dri.so}} was linked against libstdc++.so.5 which may not be present if your system uses gcc-3.4.<br />
<br />
To fix this, compile gcc-3.3.5 and copy <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.<br />
<br />
====radeonfb framebuffer====<br />
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 {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/etc/modules.autoload/kernel2.x}} at boottime instead.<br />
<br />
=== Softlink hell ===<br />
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.<br />
<br />
====Discussion====<br />
If using {{cmduser|fglrxinfo}} after installing [[fglrx]] indicates that you are still using the mesa indirect software GL renderer, you likely have some misplaced softlinks. It seems like it has to do with an apt-get upgrade that sometimes replaces these links. Anyway, go to<br />
:{{cmdroot|cd /usr/X11R6/lib}}<br />
and list your GL libraries and links<br />
:{{cmdroot|ls -la *GL*}}<br />
You should see something like the following two lines amoung others:<br />
:{{cmdresult|libGL.so -> libGL.so.1.2}}<br />
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}<br />
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):<br />
:{{cmdroot|ln -s libGL.so.1.2 libGL.so.1}}<br />
<br />
For some reason, this link might "break" later, giving you the software rendering once more. Even after renaming the mesa library to something like <tt>mesa.bkup</tt>, the system might still find it and link to it despite the name change. If you have to do this a lot, you could write a restoreGL script.<br />
<br />
=====Gentoo=====<br />
{{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:<br />
:{{cmdroot|opengl-update ati}} or<br />
:{{cmdroot|eselect opengl set ati}}<br />
Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. <tt>opengl-update</tt> is the old tried-and-true method for managing the symlinks. If <tt>opengl-update</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).<br />
<br />
If {{cmdroot|ldd /usr/X11R6/bin/glxinfo}} shows that your system still uses the xorg-x11 mesa libs after trying one of the above commands, i.e. a line like this:<br />
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}<br />
you will also need to relink {{path|libGl.so.1.2}}:<br />
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}<br />
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}<br />
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}<br />
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.<br />
<br />
=== Troubles using software suspend ===<br />
When the computer resumes from suspend, X only displays a garbled image and the computer is frozen.<br />
The problem is acknowledged in ATI's release notes and in knowledge base entry [https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 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.<br />
<br />
If you are using an older version of fglrx, using [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/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.<br />
<br />
{| cellspacing="0" cellpadding="2" border="1"<br />
|+ tested with the following configurations<br />
!model!!distro||kernel!!fglrx!!PM!!success!!comments<br />
|-<br />
|{{T42}}||SUSE 9.3||2.6.11||8.14.13||swsusp||yes||<br />
|-<br />
|{{T41p}}||???||2.6.14||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch]<br />
|-<br />
|{{T42p}}||Debian||2.6.10||Debian packaged||suspend2||yes||<br />
|-<br />
|{{T43}}||Debian sid||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 (but not earlier versions!)<br />
|-<br />
|{{T43}}||Debian etch||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 and without vbetool<br />
|-<br />
|{{T43}}||Ubuntu Breezy||2.6.12-10||8.19.10||swsusp||yes||Perfect. (Finally.)<br />
|-<br />
|{{T43}}||FC4||2.6.14.1||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)<br />
|-<br />
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)<br />
|-<br />
|{{T43}}||FC4||2.6.14.3||8.19.10||suspend2 2.2-rc13||no||DRI enabled<br />
|-<br />
|{{T43}}||FC4||2.6.14.3||8.20.8||suspend2 2.2-rc13||no||DRI enabled<br />
|-<br />
|{{R50p}}||???||???||8.19.10||swsusp||yes||<br />
|-<br />
|{{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<br />
|-<br />
|{{T43p}}||Debian sid||2.6.14.3||8.20.8||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled<br />
|-<br />
|{{R52}}||Debian sid||2.6.15-rc5||8.20.8||swsup||yes||both vbetool and UseDummyXServer disabled, DRI enabled, needs [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]<br />
|}<br />
<br />
=== Troubles with large RAM ===<br />
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 <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|mem|864m}} kernel parameter.<br />
<br />
Version 8.16.20 fixes the problem.<br />
<br />
===Display switching ===<br />
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 <tt>vesa</tt> server instead (experienced with a R52, Kernel 2.6.11, xorg 6.8.2, fglrx 8.16.20).<br />
<br />
===Composite Support===<br />
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).<br />
<br />
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.<br />
<br />
There were some rumors that composite support was fast with the open-source 2d accelerated drivers in x.org 6.9 (as opposed to 6.8.x). Alas, trying this gives better results than the proprietary drivers, but it is still too slow to be reasonably useful.<br />
<br />
===Hardlock on X logout===<br />
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.<br />
<br />
In the kdm config file (gentoo: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>: <br />
TerminateServer=true<br />
<br />
In the gdm config file add:<br />
AlwaysRestartServer=true<br />
<br />
Information from the ATI bugtracker: http://ati.cchtml.com/show_bug.cgi?id=239<br />
<br />
===Error messages in system log===<br />
<br />
If you find something like the following in {{path|/var/log/messages}}:<br />
<br />
:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}<br />
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}<br />
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}<br />
<br />
try to execute the following line and reload the fglrx module:<br />
<br />
:{{cmdroot|1=echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr}}<br />
<br />
More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 here].<br />
<br />
== Patches ==<br />
The following patches might be needed for certain versions of fglrx.<br />
<br />
===fglrx 8.21.7===<br />
<br />
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]<br />
<br />
===fglrx 8.20.8===<br />
<br />
* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]<br />
or<br />
* [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch for kernels >= 2.6.15]<br />
<br />
===fglrx (problem met at least with version 8.18.8)===<br />
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug<br />
<br />
===fglrx 8.8.25 ===<br />
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]<br />
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]</div>Bluehttps://www.thinkwiki.org/w/index.php?title=How_to_use_UltraBay_batteries&diff=18992How to use UltraBay batteries2006-01-26T15:14:34Z<p>Blue: /* UtraBay eject lever */</p>
<hr />
<div>{| width="100%"<br />
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__<br />
|style="vertical-align:top" |<br />
ThinkPad laptops only charge/discharge one battery at a time. If you have two batteries present (a system battery and an [[UltraBay]] battery), the laptop will completely deplete the UltraBay battery before using the main battery.<br />
|}<br />
<br />
===Battery hot-swapping===<br />
Switching between the batteries is instant, so if you pull the UltraBay battery from the bay when it is being discharged, the system will instantly switch to the main battery. You can therefore use the UltraBay battery to hot-swap the system battery (i.e., replace it without the need to reboot, hibernate or use an external power adapter).<br />
<br />
You should issue {{cmdroot|echo eject > /proc/acpi/ibm/bay}} before removing the battery from the bay, especially if you are replacing it with a different device (requires [[ibm-acpi]]).<br />
<br />
===Charging and discharging===<br />
When charging, the system will completely charge the main battery before it starts on the UltraBay battery. When discharging, the system will completely discharge the UltraBay battery before it discharges the main battery. This greatly reduces the lifetime of the Ultrabay battery, and also reduces its usefulness for enabling hot-swapping of the system battery. There are two ways to prevent this:<br />
<br />
* Keep an eye on the charge in the UltraBay battery and physically remove it from the bay when it gets too low (or release the eject lever- see below).<br />
* Use the [[SMAPI support for Linux#Using_the_tp_smapi_module|tp_smapi]] module to control which battery is charged (<tt>inhibit_charge</tt> on the other battery) or discharged (<tt>force_discharge</tt>). This only works on some ThinkPad models - see the [[SMAPI support for Linux#Model-specific_status|model-specific status]].<br />
<br />
===UltraBay eject lever===<br />
It seems that you don't have to completely remove the UltraBay battery from the bay to stop using it. If you release the eject lever, but don't actually pull the battery from the bay, the battery is still visible to the system, but the BIOS reverses the order of use and will completely deplete the main battery before using the UltraBay battery. The order of charging is not affected. Test machine: T23. May or may not work on other models.<br />
<br />
===Reading the battery status under Linux===<br />
<br />
====Using APM====<br />
<br />
The second battery is correctly detected by the APM subsystem (if activated).<br />
<br />
====Using ACPI====<br />
<br />
The second battery is correctly detected by the ACPI subsystem (if activated). However, the Linux ACPI subsystem only scans for batteries on boot. This means that the second battery must be present at boot time, or you will not be able to get any info for it via {{path|/proc/acpi/battery/BAT1}}.<br />
<br />
With kernel 2.6.14.2 (possibly only with [[ibm-acpi]]) there is a sysfs file: {{path|/sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}}. There isn't one for BAT0, but {{cmdroot|cat /proc/acpi/battery/BAT0/*}} shows {{cmdresult|not present}} when there is no internal battery. <br />
<br />
For BAT1 all the states go to 0, critical, etc. .<br />
<br />
{{cmdroot|echo 1 > /sys/firmware/acpi/namespace/ACPI/_SB/PCI0/LPC/EC/BAT1/eject}} will remove {{path|/proc/acpi/battery/BAT1}} and turn off the UltraBay led. Interestingly the battery will still be discharging (charging not tested) until it is physically removed.<br />
<br />
Also, if you compile the battery module of ACPI as a module, boot with the UltraBay battery present, remove the UltraBay battery (without doing the eject above), {{path|/proc/acpi/battery/BAT1}} is still there, while after {{cmdroot|rmmod battery && modprobe battery}} {{path|/proc/acpi/battery/BAT1}} is gone (BAT0 is back). Put the battery back in and {{path|/proc/acpi/battery/BAT1}} is still missing, do {{cmdroot|rmmod battery && modprobe battery}} and {{path|/proc/acpi/battery/BAT1}} is back.<br />
<br />
If you boot without the second battery <tt>BAT1</tt> never appears in {{path|/proc}} or {{path|/sys}}.<br />
<br />
If you eject using the sysfs file above, <tt>BAT1</tt> disappears from both {{path|/proc}} and {{path|/sys}} and never comes back.<br />
<br />
====Using <tt>tp_smapi</tt>====<br />
<br />
Independently of APM or ACPI, the battery status is also accessible through the [[tp_smapi]] driver. The <tt>tp_smapi</tt> kernel module provides battery status (and other features) via the sysfs interface in {{path|/sys/devices/platform/smapi/BAT<nowiki>{</nowiki>0,1<nowiki>}</nowiki>}}, and includes some information not accessible through APM or ACPI (e.g., cycle count and momentary power draw). The BAT1 interface is always present, regardless of whether the battery is present, was present on boot, or was ejected using the sysfs interface above.<br />
<br />
Unfortunately, currently none of the standard battery monitoring scripts/applets use <tt>tp_smapi</tt>.</div>Bluehttps://www.thinkwiki.org/w/index.php?title=User:Blue&diff=18990User:Blue2006-01-26T15:10:11Z<p>Blue: </p>
<hr />
<div>Owning a {{T43p}} running SuSE Linux 9.2.</div>Bluehttps://www.thinkwiki.org/w/index.php?title=User:Blue&diff=18989User:Blue2006-01-26T15:09:05Z<p>Blue: </p>
<hr />
<div>Owning a T43p running SuSE Linux 9.2.</div>Bluehttps://www.thinkwiki.org/w/index.php?title=Problems_with_fglrx&diff=18986Problems with fglrx2006-01-26T15:07:32Z<p>Blue: /* Acceleration lost after driver update */</p>
<hr />
<div>This page discusses issues with the ATI proprietary [[fglrx]] display driver.<br />
<br />
== Known Troubles and Solutions ==<br />
<br />
=== X-specific issues ===<br />
<br />
The current ATI proprietary driver (8.21.7) works with x.org 6.9.<br />
<br />
If you are running an older version (8.20.8) under Debian sid and you upgrade your xserver-xorg, apt will force you to remove any debian-packaged fglrx drivers (package fglrx-driver depends on x.org << 6.8.99). You can just download the driver from the ATI site and install after modifying the Debian packager script to allow dependencies to be satisfied by x.org 6.9, or just download 8.21.7 and install manually. See talk page for step-by-step commands.<br />
<br />
After installing the fglrx driver, you can use module-assist to build the appropriate kernel module.<br />
<br />
=== Kernel-specific troubles ===<br />
<br />
Using the current ATI driver (8.21.7) with 2.6.15 or later needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead. <br />
<br />
If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|fglrxinfo}} - if your shell hangs at the end of this command, you may have an issue and should try the patch.<br />
<br />
Although unproven, there is a substantial amount of user / developer concern that the above patches prevent hard lockups but do not provide full reliability with 2.6.15 and there are larger / redisgn issues preventing compatibility. It seems surprising that ATI would not have implemented such a simple page count fix in their latest two driver releases since kernel 2.6.15 has been available. Given the closed-source nature of the driver, it is difficult to know for sure. As of now only 2.6.14.x kernels are officially supported by the fglrx driver.<br />
<br />
=== No hardware acceleration ===<br />
<br />
====Acceleration lost after driver update====<br />
If you lose hardware acceleration after a driver update this can be caused by an old fglrx kernel module being loaded.<br />
<br />
Check out {{path|1=/var/log/Xorg.0.log}} for a message like:<br />
:<code>(WW) fglrx(0): Kernel Module version does *not* match driver.</code><br />
:<code>(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work</code><br />
<br />
You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:<br />
:<code>(II) fglrx(0): Kernel Module Version Information:</code><br />
:<code>(II) fglrx(0): Name: fglrx</code><br />
:<code>(II) fglrx(0): Version: 8.10.19</code><br />
<br />
The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path.<br><br />
Go to {{path|1=/lib/modules/<your linux kernel version>/}} and type {{cmdroot|1=grep fglrx modules.dep}}.<br><br />
If grep finds multiple lines you nailed down the problem. All you have to do now is to delete any versions of the module (look at the filedate) but the most current one. Then run {{cmdroot|1=depmod}} and you are done.<br />
<br />
{{HINT|The current version (8.21.7) of the fglrx module seem to be installed in the <code>extra/</code> subdirectory.<br><br />
Older versions (8.19.10) used to be located in the <code>kernel/drivers/char/drm</code> subdirectory.}}<br />
<br />
====GCC 3.4====<br />
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|fglrx_dri.so}} was linked against libstdc++.so.5 which may not be present if your system uses gcc-3.4.<br />
<br />
To fix this, compile gcc-3.3.5 and copy <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.<br />
<br />
====radeonfb framebuffer====<br />
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 {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/etc/modules.autoload/kernel2.x}} at boottime instead.<br />
<br />
=== Softlink hell ===<br />
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.<br />
<br />
====Discussion====<br />
If using {{cmduser|fglrxinfo}} after installing [[fglrx]] indicates that you are still using the mesa indirect software GL renderer, you likely have some misplaced softlinks. It seems like it has to do with an apt-get upgrade that sometimes replaces these links. Anyway, go to<br />
:{{cmdroot|cd /usr/X11R6/lib}}<br />
and list your GL libraries and links<br />
:{{cmdroot|ls -la *GL*}}<br />
You should see something like the following two lines amoung others:<br />
:{{cmdresult|libGL.so -> libGL.so.1.2}}<br />
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}<br />
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):<br />
:{{cmdroot|ln -s libGL.so.1.2 libGL.so.1}}<br />
<br />
For some reason, this link might "break" later, giving you the software rendering once more. Even after renaming the mesa library to something like <tt>mesa.bkup</tt>, the system might still find it and link to it despite the name change. If you have to do this a lot, you could write a restoreGL script.<br />
<br />
=====Gentoo=====<br />
{{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:<br />
:{{cmdroot|opengl-update ati}} or<br />
:{{cmdroot|eselect opengl set ati}}<br />
Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. <tt>opengl-update</tt> is the old tried-and-true method for managing the symlinks. If <tt>opengl-update</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).<br />
<br />
If {{cmdroot|ldd /usr/X11R6/bin/glxinfo}} shows that your system still uses the xorg-x11 mesa libs after trying one of the above commands, i.e. a line like this:<br />
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}<br />
you will also need to relink {{path|libGl.so.1.2}}:<br />
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}<br />
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}<br />
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}<br />
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.<br />
<br />
=== Troubles using software suspend ===<br />
When the computer resumes from suspend, X only displays a garbled image and the computer is frozen.<br />
The problem is acknowledged in ATI's release notes and in knowledge base entry [https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 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.<br />
<br />
If you are using an older version of fglrx, using [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/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.<br />
<br />
{| cellspacing="0" cellpadding="2" border="1"<br />
|+ tested with the following configurations<br />
!model!!distro||kernel!!fglrx!!PM!!success!!comments<br />
|-<br />
|{{T42}}||SUSE 9.3||2.6.11||8.14.13||swsusp||yes||<br />
|-<br />
|{{T41p}}||???||2.6.14||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch]<br />
|-<br />
|{{T42p}}||Debian||2.6.10||Debian packaged||suspend2||yes||<br />
|-<br />
|{{T43}}||Debian sid||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 (but not earlier versions!)<br />
|-<br />
|{{T43}}||Debian etch||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 and without vbetool<br />
|-<br />
|{{T43}}||Ubuntu Breezy||2.6.12-10||8.19.10||swsusp||yes||Perfect. (Finally.)<br />
|-<br />
|{{T43}}||FC4||2.6.14.1||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)<br />
|-<br />
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)<br />
|-<br />
|{{T43}}||FC4||2.6.14.3||8.19.10||suspend2 2.2-rc13||no||DRI enabled<br />
|-<br />
|{{T43}}||FC4||2.6.14.3||8.20.8||suspend2 2.2-rc13||no||DRI enabled<br />
|-<br />
|{{R50p}}||???||???||8.19.10||swsusp||yes||<br />
|-<br />
|{{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<br />
|-<br />
|{{T43p}}||Debian sid||2.6.14.3||8.20.8||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled<br />
|-<br />
|{{R52}}||Debian sid||2.6.15-rc5||8.20.8||swsup||yes||both vbetool and UseDummyXServer disabled, DRI enabled, needs [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]<br />
|}<br />
<br />
=== Troubles with large RAM ===<br />
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 <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|mem|864m}} kernel parameter.<br />
<br />
Version 8.16.20 fixes the problem.<br />
<br />
===Display switching ===<br />
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 <tt>vesa</tt> server instead (experienced with a R52, Kernel 2.6.11, xorg 6.8.2, fglrx 8.16.20).<br />
<br />
===Composite Support===<br />
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).<br />
<br />
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.<br />
<br />
There were some rumors that composite support was fast with the open-source 2d accelerated drivers in x.org 6.9 (as opposed to 6.8.x). Alas, trying this gives better results than the proprietary drivers, but it is still too slow to be reasonably useful.<br />
<br />
===Hardlock on X logout===<br />
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.<br />
<br />
In the kdm config file (gentoo: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>: <br />
TerminateServer=true<br />
<br />
In the gdm config file add:<br />
AlwaysRestartServer=true<br />
<br />
Information from the ATI bugtracker: http://ati.cchtml.com/show_bug.cgi?id=239<br />
<br />
===Error messages in system log===<br />
<br />
If you find something like the following in {{path|/var/log/messages}}:<br />
<br />
:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}<br />
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}<br />
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}<br />
<br />
try to execute the following line and reload the fglrx module:<br />
<br />
:{{cmdroot|1=echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr}}<br />
<br />
More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 here].<br />
<br />
== Patches ==<br />
The following patches might be needed for certain versions of fglrx.<br />
<br />
===fglrx 8.20.8===<br />
<br />
* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]<br />
<br />
===fglrx (problem met at least with version 8.18.8)===<br />
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug<br />
<br />
===fglrx 8.8.25 ===<br />
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]<br />
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]</div>Bluehttps://www.thinkwiki.org/w/index.php?title=Problems_with_fglrx&diff=18984Problems with fglrx2006-01-26T15:04:56Z<p>Blue: /* No hardware acceleration */</p>
<hr />
<div>This page discusses issues with the ATI proprietary [[fglrx]] display driver.<br />
<br />
== Known Troubles and Solutions ==<br />
<br />
=== X-specific issues ===<br />
<br />
The current ATI proprietary driver (8.21.7) works with x.org 6.9.<br />
<br />
If you are running an older version (8.20.8) under Debian sid and you upgrade your xserver-xorg, apt will force you to remove any debian-packaged fglrx drivers (package fglrx-driver depends on x.org << 6.8.99). You can just download the driver from the ATI site and install after modifying the Debian packager script to allow dependencies to be satisfied by x.org 6.9, or just download 8.21.7 and install manually. See talk page for step-by-step commands.<br />
<br />
After installing the fglrx driver, you can use module-assist to build the appropriate kernel module.<br />
<br />
=== Kernel-specific troubles ===<br />
<br />
Using the current ATI driver (8.21.7) with 2.6.15 or later needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead. <br />
<br />
If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|fglrxinfo}} - if your shell hangs at the end of this command, you may have an issue and should try the patch.<br />
<br />
Although unproven, there is a substantial amount of user / developer concern that the above patches prevent hard lockups but do not provide full reliability with 2.6.15 and there are larger / redisgn issues preventing compatibility. It seems surprising that ATI would not have implemented such a simple page count fix in their latest two driver releases since kernel 2.6.15 has been available. Given the closed-source nature of the driver, it is difficult to know for sure. As of now only 2.6.14.x kernels are officially supported by the fglrx driver.<br />
<br />
=== No hardware acceleration ===<br />
<br />
====Acceleration lost after driver update====<br />
If you lose hardware acceleration after a driver update this can be caused by an old fglrx kernel module being loaded.<br />
<br />
Check out {{path|/var/log/Xorg.0.log}} for a message like:<br />
:<code>(WW) fglrx(0): Kernel Module version does *not* match driver.</code><br />
:<code>(EE) fglrx(0): incompatible kernel module detected - HW accelerated OpenGL will not work</code><br />
<br />
You can verify this yourself by looking at the version message some lines above. It should read something not matching the installed version like:<br />
:<code>(II) fglrx(0): Kernel Module Version Information:</code><br />
:<code>(II) fglrx(0): Name: fglrx</code><br />
:<code>(II) fglrx(0): Version: 8.10.19</code><br />
<br />
The cause for this trouble might be that there resist multiple versions of the fglrx module within the kernel module search path.<br><br />
Go to {{path|/lib/modules/<your linux kernel version>/}} and type {{cmdroot|<nowiki>grep fglrx modules.dep</nowiki>}}.<br><br />
If grep finds multiple lines you nailed down the problem. All you have to do now is to delete any versions of the module (look at the filedate) but the most current one. Then run {{cmdroot|depmod}} and you are done.<br />
<br />
{{HINT|The current version (8.21.7) of the fglrx module seem to be installed in the <code>extra/</code> subdirectory.<br><br />
Older versions (8.19.10) used to be located in the <code>kernel/drivers/char/drm</code> subdirectory.}}<br />
<br />
<br />
====GCC 3.4====<br />
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|fglrx_dri.so}} was linked against libstdc++.so.5 which may not be present if your system uses gcc-3.4.<br />
<br />
To fix this, compile gcc-3.3.5 and copy <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.<br />
<br />
====radeonfb framebuffer====<br />
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 {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/etc/modules.autoload/kernel2.x}} at boottime instead.<br />
<br />
=== Softlink hell ===<br />
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.<br />
<br />
====Discussion====<br />
If using {{cmduser|fglrxinfo}} after installing [[fglrx]] indicates that you are still using the mesa indirect software GL renderer, you likely have some misplaced softlinks. It seems like it has to do with an apt-get upgrade that sometimes replaces these links. Anyway, go to<br />
:{{cmdroot|cd /usr/X11R6/lib}}<br />
and list your GL libraries and links<br />
:{{cmdroot|ls -la *GL*}}<br />
You should see something like the following two lines amoung others:<br />
:{{cmdresult|libGL.so -> libGL.so.1.2}}<br />
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}<br />
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):<br />
:{{cmdroot|ln -s libGL.so.1.2 libGL.so.1}}<br />
<br />
For some reason, this link might "break" later, giving you the software rendering once more. Even after renaming the mesa library to something like <tt>mesa.bkup</tt>, the system might still find it and link to it despite the name change. If you have to do this a lot, you could write a restoreGL script.<br />
<br />
=====Gentoo=====<br />
{{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:<br />
:{{cmdroot|opengl-update ati}} or<br />
:{{cmdroot|eselect opengl set ati}}<br />
Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. <tt>opengl-update</tt> is the old tried-and-true method for managing the symlinks. If <tt>opengl-update</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).<br />
<br />
If {{cmdroot|ldd /usr/X11R6/bin/glxinfo}} shows that your system still uses the xorg-x11 mesa libs after trying one of the above commands, i.e. a line like this:<br />
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}<br />
you will also need to relink {{path|libGl.so.1.2}}:<br />
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}<br />
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}<br />
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}<br />
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.<br />
<br />
=== Troubles using software suspend ===<br />
When the computer resumes from suspend, X only displays a garbled image and the computer is frozen.<br />
The problem is acknowledged in ATI's release notes and in knowledge base entry [https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 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.<br />
<br />
If you are using an older version of fglrx, using [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/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.<br />
<br />
{| cellspacing="0" cellpadding="2" border="1"<br />
|+ tested with the following configurations<br />
!model!!distro||kernel!!fglrx!!PM!!success!!comments<br />
|-<br />
|{{T42}}||SUSE 9.3||2.6.11||8.14.13||swsusp||yes||<br />
|-<br />
|{{T41p}}||???||2.6.14||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch]<br />
|-<br />
|{{T42p}}||Debian||2.6.10||Debian packaged||suspend2||yes||<br />
|-<br />
|{{T43}}||Debian sid||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 (but not earlier versions!)<br />
|-<br />
|{{T43}}||Debian etch||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 and without vbetool<br />
|-<br />
|{{T43}}||Ubuntu Breezy||2.6.12-10||8.19.10||swsusp||yes||Perfect. (Finally.)<br />
|-<br />
|{{T43}}||FC4||2.6.14.1||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)<br />
|-<br />
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)<br />
|-<br />
|{{T43}}||FC4||2.6.14.3||8.19.10||suspend2 2.2-rc13||no||DRI enabled<br />
|-<br />
|{{T43}}||FC4||2.6.14.3||8.20.8||suspend2 2.2-rc13||no||DRI enabled<br />
|-<br />
|{{R50p}}||???||???||8.19.10||swsusp||yes||<br />
|-<br />
|{{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<br />
|-<br />
|{{T43p}}||Debian sid||2.6.14.3||8.20.8||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled<br />
|-<br />
|{{R52}}||Debian sid||2.6.15-rc5||8.20.8||swsup||yes||both vbetool and UseDummyXServer disabled, DRI enabled, needs [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]<br />
|}<br />
<br />
=== Troubles with large RAM ===<br />
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 <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|mem|864m}} kernel parameter.<br />
<br />
Version 8.16.20 fixes the problem.<br />
<br />
===Display switching ===<br />
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 <tt>vesa</tt> server instead (experienced with a R52, Kernel 2.6.11, xorg 6.8.2, fglrx 8.16.20).<br />
<br />
===Composite Support===<br />
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).<br />
<br />
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.<br />
<br />
There were some rumors that composite support was fast with the open-source 2d accelerated drivers in x.org 6.9 (as opposed to 6.8.x). Alas, trying this gives better results than the proprietary drivers, but it is still too slow to be reasonably useful.<br />
<br />
===Hardlock on X logout===<br />
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.<br />
<br />
In the kdm config file (gentoo: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>: <br />
TerminateServer=true<br />
<br />
In the gdm config file add:<br />
AlwaysRestartServer=true<br />
<br />
Information from the ATI bugtracker: http://ati.cchtml.com/show_bug.cgi?id=239<br />
<br />
===Error messages in system log===<br />
<br />
If you find something like the following in {{path|/var/log/messages}}:<br />
<br />
:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}<br />
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}<br />
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}<br />
<br />
try to execute the following line and reload the fglrx module:<br />
<br />
:{{cmdroot|1=echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr}}<br />
<br />
More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 here].<br />
<br />
== Patches ==<br />
The following patches might be needed for certain versions of fglrx.<br />
<br />
===fglrx 8.20.8===<br />
<br />
* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]<br />
<br />
===fglrx (problem met at least with version 8.18.8)===<br />
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug<br />
<br />
===fglrx 8.8.25 ===<br />
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]<br />
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]</div>Bluehttps://www.thinkwiki.org/w/index.php?title=Problems_with_fglrx&diff=18979Problems with fglrx2006-01-26T13:24:51Z<p>Blue: /* Error messages in system log */</p>
<hr />
<div>This page discusses issues with the ATI proprietary [[fglrx]] display driver.<br />
<br />
== Known Troubles and Solutions ==<br />
<br />
=== X-specific issues ===<br />
<br />
The current ATI proprietary driver (8.21.7) works with x.org 6.9.<br />
<br />
If you are running an older version (8.20.8) under Debian sid and you upgrade your xserver-xorg, apt will force you to remove any debian-packaged fglrx drivers (package fglrx-driver depends on x.org << 6.8.99). You can just download the driver from the ATI site and install after modifying the Debian packager script to allow dependencies to be satisfied by x.org 6.9, or just download 8.21.7 and install manually. See talk page for step-by-step commands.<br />
<br />
After installing the fglrx driver, you can use module-assist to build the appropriate kernel module.<br />
<br />
=== Kernel-specific troubles ===<br />
<br />
Using the current ATI driver (8.21.7) with 2.6.15 or later needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead. <br />
<br />
If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|fglrxinfo}} - if your shell hangs at the end of this command, you may have an issue and should try the patch.<br />
<br />
Although unproven, there is a substantial amount of user / developer concern that the above patches prevent hard lockups but do not provide full reliability with 2.6.15 and there are larger / redisgn issues preventing compatibility. It seems surprising that ATI would not have implemented such a simple page count fix in their latest two driver releases since kernel 2.6.15 has been available. Given the closed-source nature of the driver, it is difficult to know for sure. As of now only 2.6.14.x kernels are officially supported by the fglrx driver.<br />
<br />
=== No hardware acceleration ===<br />
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|fglrx_dri.so}} was linked against libstdc++.so.5 which may not be present if your system uses gcc-3.4.<br />
<br />
To fix this, compile gcc-3.3.5 and copy <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.<br />
<br />
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 {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/etc/modules.autoload/kernel2.x}} at boottime instead.<br />
<br />
=== Softlink hell ===<br />
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.<br />
<br />
====Discussion====<br />
If using {{cmduser|fglrxinfo}} after installing [[fglrx]] indicates that you are still using the mesa indirect software GL renderer, you likely have some misplaced softlinks. It seems like it has to do with an apt-get upgrade that sometimes replaces these links. Anyway, go to<br />
:{{cmdroot|cd /usr/X11R6/lib}}<br />
and list your GL libraries and links<br />
:{{cmdroot|ls -la *GL*}}<br />
You should see something like the following two lines amoung others:<br />
:{{cmdresult|libGL.so -> libGL.so.1.2}}<br />
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}<br />
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):<br />
:{{cmdroot|ln -s libGL.so.1.2 libGL.so.1}}<br />
<br />
For some reason, this link might "break" later, giving you the software rendering once more. Even after renaming the mesa library to something like <tt>mesa.bkup</tt>, the system might still find it and link to it despite the name change. If you have to do this a lot, you could write a restoreGL script.<br />
<br />
=====Gentoo=====<br />
{{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:<br />
:{{cmdroot|opengl-update ati}} or<br />
:{{cmdroot|eselect opengl set ati}}<br />
Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. <tt>opengl-update</tt> is the old tried-and-true method for managing the symlinks. If <tt>opengl-update</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).<br />
<br />
If {{cmdroot|ldd /usr/X11R6/bin/glxinfo}} shows that your system still uses the xorg-x11 mesa libs after trying one of the above commands, i.e. a line like this:<br />
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}<br />
you will also need to relink {{path|libGl.so.1.2}}:<br />
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}<br />
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}<br />
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}<br />
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.<br />
<br />
=== Troubles using software suspend ===<br />
When the computer resumes from suspend, X only displays a garbled image and the computer is frozen.<br />
The problem is acknowledged in ATI's release notes and in knowledge base entry [https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 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.<br />
<br />
If you are using an older version of fglrx, using [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/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.<br />
<br />
{| cellspacing="0" cellpadding="2" border="1"<br />
|+ tested with the following configurations<br />
!model!!distro||kernel!!fglrx!!PM!!success!!comments<br />
|-<br />
|{{T42}}||SUSE 9.3||2.6.11||8.14.13||swsusp||yes||<br />
|-<br />
|{{T41p}}||???||2.6.14||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch]<br />
|-<br />
|{{T42p}}||Debian||2.6.10||Debian packaged||suspend2||yes||<br />
|-<br />
|{{T43}}||Debian sid||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 (but not earlier versions!)<br />
|-<br />
|{{T43}}||Debian etch||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 and without vbetool<br />
|-<br />
|{{T43}}||Ubuntu Breezy||2.6.12-10||8.19.10||swsusp||yes||Perfect. (Finally.)<br />
|-<br />
|{{T43}}||FC4||2.6.14.1||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)<br />
|-<br />
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)<br />
|-<br />
|{{T43}}||FC4||2.6.14.3||8.19.10||suspend2 2.2-rc13||no||DRI enabled<br />
|-<br />
|{{T43}}||FC4||2.6.14.3||8.20.8||suspend2 2.2-rc13||no||DRI enabled<br />
|-<br />
|{{R50p}}||???||???||8.19.10||swsusp||yes||<br />
|-<br />
|{{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<br />
|-<br />
|{{T43p}}||Debian sid||2.6.14.3||8.20.8||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled<br />
|-<br />
|{{R52}}||Debian sid||2.6.15-rc5||8.20.8||swsup||yes||both vbetool and UseDummyXServer disabled, DRI enabled, needs [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]<br />
|}<br />
<br />
=== Troubles with large RAM ===<br />
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 <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|mem|864m}} kernel parameter.<br />
<br />
Version 8.16.20 fixes the problem.<br />
<br />
===Display switching ===<br />
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 <tt>vesa</tt> server instead (experienced with a R52, Kernel 2.6.11, xorg 6.8.2, fglrx 8.16.20).<br />
<br />
===Composite Support===<br />
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).<br />
<br />
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.<br />
<br />
There were some rumors that composite support was fast with the open-source 2d accelerated drivers in x.org 6.9 (as opposed to 6.8.x). Alas, trying this gives better results than the proprietary drivers, but it is still too slow to be reasonably useful.<br />
<br />
===Hardlock on X logout===<br />
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.<br />
<br />
In the kdm config file (gentoo: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>: <br />
TerminateServer=true<br />
<br />
In the gdm config file add:<br />
AlwaysRestartServer=true<br />
<br />
Information from the ATI bugtracker: http://ati.cchtml.com/show_bug.cgi?id=239<br />
<br />
===Error messages in system log===<br />
<br />
If you find something like the following in {{path|/var/log/messages}}:<br />
<br />
:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}<br />
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}<br />
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}<br />
<br />
try to execute the following line and reload the fglrx module:<br />
<br />
:{{cmdroot|<nowiki>echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr</nowiki>}}<br />
<br />
More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 here].<br />
<br />
== Patches ==<br />
The following patches might be needed for certain versions of fglrx.<br />
<br />
===fglrx 8.20.8===<br />
<br />
* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]<br />
<br />
===fglrx (problem met at least with version 8.18.8)===<br />
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug<br />
<br />
===fglrx 8.8.25 ===<br />
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]<br />
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]</div>Bluehttps://www.thinkwiki.org/w/index.php?title=Problems_with_fglrx&diff=18978Problems with fglrx2006-01-26T13:20:52Z<p>Blue: /* Known Troubles and Solutions */</p>
<hr />
<div>This page discusses issues with the ATI proprietary [[fglrx]] display driver.<br />
<br />
== Known Troubles and Solutions ==<br />
<br />
=== X-specific issues ===<br />
<br />
The current ATI proprietary driver (8.21.7) works with x.org 6.9.<br />
<br />
If you are running an older version (8.20.8) under Debian sid and you upgrade your xserver-xorg, apt will force you to remove any debian-packaged fglrx drivers (package fglrx-driver depends on x.org << 6.8.99). You can just download the driver from the ATI site and install after modifying the Debian packager script to allow dependencies to be satisfied by x.org 6.9, or just download 8.21.7 and install manually. See talk page for step-by-step commands.<br />
<br />
After installing the fglrx driver, you can use module-assist to build the appropriate kernel module.<br />
<br />
=== Kernel-specific troubles ===<br />
<br />
Using the current ATI driver (8.21.7) with 2.6.15 or later needs a [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]. (see table below for detail.) If you can't compile the driver modules with 2.6.15 or later, you should apply this [http://www.ksp.sk/~rasto/fglrx_with_2.6.15.patch patch] instead. <br />
<br />
If you do not use one of these patches, you may experience peculiar lockups of X. Try {{cmduser|fglrxinfo}} - if your shell hangs at the end of this command, you may have an issue and should try the patch.<br />
<br />
Although unproven, there is a substantial amount of user / developer concern that the above patches prevent hard lockups but do not provide full reliability with 2.6.15 and there are larger / redisgn issues preventing compatibility. It seems surprising that ATI would not have implemented such a simple page count fix in their latest two driver releases since kernel 2.6.15 has been available. Given the closed-source nature of the driver, it is difficult to know for sure. As of now only 2.6.14.x kernels are officially supported by the fglrx driver.<br />
<br />
=== No hardware acceleration ===<br />
If the ATI driver works only without the hardware acceleration, take into consideration that {{path|fglrx_dri.so}} was linked against libstdc++.so.5 which may not be present if your system uses gcc-3.4.<br />
<br />
To fix this, compile gcc-3.3.5 and copy <tt>libstdc++.so.5*</tt> to {{path|/usr/lib}} and update the dynamic linker cache via {{cmdroot|ldconfig}}.<br />
<br />
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 {{cmdroot|modprobe fglrx}} after boot but to have the module loaded via {{path|/etc/modules.autoload/kernel2.x}} at boottime instead.<br />
<br />
=== Softlink hell ===<br />
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.<br />
<br />
====Discussion====<br />
If using {{cmduser|fglrxinfo}} after installing [[fglrx]] indicates that you are still using the mesa indirect software GL renderer, you likely have some misplaced softlinks. It seems like it has to do with an apt-get upgrade that sometimes replaces these links. Anyway, go to<br />
:{{cmdroot|cd /usr/X11R6/lib}}<br />
and list your GL libraries and links<br />
:{{cmdroot|ls -la *GL*}}<br />
You should see something like the following two lines amoung others:<br />
:{{cmdresult|libGL.so -> libGL.so.1.2}}<br />
:{{cmdresult|libGL.so.1 -> libGL.so.1.2}}<br />
If you see a link to a mesa library (something like {{cmdresult|... -> libGL.mesa.1.2}}), then that's your problem! Restore the softlink like this (use your actual library version, though):<br />
:{{cmdroot|ln -s libGL.so.1.2 libGL.so.1}}<br />
<br />
For some reason, this link might "break" later, giving you the software rendering once more. Even after renaming the mesa library to something like <tt>mesa.bkup</tt>, the system might still find it and link to it despite the name change. If you have to do this a lot, you could write a restoreGL script.<br />
<br />
=====Gentoo=====<br />
{{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:<br />
:{{cmdroot|opengl-update ati}} or<br />
:{{cmdroot|eselect opengl set ati}}<br />
Eselect is new, and still ~x86 (as of the end of 2005), so you may not have it yet. <tt>opengl-update</tt> is the old tried-and-true method for managing the symlinks. If <tt>opengl-update</tt> doesn't fix it for you, you should probably tell [http://bugs.gentoo.org Gentoo Bugzilla] (assuming they don't know yet).<br />
<br />
If {{cmdroot|ldd /usr/X11R6/bin/glxinfo}} shows that your system still uses the xorg-x11 mesa libs after trying one of the above commands, i.e. a line like this:<br />
:{{cmdresult|1=libGL.so.1 => /usr/lib/opengl/xorg-x11/lib/libGL.so.1 (0x400a8000)}}<br />
you will also need to relink {{path|libGl.so.1.2}}:<br />
:{{cmdroot|cd /usr/lib/opengl/xorg-x11/lib/}}<br />
:{{cmdroot|mv libGL.so.1.2 libGL.so.1.2_backup}}<br />
:{{cmdroot|ln -s /usr/lib/libGL.so.1.2 libGL.so.1.2}}<br />
After another restart of X {{cmduser|fglrxinfo}} should show that it's using the right libs now.<br />
<br />
=== Troubles using software suspend ===<br />
When the computer resumes from suspend, X only displays a garbled image and the computer is frozen.<br />
The problem is acknowledged in ATI's release notes and in knowledge base entry [https://support.ati.com/ics/support/KBResult.asp?searchFor=Search+Words&search.x=0&search.y=0&searchOption=id&questionID=737-218+&task=knowledge&searchTime=-1&productID=&folderID=-1&resultLimit=50 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.<br />
<br />
If you are using an older version of fglrx, using [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to save/restore the video card state before/after suspend worked for some people. If you use [[Software Suspend 2|Software Suspend 2 (suspend2)]] scripts, you can simply uncomment <tt>EnableVbetool yes</tt> in {{path|/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.<br />
<br />
{| cellspacing="0" cellpadding="2" border="1"<br />
|+ tested with the following configurations<br />
!model!!distro||kernel!!fglrx!!PM!!success!!comments<br />
|-<br />
|{{T42}}||SUSE 9.3||2.6.11||8.14.13||swsusp||yes||<br />
|-<br />
|{{T41p}}||???||2.6.14||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch]<br />
|-<br />
|{{T42p}}||Debian||2.6.10||Debian packaged||suspend2||yes||<br />
|-<br />
|{{T43}}||Debian sid||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 (but not earlier versions!)<br />
|-<br />
|{{T43}}||Debian etch||2.6.14.2||8.19.10||swsusp||yes||works perfectly with 8.19.10 and without vbetool<br />
|-<br />
|{{T43}}||Ubuntu Breezy||2.6.12-10||8.19.10||swsusp||yes||Perfect. (Finally.)<br />
|-<br />
|{{T43}}||FC4||2.6.14.1||8.19.10||suspend2 2.2-rc9||yes||needs a small [http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2005-November/030381.html patch], requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)<br />
|-<br />
|{{T43}}||FC4||2.6.14.2||8.19.10||suspend2 2.2-rc11||yes||requires DRI disabled in {{path|xorg.conf}} (hence no 3D acceleration)<br />
|-<br />
|{{T43}}||FC4||2.6.14.3||8.19.10||suspend2 2.2-rc13||no||DRI enabled<br />
|-<br />
|{{T43}}||FC4||2.6.14.3||8.20.8||suspend2 2.2-rc13||no||DRI enabled<br />
|-<br />
|{{R50p}}||???||???||8.19.10||swsusp||yes||<br />
|-<br />
|{{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<br />
|-<br />
|{{T43p}}||Debian sid||2.6.14.3||8.20.8||Suspend to RAM||yes||without vbetool or UseDummyXServer, with DRI enabled<br />
|-<br />
|{{R52}}||Debian sid||2.6.15-rc5||8.20.8||swsup||yes||both vbetool and UseDummyXServer disabled, DRI enabled, needs [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 patch]<br />
|}<br />
<br />
=== Troubles with large RAM ===<br />
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 <tt>fglrx</tt> kernel module is loaded, but independently of whether {{kernelconf|CONFIG_HIGHMEM||||||}} is enabled. A workaround is to limit RAM by adding the {{bootparm|mem|864m}} kernel parameter.<br />
<br />
Version 8.16.20 fixes the problem.<br />
<br />
===Display switching ===<br />
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 <tt>vesa</tt> server instead (experienced with a R52, Kernel 2.6.11, xorg 6.8.2, fglrx 8.16.20).<br />
<br />
===Composite Support===<br />
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).<br />
<br />
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.<br />
<br />
There were some rumors that composite support was fast with the open-source 2d accelerated drivers in x.org 6.9 (as opposed to 6.8.x). Alas, trying this gives better results than the proprietary drivers, but it is still too slow to be reasonably useful.<br />
<br />
===Hardlock on X logout===<br />
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.<br />
<br />
In the kdm config file (gentoo: {{path|/usr/kde/<VERSION>/share/config/kdm/kdmrc}}) you have to add following to the section <code>[X-:*-Core]</code>: <br />
TerminateServer=true<br />
<br />
In the gdm config file add:<br />
AlwaysRestartServer=true<br />
<br />
Information from the ATI bugtracker: http://ati.cchtml.com/show_bug.cgi?id=239<br />
<br />
===Error messages in system log===<br />
<br />
If you find something like the following in {{path|/var/log/messages}}:<br />
<br />
:{{cmdresult|kernel: mtrr: base(0xc0000000) is not aligned on a size(0x7ff0000) boundary}}<br />
:{{cmdresult|kernel: [fglrx:firegl_addmap] *ERROR* mtrr allocation failed (-22)}}<br />
:{{cmdresult|kernel: [fglrx:firegl_unlock] *ERROR* Process 5132 using kernel context 0}}<br />
<br />
try to execute the following line and reload the fglrx module:<br />
<br />
:{{cmd|<nowiki>echo "base=0xd0000000 size=0x8000000 type=write-combining" > /proc/mtrr</nowiki>}}<br />
<br />
More detailed instructions can be found [http://ubuntuforums.org/showthread.php?t=115104 here].<br />
<br />
== Patches ==<br />
The following patches might be needed for certain versions of fglrx.<br />
<br />
===fglrx 8.20.8===<br />
<br />
* [http://marc.theaimsgroup.com/?l=linux-kernel&m=113429835515001&w=2 for kernel 2.6.15]<br />
<br />
===fglrx (problem met at least with version 8.18.8)===<br />
* [http://lkml.org/lkml/2005/9/22/183 for kernel >= 2.6.13 ] Missing verify_area bug<br />
<br />
===fglrx 8.8.25 ===<br />
* [http://www.rage3d.com/board/showthread.php?t=33798874 for kernels >= 2.6.10]<br />
* [http://www.gehirn.org.uk/wiki/images/8.8.25-kernel-2.6.11+.patch For kernels >= 2.6.11-rc1]</div>Blue