Making the Hardware Components work

The next pages describe how to configure the various hardware components so they work Debian Linux.


CD-RW/DVD-RW Multi-Burner

The drive itself works fine in any case, but when it's used as normal EIDE-device there's no DMA support because it's connected to the SATA-controller. Hence it's necessary to use it as SATA-device to get the full speed and low CPU utilization needed, for instance to play DVDs without annoying stuttering.

Current vanilla kernels from have the code for ATAPI support via SATA already included, but it's not enabled by default. After reading some comments about various Linux distributors already enabling the functionality in their custom kernels, I figured it's worth giving it a try.

Kernel 2.6.12.x:

In the kernel source tree in includes/linux/libata.h you have to change

#undef ATA_ENABLE_ATAPI                /* define to enable ATAPI support */
#undef ATA_ENABLE_PATA /* define to enable PATA support in some
* low-level drivers */
#undef ATAPI_ENABLE_DMADIR /* enables ATAPI DMADIR bridge support */

at around line 40 to

#define ATA_ENABLE_ATAPI                /* define to enable ATAPI support */
#define ATA_ENABLE_PATA /* define to enable PATA support in some
* low-level drivers */
#define ATAPI_ENABLE_DMADIR /* enables ATAPI DMADIR bridge support */

Kernel 2.6.14 and beyond:

Just add "libata.atapi_enabled=1" to the kernel command line in the GRUB configuration.

Using the Debian kernel package (currently linux-image-2.6.16-1-686 in sid/unstable), just make sure that the initrd is created in a way that the libata module is loaded with the atapi_enabled=1 option set. Depending on the programm you're using to create the initrd, it's necessary to configure the following files:

Package initrd-tools:

Put the line

libata atapi_enabled=1

into /etc/mkinitrd/modules

Package initramfs-tools:

Put the above line into /etc/mkinitramfs/modules

Package yaird:

Make sure the option is configured in the /etc/modprobe.d/ directory, e.g. put the line

options libata atapi_enabled=1

into a file /etc/modprobe.d/cdrom

Either way, you have to re-create the initrd afterwards, either manually (see the manual pages for mkinitrd, mkinitramfs and yaird, respectively) or by running dpkg-reconfigure linux-image-2.6.16-1-686 


If patching is necessary you have to recompile and install the kernel as described on the kernel configuration page. After rebooting into the new kernel, the optical drive should then be accessible via /dev/scd0 (or /dev/sr0) for reading and /dev/sg1 for writing.

If your system still uses /dev/hdc (i.e. the drive is not found in /proc/scsi/scsi) it's maybe because the IDE-detection routines at startup find the multi-burner before the libata subsystem tries to access it. You can disable the IDE-detection by passing "ide1=noprobe" as kernel parameter in your GRUB configuration.

After a week of testing there haven't been any problems so far, so it seems to work fine. Playing DVDs now works perfectly, and writing to optical media works as well. But of course, you can also wait until the kernel developers think the feature is stable enough to enable it by default in the kernel.

Since I use various kernels at the moment, some with the SATA-ATAPI features enabled and some without, I put the following lines into an init script to fix the /dev/cdrom and /dev/dvd symlinks depending on kernel configuration:

# fix dvd and cdrom links
rm -f /dev/cdrom /dev/dvd
if grep -q MATSHITA /proc/scsi/scsi
# running libata enabled kernel
ln -s /dev/sr0 /dev/cdrom
ln -s /dev/sr0 /dev/dvd
# running kernel with only IDE support
ln -s /dev/hdc /dev/cdrom
ln -s /dev/hdc /dev/dvd


Fingerprint Reader

Finally found time to fiddle around with the fingerprint reader, and getting it to work was easier than I thought. The HowTo in the ThinkWiki was very helpful, as usual.

