ThinkWiki - User contributions [en]

Fglrx

2006-11-11T19:13:11Z

Wilmer: /* ThinkPads that are NOT supported by fglrx */

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
== ATI fglrx driver ==
This is a proprietary Linux binary-only driver for ATI graphic chips with support for 3D acceleration.

Also see [[R300|opensource driver]] with 3D support
|}

==Availability / Project Homepage==
Home page: https://support.ati.com/ics/support/default.asp?deptID=894&task=knowledge&folderID=356

== Packages ==
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]

*{{Debian}} packages: http://www.stanchina.net/~flavio/debian-official/fglrx-driver.html
** These packages have been added to Debian unstable as <tt>fglrx-driver</tt>, so you can now apt-get them and use module-assistant to install.
** If you are on stable sarge with backport's kernel 2.6.15, download ATI's installer, 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.
*{{SUSE}} packages: http://www.suse.de/~sndirsch/ati-installer-HOWTO.html
*{{Gentoo}} {{cmdroot|emerge x11-drivers/ati-drivers}}
*{{Fedora}} 4 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install kernel-module-fglrx-$(uname -r) ati-fglrx }}
** For custom-compiled kernels: see [[How to build custom packages for fglrx]]
*{{Fedora}} 5 packages: http://rpm.livna.org
** For stock Fedora kernels: {{cmdroot|yum install xorg-x11-drv-fglrx}}
** For custom-compiled kernels: see [[How to build custom packages for fglrx]]
*{{Arch Linux}}
:{{cmdroot|pacman -S ati-fglrx}} (kernel module for 2.6.15-ARCH)
:{{cmdroot|pacman -S ati-fglrx-archck}} (kernel module for 2.6.15-archck)
:{{cmdroot|pacman -S ati-fglrx-utils}} (xorg7 stuff and tools)
*{{Ubuntu}}
**[http://wiki.cchtml.com/index.php/Ubuntu_Dapper_Installation_Guide Dapper Drake Howto]
**[http://wiki.cchtml.com/index.php/Ubuntu_Breezy_Installation_Guide Breezy Badger Howto]

== Building for Xorg 7.0==
To compile fglrx versions <= 8.24.8 for Xorg 7.0.0, fake Xorg 6.9.0 by
:{{cmdroot|1=export X_VERSION=x690; sh ati-driver-installer-8.24.8-x86.run}}
Next, move the various resulting libraries and modules from /usr/X11R6 to /usr/lib/xorg

In {{path|/usr/src/ATI}} additional sources are installed for fireglcontrol and fgl_glxgears

== Status ==
Current version: 8.30.3 (31st October 2006)

Major changes:
* 8.30.3: no new features, only bugfixes
* 8.29.6: Linux 2.6.18 support, dropped support for Radeon 8500/9000/9100/9200/9250 (both, mobile and normal versions)
* 8.28.8: Display Switching Support for ThinkPads, ATI Pairmode support, Retaining display device state between restarts, Support for Radeon Xpress 1200, 1250, and 1300
* 8.27.10: X.org 7.1 support, Fedora Core package support
* 8.26.18: support for dynamically attached DFPs and Thermal Event Power Management (both via daemon), minor bug fixes
* 8.25.18: Xorg 7.0 support, FireGLâ„¢V5xxx/V7xxx support, Dynamic Display Management, fixed a lot of critical bugs.
* 8.24.8: support for X1300, X1400, X1600, X1800 (generic and mobility) and 3D accelerated video playback on Avivo
* 8.23.7: support for X850 and X800, OpenGL 2.0 Enhancement, FSAA for some chips
* 8.22.5: added kernel 2.6.15 support -- patch no longer required
* 8.21.7: initial OpenGL 2.0 support
* 8.20.8: fixed resume issues, fixed compile problems with kernels 2.6.13 and 2.6.14
* 8.19.10: has added suspend / resume and dynamic GPU power management support. Using vbetool no longer required.

== Known problems and solutions ==
See [[Problems with fglrx]].
== User experience ==
=== Speed ===
How much is the speed gain versus the opensource drivers?

Compared to the old drivers, approximately 40% speed gain have been noticed with fglrx. However, there are issues with freezing/garbage after suspend, garbage when resizing desktop (via {{key|ctrl}}{{key|alt}}{{key|plus}}, {{key|ctrl}}{{key|alt}}{{key|minus}}), and garbage while using VMware. The current 8.14.13 has shown 400% improvement over using the open source radeon driver: 1200 FPS for glxgears{{footnote|1}}!
However the situation seems to be changing today. With recent x11-drm-20060608 driver (gentoo) and thinkpad t42 (ati 9600) the speed is confirmed as 1900fps without any single crash so far.

{{NOTE|1=Video overlay acceleration may be disabled when 3D acceleration is enabled. The following comment from the xorg.conf file bundled with the fglrx driver indicates that:
# === OpenGL Overlay ===
# Note: When OpenGL Overlay is enabled, Video Overlay
# will be disabled automatically
Option "OpenGLOverlay" "1"
However, you can use either regular Xv video overlay or make the video an opengl texture and let the OpenGL engine scale your video. This has nothing to do with the acceleration of 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.}}

=== Power saving ===
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]]).