There are 4 components to make the whole thing work:

  • the BioAPI framework to use various biometric authentication systems, Debian packages (and lots of infos about Linux and Biometrics) can be found at Michael R. Crusoe's great website Note: I used the package (version 1.2.3) found in because it was the only version that worked in all respects. YMMV.
  • the driver (called Biometric Service Provider, BSP) for the fingerprint reader in the Thinkpad provided by UPEK, Inc., the direct link to the download page is
  • the pam_bioapi module found at, which makes the BioAPI accessible from the Linux PAM system.
  • a pam configuration for the services that should use the fingerprint reader, e.g. the login in the text console or in the graphical display manager. And of course you need to collect fingerprints of the users that should be able to use the reader for authentication. If no sample fingerprints are found or if they do not match, the system falls back to using passwords.

BioAPI framework

Just installe the downloaded .deb file with

dpkg -i bioapi_1.2.3_i386.deb

Ignore the warning about not finding /usr/lib/, it's not fatal.

UPEK Fingerprint BSP

The software comes in a zip file, so

apt-get install unzip

if you haven't got it installed already. Then create a new directory and change into it, then unpack and install the driver:

mkdir fingerprint-driver
cd fingerprint-driver
unzip -q /path/to/the/downloaded/


It's necessary to use a patch from to make the pam module work, I also attached the fingerprint.patch file below in case it vanishes from the current URL.

Otherwise the installation is straightforward with the usual 3 steps ./configure, make and make install: (make sure you have libpam-dev or specifically libpam0g-dev installed)

tar -xjf /path/to/the/downloaded/pam_bioapi-0.2.1.tar.bz2 
cd pam_bioapi-0.2.1/
patch -p0 < /path/to/the/downloaded/fingerprint.patch
make install

Enrolling users and PAM configuration

Since the BioAPI framework could work with various biometric devices each and every one of them has a unique serial number (a long hexadecimal number) called Module ID. The process of gathering sample fingerprints and the PAM configuration both need the Module ID of your fingerprint reader. You can print the ID in the needed format with the following rather ugly command:

BioAPITest | sed -ne "/Fingerprint/{n;n;s/^.*: \(.\{9\}\)\(.\{4\}\)\(.\{4\}\)\(.\{4\}\)\(.*\)/\1-\2-\3-\4-\5/gp}"

The result, in my case {5550454b-2054-464d-2f45-535320425350} (check if your ID differs and change accordingly in the following steps), is needed in several places. First create a directory in /etc/bioapi1.10/pam with that name, e.g. with

mkdir -p /etc/bioapi1.10/pam/{5550454b-2054-464d-2f45-535320425350}

Into that directory the files containing the sample fingerprints (one file per user, with .bir as extension) need to be copied. Creating these files is done using the Sample program that comes with the UPEK software (in the NonGUI_Sample subdirectory), which needs to be made executable first. Then run it (from the current directory with ./Sample), choose "enroll" and enter a valid username. You'll then be prompted to collect 3 fingerprints. Once you're done, choose "quit" and look into the current directory. It should contain a .bir-file for the username you just entered. Copy that file into the directory created in the last step. E.g. for the user spiney:

cd /path/to/fingerprint-driver/NonGUI_Sample
chmod a+x Sample
cp spiney.bir /etc/bioapi1.10/pam/{5550454b-2054-464d-2f45-535320425350}

Repeat for each user you want to use the fingerprint reader with.

The next and final step is to configure services to use the pam_bioapi module as authentication source. For each PAM-aware service there's a configuration file in /etc/pam.d/ plus the fallback configuration file called common-auth which you could use to enable the reader system-wide. I just enabled it for gdm (the Gnome Display Manager, i.e. the graphical login) and login (for the text consoles) by adding the following line before the line with @include common-auth:

auth       sufficient /usr/local/lib/security/ {5550454b-2054-464d-2f45-535320425350} /etc/bioapi1.10/pam/

Note: by using the complete path to the module it's not necessary to copy it to /lib/security.

After that logging in using the fingerprint reader should work for configured services. If not, check /var/log/auth.log for any pam-related error messages.

Using the fingerprint reader with programs that run as unprivileged user

For PAM-aware applications like xscreensaver which are run as normal user without root privileges it's necessary to change the permissions on two files so that files can be read and written:

  • /var/log/BSP.log (the log file of the UPEK driver, since this is a beta release there's no way to disable logging)
  • the entry for the fingerprint reader USB devices in the /proc filesystem, something like /proc/bus/usb/004/002

The latter can be printed with the following command:

echo /proc/bus/usb/`lsusb | sed -ne "/0483:2016/s/Bus\ \(.*\)\ Device\ \(.*\):\ .*/\1\/\2/p"`

Either set to permissions on both to world read/writeable (pass 666 to chmod, probably ok security-wise since notebooks are single user systems in most cases) or assign a special group to them and give it write permission, and then add all users that should be able to use the fingerprint reader to that group. In my case I used the group adm, because my normal user was already member in it (I do like to read log files without changing to root). So I did the following

chgrp adm /var/log/BSP.log
chmod g+rw /var/log/BSP.log
DEVICE=/proc/bus/usb/`lsusb | sed -ne "/0483:2016/s/Bus\ \(.*\)\ Device\ \(.*\):\ .*/\1\/\2/p"`
chgrp adm $DEVICE
chmod g+rw $DEVICE

Since you have to set the permissions on the proc entry every time you boot (or come back from suspend/hibernation), it's best to put the last three lines into some shell script that gets run every time you boot.

Now also non-root users can use the fingerprint reader. The only application at the moment that comes to mind and is PAM-capable is xscreensaver. It needs a patch from by Josef Hajas so that you are first asked to swipe your finger and it falls only back to password authentication when that fails. You can either get the source code from the xscreensaver website, but if you run Debian sid you can also download my patched xscreensaver package (built from the current source from Debian via apt-get source) which is attached below. I'll try to keep them updated whenever there's a new version in Debian until the patch makes it into the xscreensaver source code upstream. But I disclaim all warranties regarding that package, so beware!

Now just change /etc/pam.d/xscreensaver to

# /etc/pam.d/xscreensaver - PAM behavior for xscreensaver

auth sufficient /usr/local/lib/security/ {5550454b-2054-464d-2f45-535320425350} /etc/bioapi1.10/pam/
@include common-auth

and add the following option

alternativeAuth: True

to your ~/.xscreensaver configuration file, restart xscreensaver and you're set. Lock the screen, press a key and there should be the window telling you to swipe your finger over the reader.

Again, if it doesn't work, take a look into /var/log/auth.log and check those file permissions.

New patch for xscreensaver

Since the original patch was sometimes confusing to the user (see Brice Goglin's comment below) I tried to come up with a different approach: use a different PAM configuration for xscreensaver when using the alternativeAuth option.

Below is the patch (xscreensaver-4.23_fingerprint.patch) and also an updated version of the package for Debian sid (xscreensaver_4.23-3fingerprint_i386.deb). To use it, follow the instructions above, but instead of modifying /etc/pam.d/xscreensaver (if you did already, remove the bioapi line again), create a new file /etc/pam.d/xscreensaver-alternative with the following content:

# /etc/pam.d/xscreensaver-alternative - PAM behavior for xscreensaver
# when running with alternativeAuth

auth sufficient /usr/local/lib/security/ {5550454b-2054-464d-2f45-535320425350} /etc/bioapi1.10/pam/

Again, I disclaim all warranties regarding the patch and the package, so beware!


Graphics Card


Using the Graphics Card with the ATI fglrx driver


You can create new configuration files suitable for the fglrx driver with the fglrxconfig tool, alternatively you can also use aticonfig to change configuration parameters. Better backup /etc/X11/xorg.conf before using either of the two utilities.

Supported modes for multi-monitor setups

Attached at the bottom of the page you can find the xorg.conf files I use for the various multi-monitor modes that the ATI binary driver supports and also TV-out. A few notes:

  • no example for "Mirror" mode, which is pretty useless if you don't happen to have an external monitor matching the notebook's LCD resolution, i.e. 1400x1050, which I don't.
  • the external display I use has a max. resolution of 1280x1200, if your monitor supports less be sure to check the HorizSync, VertRefresh, HSync2 and VRefresh2 options.
  • I'm living in Europe, hence my TV understands PAL (connected via S-Video), so if you need NTSC or something else, check the TVFormat and TVStandard options. aticonfig run without arguments lists all available values.
  • I have configured my input devices (TouchPad, Trackpoint, external mouse) with their special files in /dev/input and not /dev/input/mice. There's a good chance that your file-to-device mapping looks different, so check if you're using the correct device files in /dev/bus/input/devices. Or just use /dev/input/mice in which case you'll lose the ability to configure some settings per device.


Using the Graphics Card with the radeon driver


You can create new configuration files suitable for the radeon driver with the text-based xorgconfig tool or run

X -configure

to let probe your hardware and write a configuration file, alternatively you can also use the graphic application xorgcfg to change configuration parameters. Better backup /etc/X11/xorg.conf before using either of these utilities.

Supported modes for multi-monitor setups

Attached at the bottom of the page you can find the xorg.conf files I use for the various multi-monitor modes that the radeon driver supports. A few notes:

  • the external display I use has a max. resolution of 1280x1200, if your monitor supports less be sure to check the HorizSync, VertRefresh, HSync2 and VRefresh2 options.
  • I have configured my input devices (TouchPad, Trackpoint, external mouse) with their special files in /dev/input and not /dev/input/mice. There's a good chance that your file-to-device mapping looks different, so check if you're using the correct device files in /dev/bus/input/devices. Or just use /dev/input/mice in which case you'll lose the ability to configure some settings per device.
  • TV-Out is currently not supported by the opensource radeon driver, use the fglrx driver if you need this feature.
  • real dual-head support (as in two seperate independent screens) seems to be broken at the moment, see bug #332548 in the Debian bug tracking system.


Easily switching from fglrx to radeon and back

Once you have installed and set up the graphics card with the fglrx and the radeon driver (including multi-monitor setups), it's helpful to make the switch from one setup to another rather easy.

Basically, switching involves exchanging the xorg.conf file and the GL library file. But since the drivers are different in other respects too (suspend/resume, 3D acceleration), it's also convenient to change configuration files
at the same time, for example the xscreensaver configuration file to run different screensavers (radeon: no 3D; fglrx: all the 3D you can find ;)) or the hibernate.conf file for suspending the ThinkPad.

The attached radeonswitch script does exactly that.

You can switch the configuration either at boot time (if you set up GRUB/LILO to do so, see below) or while the system is up and running.

Note: switching while the system is running only work from radeon to fglrx, not the other way around. The fglrx driver seems to do some magic initialization to the graphics card which makes it unusable for the radeon driver. In other words, switching from fglrx to radeon needs a reboot of the system.


  • Debian unstable running the latest packages (6.9.0).
  • the fglrx driver installed from a Debian package, see the "Problems with fglrx" page in the ThinkWiki if you have troubles. The script will not work if you install the fglrx driver not from a .deb file!


If you only want switch while the system is running, no special installation is needed. If you want to switch at boot time, as root issue

mv /path/to/downloaded/radeonswitch /etc/init.d
chmod 755 /etc/init.d/radeonswitch
update-rc.d radeonswitch defaults 95

to integrate it into the boot sequence of the Debian system.


Put the xorg.conf files for the various configurations you use into /etc/X11, renaming them to xorg.conf.<config>. For <config>, use a word starting with fglrx for the fglrx driver or a word starting with radeon for the radeon driver, e.g. is my TV-Out configuration for the fglrx driver. The example configuration files on this site all use this naming convention.

If you want to switch other configuration files, add them to the CONFIGS variable at the beginning of the radeonswitch file (an example can be found as comment inside the script) and provide one version with a .fglrx suffix and one with a .radeon suffix. For example the I created one /home/spiney/.xscreensaver.fglrx file with almost all 3D screensavers active and another /home/spiney/.xscreensaver.radeon with mostly 2D screensavers configured. The file corresponding to the chosen driver will be copied to /home/spiney.xscreensaver when radeonswitch is run.

Usage from the command line

As root issue

/etc/init.d/radeonswitch set <config>

to switch to the corresponding configuration and restart X.

Usage at boot time

You have to configure your boot loader to switch the driver at system startup. For GRUB this means adding


to your kernel configuration line in /boot/grub/menu.lst. For LILO (not tested) it should work with adding


to your /etc/lilo.conf line and running


to install the new LILO configuration.

Of course you have to provide multiple menu entries for GRUB or LILO, otherwise you can't really switch. Wink If you provide menu entries where RADEONDRIVER is not appended, the graphics card setup will be left as it is.


Use this script own your own risk! I give no warranty whatsoever that the script works as intended, so if it accidentally deletes your whole harddisk, you're on your own. But I'm using it myself for quite some time now, so that's unlikely. Smile Bug reports or feature requests are very welcome, feel free to use the feedback page.

Binary Data radeonswitch1.21 KB



Warning: do not use these patches alongside suspend2, since there seem to be unresolved issues with this combination.

New technologies are fine, but sometimes they just give headaches. The harddisk found in the T43p is one such case. It's connected to a SATA controller via a so called SATA-to-PATA bridge, and the problem is that powermanagement and suspend-to-RAM is not working with stock kernels from, at least not with the currently latest version 2.6.14.

But, after reading and re-reading the page about the topic in the ThinkWiki, playing around with different combinations of patches and following bits of the discussion in the LKML and linux-ide archives, at last I got the whole thing working. But of course this is rather unsafe territory and I give no warranty whatsoever that it works for you or that there will be no loss of data, so continue at your own risk.

Used Patches

Kernel 2.6.14:

  • from this LKML posting I got the suspend-to-RAM patch, and even though there seems to be a competing implementation this one "works for me". Use the "Get diff 1" link in the menu on the left to get the patch in proper text-only format.
  • from I downloaded 02_libata_passthru.patch and 03_libata_passthru_bugfix.patch so I can use hdparm and the smartmontools needed for setting powersaving parameters among other things. 02_libata_passthru.patch does not apply cleanly since a couple of things are already in the suspend-to-RAM patch from above, so I updated it and it's attached below.

In the root directory of the kernel source, apply the patches in the following order:

patch -p1 < /path/to/downloaded/suspend-to-ram-from-lkml.patch
patch -p1 < /path/to/downloaded/02_libata_passthru.fixed.patch
patch -p1 < /path/to/downloaded/03_libata_passthru_bugfix.patch

Kernel 2.6.15:

Kernl 2.6.16:

  • no more patches are needed, both a self-compiled kernel and the current kernel package in Debian unstable (linux-image-2.6.16-1-686) have no problems regarding the harddisk.

If necessary, recompile and install the kernel as shown in the kernel configuration page.

After booting into the new kernel, commands like

hdparm -I /dev/sda

to show information about the drive or

hdparm -y /dev/sda

to spin down the harddisk should work. (the -i option does not, interestingly enough)

Once that works it's time to configure suspend-to-RAM or start using the Laptop Mode Tools.

Warning: once while using the Laptop Mode Tools I had problems similar to the ones outlined in this Debian bug report, so I disabled powermanagement for the moment setting CONTROL_HD_POWERMGMT=0 in laptop-mode.conf. Also, I'm not running smartd from the smartmontools since I guess that could also lead to problems.
File 02_libata_passthru.fixed.patch20.93 KB



To use the infrared transmitter (it's located at the front, which is a rather unpractical placement IMO) it's necessary to install the irda-utils with

apt-get install irda-utils

The configuration of the irda-utils Debian package takes place in /etc/default/irda-utils and get filled in via questions asked by debconf at installation time. I use the following settings:


As stated in /usr/share/doc/irda-utils/README.Debian to use Fast-Infrared (FIR) it's necessary to disable the Serial-Infrared (SIR) part of the system, so I disabled loading the SIR kernel modules by adding them to /etc/hotplug/blacklist:

# ignore serial irda drivers

After that it's necessary to tell the system which kernel module to load for the irda0 device, that is done by putting the following lines into /etc/modprobe.d/irda-utils:

alias irda0 nsc-ircc
options nsc-ircc dongle_id=0x09 io=0x2f8 irq=3
install nsc-ircc /bin/setserial /dev/ttyS1 uart none port 0 irq 0; /sbin/modprobe --ignore-install nsc-ircc

The nsc-ircc kernel module needs a patch to work, see the kernel configuration page.

Stop the irda-utils with

/etc/init.d/irda-utils stop

and then make sure the SIR modules are not loaded anymore (use lsmod and if they're still loaded use rmmod to remove them). Then start the irda-utils again with

/etc/init.d/irda-utils start

The nsc-ircc module should get loaded automatically and the irattach program should be setting up the infrared device irda0. Check /var/log/syslog, it should look similar to this:

Sep 17 14:43:10 t43p kernel: pnp: Device 00:0a activated.
Sep 17 14:43:10 t43p kernel: nsc-ircc, Found chip at base=0x000
Sep 17 14:43:10 t43p kernel: nsc-ircc, driver loaded (Dag Brattli)
Sep 17 14:43:10 t43p kernel: IrDA: Registered device irda0
Sep 17 14:43:10 t43p kernel: nsc-ircc, Using dongle: IBM31T1100 or Temic TFDS6000/TFDS6500
Sep 17 14:43:10 t43p irattach: executing: 'echo t43p > /proc/sys/net/irda/devname'
Sep 17 14:43:10 t43p irattach: executing: 'echo 1 > /proc/sys/net/irda/discovery'
Sep 17 14:43:10 t43p irattach: Starting device irda0

After that it's possible for example to use infrared communication to sync a Palm PDA or to access a mobile phone via gnokii or gammu. See the Linux Infrared Howto for more information.

I actually don't like the irda-utils to be started automatically at boot time since I very seldomly use infrared communcations, so I removed the symbolic link /etc/rc2.d/S20irda-utils (because I use runlevel 2 as my default runlevel, which is the standard configuration in Debian, use the appropriate rcX.d directory for your runlevel). Instead I'm using the following script (I called it toggle_irda) to toggle the irda-port on and off:


if [ -f $PIDFILE ]
/etc/init.d/irda-utils stop > /dev/null
/etc/init.d/irda-utils start > /dev/null

It checks whether the irda-utils are currently running and either starts or stops them. The scripts gets started when pressing Fn+F8, see the Special Keys page for details.

File nsc-ircc-pnp.2.6.12.diff5.03 KB


Special Keys

Getting the various special keys like "Access IBM", Mute etc. and the Fn-key combinations recognized is pretty easy. For an overview of the possibilities and more in-depth information see this ThinkWiki page.

Three software packages are needed:

You can install acpid and tpb with

apt-get install acpid tpb


Note: Version 2.6.14 of the Linux kernel has the most recent version of the ibm-acpi module include, so all you need to do is enable it in "Power management options (ACPI, APM)" -> "ACPI (Advanced Configuration and Power Interface) Support" -> "IBM ThinkPad Laptop Extras", preferably as module so you can pass it options at via modprobe. And don't enable "Generic Hotkey (EXPERIMENTAL)" in the same menu since it seems to conflict with the Thinkpad Extras in some way.

The ibm-acpi kernel module is part of the standard Linux kernel since version 2.6.10, but it's not the most recent version. To replace it with the newest version (at the time of writing 0.11, the upcoming kernel 2.6.14 will include 0.12a), it must be compiled as a module (CONFIG_ACPI_IBM=m; if you're using my kernel configuration file you're fine, otherwise search for "IBM Thinkpad Laptop Extras" in the kernel configuration). Download the compressed archive and then issue

tar -xzf ibm-acpi-0.11.tar.gz
cd ibm-acpi-0.11
make install

to install the new module. After that either reboot (the new module should get loaded automatically by the hotplug subsystem) or try

rmmod ibm_acpi
modprobe ibm_acpi

Make sure you're running the correct version, either by search the kernel message buffer with

dmesg | grep ibm_acpi

or by checking in the proc filesystem with

cat /proc/acpi/ibm/driver

To enable the hotkeys you have to echo some values into the proc filesystem:

echo enable > /proc/acpi/ibm/hotkey
echo 0xffef > /proc/acpi/ibm/hotkey

The first line basically enables the hotkey feature, the second selects all available key combinations apart from Fn+F5 (which toggles the bluetooth adapter on and off) to send ACPI events. See the ibm-acpi README file for details, also for the various other interesting files in that directory.

Since you probably don't want to do that everytime after the modules gets loaded, it's probably a good idea to put these module parameters into the /etc/modprobe.d/ directory, in my case I wrote a file called /etc/modprobe.d/ibm-acpi containing

options ibm_acpi experimental=1 hotkey=enable,0xffef


The next step is to configure acpid for the ACPI events sent by pressing the special keys and tell it what command to run. The name of the events all start with "ibm/", hence I wrote a file called /etc/acpi/events/ibm-acpi with the following content:

action=/etc/acpi/actions/ "%e"

The action line calls a script and passes the event name as first and only argument. The /etc/acpi/actions/ is a simple shell script and looks like this:

case "$1" in
# Fn+F12
"ibm/hotkey HKEY 00000080 0000100c")
# Fn+F4
"ibm/hotkey HKEY 00000080 00001004")
/usr/sbin/hibernate -F /etc/hibernate/hibernate.conf.ram
# Fn+F6
"ibm/hotkey HKEY 00000080 00001006")
# Fn+F8
"ibm/hotkey HKEY 00000080 00001008")
# Fn+F3
"ibm/hotkey HKEY 00000080 00001003")
# log everything else to syslog
/usr/bin/logger -i -t "IBM Special Button" $1