=== Display Switching (Dynamic Display Management) ===

Version 8.25.18 introduces a new feature: Dynamic Display Management. It allows display switching on-the-fly.

To list all connected and enabled monitors:
:{{cmdroot|1=aticonfig --query-monitor}}

To switch displays:
:{{cmdroot|1=aticonfig --enable-monitor=STRING,STRING}}, where STRING can be: none, lvds, crt1, crt2, tv, tdms1, tdms2

Only 2 displays can be enabled at the same time. Any displays that are not on the list will be disabled.

== Useful links ==
* [http://www.ati.com/products/catalyst/linux.html ATI Linux Driver FAQ]
* [http://www.rage3d.com/content/articles/atilinuxhowto/ ATI Radeon Linux How-To]
* [http://www.rage3d.com/board/forumdisplay.php?f=61&daysprune=30&order=asc&sort=title Rage3D Linux Discussion Forum]
* [http://www.driverheaven.net/forumdisplay.php?f=103 Radeon Driver Forum at Driverheaven]
* [http://odin.prohosting.com/wedge01/gentoo-radeon-faq.html Gentoo ATI Radeon FAQ]
* [http://forums.gentoo.org/viewtopic-t-374745-highlight-t42+ati+dri.html Gentoo T42 ATI. DRI + xorg driver]
* [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]).

== ThinkPads that may be supported ==
Supported chips, as found in select IBM ThinkPads:
{{NOTE|fglrx version 8.29.6 discontinued support for Radeon 9200 and earlier.}}
* [[ATI Mobility FireGL 9000]]
** {{T40p}}
* [[ATI Mobility FireGL T2]]
** {{R50p}}
** {{T41p}}, {{T42p}}
* [[ATI Mobility FireGL V3200]]
** {{T43p}}
* [[ATI Mobility Radeon 9000]]
** {{R50}}, {{R51}}
** {{T40}}, {{T41}}, {{T42}}
* [[ATI Mobility Radeon 9600]]
** {{T42}}
* [[ATI Mobility Radeon X300]]
** {{R52}}
** {{T43}}
** {{Z60m}}
* [[ATI Mobility Radeon Xpress 200M]]
** {{R51e}}
* [[ATI Mobility Radeon X600]]
** {{Z60m}}
* [[ATI Mobility Radeon X1400]]
** {{T60}}, {{R60}}, {{Z61m}}
* [[ATI Mobility FireGL V5200]]
** {{T60p}}

== ThinkPads that are NOT supported by fglrx==
Unsupported chips, as found in select IBM ThinkPads:
* [[ATI Mobility Radeon 7500]]
** {{R40}}
** {{T30}}
** {{T42}}

{{footnotes|
#Note that glxgears isn't a benchmark tool, it's so simple that its FPS values 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 happen to have the opposite effects. Think in terms of a car engines rpms: higher rpms in the same car usually means a faster car, change anything and it's meaningless, ie: gears, truck, wheel size, etc. make it useless.
}}
[[Category:Drivers]]

Problem with high power drain in ACPI sleep

2006-08-07T18:32:44Z

Wilmer: Added 2373-JTU

{| width="100%"
|style="vertical-align:top;padding-right:20px;width:10px;white-space:nowrap;" | __TOC__
|style="vertical-align:top" |
==Problem description==
Several people realized that their ThinkPads eat up too much power while suspended to ram via ACPI. Compared to APM suspend to ram the power drain is experienced to be about 10 times as high, 2-5 Watts. This empties the battery within one or two days.
|}

==Affected Models==
{| border="1" cellspacing="0" cellpadding="2" style="float:right;margin-left:20px;"
|-
! style="vertical-align:top;background-color:#ffcfbc;" | affected models
! style="vertical-align:top;background-color:#cfefcf;" | unaffected models
|-
| style="vertical-align:top;background-color:#fff0e0;" |
* {{R32}}
** 2658-BQG
* {{R40}}
** 2722-3GG
** 2722-5MG
** 2722-B3G
** 2722-CDG
** 2897-GWU
** 2722-6YU
** 2722-CDG
* {{R50}}
** 1829-7RG
** 1829-6DM
** 1836-3SU
* {{R51}}
** 1829-9MG
** 1829-EHG
** 1829-R6G
** 1830-DG4
** 1836-Q6U
* {{T23}}
**2647-???
* {{T30}}
** 2366-81A
** 2366-97U
** 2366-FBU
** 2366-96G
*{{T40}}
**2373-19G
**2373-22G
**2373-42G
**2373-75G
**2373-82U
**2373-92U
**2373-A1U
**2373-MU3
*{{T40p}}
**2373-G1U
**2373-G3U
**2373-G3G
**2373-G1G
**2373-G5G
* {{T41}}
**2379-DJU
**2373-3KG
**2373-9HU
**2373-4FG
**2373-4PG
**2373-1FG
**2373-2FG
**2373-2GG
**2373-6U4
**2373-7JU
**2373-CY0
**2373-TG5
**2373-3HM
**2373-4GU
* {{T41p}}
**2373-9FU
* {{T42}}
**2373-C19
**2373-CTO
**2378-DTU
**2378-DUU
**2378-XXE
**2378-R4U
**2373-FWG
**2374-ZEP
**2373-F2G
**2373-JTU
**2373-VUW
**[[2373-6ZG]]
* {{X21}}
**2662-BSG
* {{X32}}
**2884-A3U
*{{X41T}}
** 1869-5CU
| style="vertical-align:top;background-color:#e9f9e9;" |
*[[:Category:A22m | A22m]]
**2628
*[[:Category:A31 | A31]]
**2652-D5G
*[[:Category:R50p | R50p]]
*[[:Category:R52 | R52]]
**1858-6MM
*[[:Category:T41 | T41]]
**2373-GEU
*[[:Category:T41p | T41p]]
**2373-GKG
**2373-GGG
**[[2373-GHG]]
*[[:Category:T42 | T42]]
**[[2373-M1G]]
**[[2373-WBZ]]
**[[2373-F7G]]
**[[2378-DXU]]
**[[2378-FVU]]
**[[2378-RTU]]
**[[2378-RRU]]
*[[:Category:T42p | T42p]]
**[[2373-HTG]]
**[[2373-W6M]]
**[[2373-GTG]]
**[[2373-GXG]]
**2373-KXM
*[[:Category:T43 | T43]]
**[[2668-W12]]
*[[:Category:T43p | T43p]]
**[[2668-G2G]]
*[[:Category:X40 | X40]]
**2371
|}
*Different symptoms have been reported for different models. In some models the origin of the power drain is obvious ([[Problem with LCD backlight remaining on during ACPI sleep|backlight on during suspend]]), in other models there is no obvious reason.

*On some models/configurations the higher power drain couldn't even be realized or was at least significantly lower.

*The T4x ThinkPad series and other Radeon based models suspend to ram just fine, and there are no components that are obviously left powered up. The [[UltraBay]] and network light is on, but that is the same under windows (but under APM sleep to RAM those lights are OFF). For these models the higher power drain is caused by a driver problem and can be fixed in software. This fix has not yet made its way into the official kernel (as of linux 2.6.12).

The table on the right gives an overview of the models suffering from the mysterious power drain. To find out about your model, you may use the following [[ACPI sleep power drain test script | script]]. It creates a file {{path|/var/log/battery.log}} which will tell you if you are affected or not.

==Affected Operating Systems==
*Linux, all flavours.
*Windows, for some models as well (only when using non-IBM drivers).
*FreeBSD (on the A22M)

==Status==
*The cause of the mysterious power drain is the Radeon GPU, which requires extra steps to suspend properly. Unfortunately, this fix might break non-ThinkPad machines and therefore is not yet in the official kernel sources.
*The official bugzilla entry for the radeon suspend issue is in the [http://bugme.osdl.org/show_bug.cgi?id=3022 OSDL Bugzilla]. There you can find a patch which will solve the power drain issue.
{{WARN|This solution enables doing suspend-to-D2 on non-PPC-machines, which is not properly documented! Be careful and have a look at the discussion for kernel bug 3022 (see above) before applying the patch. By default, the patch enables the suspend-to-D2 only on machines where it is known to work. This behaviour can be overridden with a module option.}}
{{NOTE|This solution is on its way for inclusion into the mainline Linux kernel, but the whitelist required for its inclusion needs your help. Please send mail to ''patroclo7 at gmail.com'' with the output of '''lspci -d "1002:*" -vn''' on affected machines ''only''. Refer to [http://thread.gmane.org/gmane.linux.hardware.thinkpad/25355 the linux-thinkpad ML post requesting this information] for more information. This is mostly urgent if you happen to own an X21 or a R50.}}
*Most certainly, the DSDT is not at fault. (Interesting to note: The DSDT from BIOS 3.13 (Nov 04) for the T42p compiles without bugs.)
*Some additional power savings can be achieved by turning off the wake-on-lan ({{cmdroot|ethtool -s eth0 wol d}}). The power drain of the wol feature is far smaller than the radeon bug, but can be noticeable.

==Solutions==
===For ThinkPads with Radeon graphic chips===
You must use a patched version of the radeon frame buffer, even if you are only interested in using the X window system. This modified radeon frame buffer then suspends the radeon chip correctly during ACPI sleep. This patch is not yet in the official (kernel.org) kernels.

The [http://bugme.osdl.org/attachment.cgi?id=8220&action=view patch] contains a list of ThinkPads where it is known to work, and by default only activates on these machines. If you think that your computer would profit from the patch as well, you can force it by including the module parameter {{bootparm|force_sleep|1}}. If it doesn't work this can result in system hangs.

====Technical Background====
The patch removes the CONFIG_PPC_PMAC condition for enabling D2 sleep in {{path|drivers/video/aty/radeon_pm.c}} as discussed in [http://bugme.osdl.org/show_bug.cgi?id=3022 kernel bug 3022].

====Fedora Core====
* Fedora Core 4: Fedora ships a patched radeon frame buffer (radeonfb.ko), but you must enable it yourself. {{Fedora}} compiles it as a module rather than including it in the kernel, therefore you cannot activate it at boot time without a custom initrd. You must arrange for the module to be loaded before X starts (for example, using an init script).
* Fedora Core 3: this is also true for updated kernels (at least for kernel-2.6.12-1.1376_FC3) but '''not''' for the initially shipped version.

There are precompiled patched kernels [http://www.sas.upenn.edu/~vbraun/computing/T41/kernel.html available] as well, that do not need an initrd modification:
*[http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/i386/kernel-T4x-2.6.11.11-26.i386.rpm linux 2.6.11 for Fedora Core 3]
*[http://carrot.hep.upenn.edu/~vbraun/kernel-T4x/i386/kernel-T4x-2.6.12.2-2.i386.rpm linux 2.6.12 for Fedora Core 4]
These kernels contain additional ThinkPad-related patches, including [[Software Suspend 2]] and trackpoint support. Suspend to disk and suspend to ram should work with them. If your ThinkPad model is not yet whitelisted in the patch, you might have to enable the radeon fix by including the parameter {{bootparm|video|2=radeonfb:force_sleep}} on the kernel command line.

If you try, please send the result (hang yes/no, battery drain yes/no) with the precise model number (i.e. IBM ThinkPad T41 2379-DJU) to <tt>vbraun at physics dot upenn dot edu</tt>, it would be nice if your subject line would include "RADEONFB:" to make sure that I do not miss any emails.

=====testing radeonfb without changing initrd=====
If you want to try the radeon frame buffer, you can enable it as follows:
*First, switch to a console ({{key|Ctrl}}{{key|Alt}}{{key|F1}}) and log in as root.
*Stop X: {{cmdroot|init 3}}
*Now you can load the module: {{cmdroot|1=modprobe radeonfb force_sleep=1}}
*Finally, resume X: {{cmdroot|init 5}}

=====including radeonfb into your initrd=====
As an alternative you can build your customized initrd. This is as simple as running
:{{cmdroot|1=mkinitrd --with=radeonfb /boot/<name-of-your-new-initrd> `uname -r`}}
and replacing the initrd in {{path|/boot/grub/grub.conf}} with your new one. You also need to add the kernel command line argument {{bootparm|video|2=radeonfb:force_sleep}}.

====Gentoo====
After installing the patch on {{Gentoo}} (it works fine with gentoo-sources: {{cmdroot|cd /usr/src/linux/drivers/video/aty}}, and execute {{cmdroot|patch -p4 < <patchname>}}, then recompile the kernel), one needs to add {{bootparm|video|radeonfb:force_sleep}} to the kernel parameters.

====Another possible solution====
It is possible that [[radeontool]] will help some people with this case.
(simply run radeontool light off before suspend and radeontool light on after resume).
A radeontool patch for freebsd is here: http://www.init-main.com/radeontool.patch (by Takanori Watanabe).

===For models without Radeon graphics===
The Problem seems to be solved when you use the [http://www.srcf.ucam.org/~mjg59/vbetool/ vbetool] to turn the LCD off before suspending ...
:{{cmdroot|vbetool dpms off}}
and turning it on afterwards again...
:{{cmdroot|vbetool dpms on}}
You have to change to a normal console before turning the LCD off.
Additionally you have to deactivate the Wake-On-Lan feature like mentioned above ...
:{{cmdroot|ethtool -s eth0 wol d}}
With these commands used together the "testing script" reports no high power drain while suspending.

==Other problems causing the power drain==
On my [[R51]] using Gentoo Linux, the high power drain was not caused by the graphics adaptor but by several components not powered down properly before putting the Thinkpad into S3.

If the above did not help you, this might do:

Walk through
/sys/devices/*/*/power/state
and try to disable each of it, every time checking the power drain. (See linux/Documentation/power/devices.txt for values to write into the state-files. 3 should be the value you want to try)
Do the same for other components (Like the Ultrabay, etc.). Please add your experiences here.

===R51: Ultrabay and networking===
On my system, ultrabay and networking light were still on while in S3. So were the devices theirselves.
echo -n eject > /proc/acpi/ibm/bay # Disable ultrabay
ethtool -s eth0 wol d # Disable Wake-On-Lan (And so the eth-adaptor)
echo mem > /sys/power/state # Sleep

For me, this lowered the power drain from >700mW to 338 mW.

ACPI sleep power drain test script

2006-08-07T18:27:46Z

Wilmer: Added two checks (at least the first one is probably a good idea for people like me ;-))

The following script will suspend your notebook to ram and output some statistics about the power drain during suspend to {{path|/var/log/battery.log}}. The output will look something like this:

Di Jan 11 14:01:15 CET 2005
before: 41170 mWh
after: 41000 mWh
diff: -170 mWh
seconds: 1671 sec
result: -366 mW
Congratulations, your model seems NOT to be affected.

{{NOTE|This Script has some limitations:
*It is not totally reliable, e.g. on some (all?) R32 the values ACPI reports for the battery are wrong by factor 10. They are actually reported in cWh instead of mWh. The script assumes they are reported in mWh as on most ThinkPads - hence the power consumption appearce to be only a tenth of its actual value.
*The script assumes you have only one battery. If you have a second battery (for example, an UltraBay Slim battery), take it out for this test or change the BATTERY variable from "BAT0" to "BAT1". If you do the latter, you will get bogus results if the second battery is run down while sleeping.
*The usage threshold of 1000 mWh might be a bit a bit too tolerant. You can try lowering it to 500 to be sure.}}

Please save this script to a file, i.e. {{path|sleep.sh}}, make it executable ({{cmdroot|chmod +x sleep.sh}}) and execute it as root while your notebook is on battery. To get representative values you should leave the notebook suspended for at least 20 minutes.

#!/bin/sh
# sleep.sh test script for measuring power drain during suspend-to-ram with ACPI

# default settings, change if needed
LOG=/var/log/battery.log
BATTERY=BAT0
THRESHOLD=1000

if ! grep -q '^charging state:.*discharging' /proc/acpi/battery/$BATTERY/state; then
echo 'Not running on battery power, did you forget to disconnect the charger?'
exit 1
fi

if [ "$UID" != "0" ]; then
echo 'This script can only be run by root.'
exit 1
fi

# remove USB for external mouse before sleeping
if lsmod | grep '^usbhid' >/dev/null ; then
/sbin/modprobe -r -s usbhid
fi
if lsmod | grep '^uhci_hcd' >/dev/null ; then
/sbin/modprobe -r -s uhci_hcd
fi
if lsmod | grep '^ehci_hcd' >/dev/null ; then
/sbin/modprobe -r -s ehci_hcd
fi

# save system time
hwclock --systohc

# get start values
date >> $LOG
DATE_BEFORE=`date +%s`
BAT_BEFORE=`grep 'remaining capacity' /proc/acpi/battery/$BATTERY/state | awk '{print $3}'`

# go to sleep
if [ -e /proc/acpi/sleep ]; then
echo 3 > /proc/acpi/sleep
else
echo -n mem > /sys/power/state
fi

# get end values
DATE_AFTER=`date +%s`
BAT_AFTER=`grep 'remaining capacity' /proc/acpi/battery/$BATTERY/state | awk '{print $3}'`

# do the calculations
DIFF=`echo "$BAT_AFTER - $BAT_BEFORE" | bc`
SECONDS=`echo "$DATE_AFTER - $DATE_BEFORE" | bc`
USAGE=`echo "($DIFF * 60 * 60) / ($SECONDS)" | bc`

# output the results
echo "before: $BAT_BEFORE mWh" >> $LOG
echo "after: $BAT_AFTER mWh" >> $LOG
echo "diff: $DIFF mWh" >> $LOG
echo "seconds: $SECONDS sec" >> $LOG
echo "result: $USAGE mW" >> $LOG
if [ $USAGE -gt -$THRESHOLD ]
then
echo "Congratulations, your model seems NOT to be affected." >> $LOG
else
echo "Your model seems to be affected." >> $LOG
fi
if [ $SECONDS -lt 1200 ]
then
echo "!!! The notebook was suspended less than 20 minutes." >> $LOG
echo "!!! To get representative values please let the notebook sleep" >> $LOG
echo "!!! for at least 20 minutes." >> $LOG
fi
echo "" >> $LOG

# restore USB support
if !(lsmod | grep '^ehci_hcd') >/dev/null ; then
/sbin/modprobe -s ehci_hcd
fi
if !(lsmod | grep '^uhci_hcd') >/dev/null ; then
/sbin/modprobe -s uhci_hcd
fi
if !(lsmod | grep '^usbhid') >/dev/null ; then
/sbin/modprobe -s usbhid
fi

# restore system time
hwclock --hctosys

The script was originally written by Jan-Hendrik Benter and was modified a little for this page.

[[Category:Scripts]]