For a couple of events commands are run, the rest get logged to the syslog daemon. All Thinkpad's ACPI event names and their corresponding keys are listed on the above mentioned ThinkWiki page. The toggle_wlan and toggle_backlight scripts are attached in their current version if someone's interested, they'll be explained in more detail once I write the pages for the network and graphics card sections. The toggle_irda script is explained on the Infrared page. The hibernate script is part of Software Suspend 2.

Be sure to notify acpid about changes in files in /etc/acpi by issuing

/etc/init.d/acpid reload


The last part is to configure tpb. This is easy, because the most important functions work right away, namely the volume-up/down and mute buttons, the thinklight and the brightness control. The latter two work even without tpb, probably it's hardwired in the hardware, but tpb adds a nice on screen display.

The configuration file is /etc/tpbrc. Two things I changed from the defaults:

  • setting XEVENTS to OFF results in tpb not grabbing the Fn-key and the forward/backward-keys next to the cursor keys, because I'd like them to send normal keycodes. Try the 'xev' command to actually see the keycodes.
  • CALLBACK /etc/ tells tpb to run that script for the various events in recognizes.

I copied the example script from /usr/share/doc/tpb/ to that location and started editing. First I substituted all occurences of "echo" with "/usr/bin/logger -i -t tpb" to log all actions to the syslog daemon. The only action that I really defined is the one for the zoom-event (when pressing Fn and the space bar), because I wanted to use xzoom (apt-get install xzoom if you haven't guessed it by now) to get a zooming feature for X. That part of the callback script looks now like this:

case $2 in
killall xzoom

BTW, since tpb is run from the startup files of the X Window System, all commands run by the user running X, whereas the commands run from acpid are run with root privileges.

Binary Data toggle_backlight426 bytes
Binary Data toggle_wlan623 bytes


Suspend to RAM

Once the harddisk is supported properly (see the Harddisk page for details) it's rather easy to get suspending and resuming to work. Instead of writing my own suspend script I'm being lazy and just use the hibernate script that comes with Software Suspend 2. Luckily it's also available as a Debian package, so installation is easily done as usual with apt-get, installing the needed vbetool utility at the same time:

apt-get install hibernate vbetool

Attached is the hibernate.conf that I use for suspending to RAM, just a few notes: (see the hibernate.conf manual page for all the other settings)

  • EnableVBEtool is needed so the screen contents are not a just huge garbled mess after resume.
  • UseDummyXServer is needed that the Radeon graphics cards re-enables powersaving (DymanicClocks) after resume.
  • the services hsf (for the modem) and irda-utils need to be stopped and restarted, otherwise the suspend fails (hsf) or the device doesn't work any more after resume (irda-utils).

Note: when using the recent fglrx drivers from ATI (version 8.19.10 and later), be sure not to use either vbetool or the dummy X server, since these options seem to break the resume process.

You can use the configuration file by issuing

hibernate -F /path/to/hibernate.conf.ram

see the Special Keys page for how to map Fn+F4 to that command.

More information can be found in the "How to make ACPI work" ThinkWiki page.

File hibernate.conf.ram483 bytes