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 http://www.kernel.org 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 

Notes:

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
then
        # running libata enabled kernel
        ln -s /dev/sr0 /dev/cdrom
        ln -s /dev/sr0 /dev/dvd
else
        # running kernel with only IDE support
        ln -s /dev/hdc /dev/cdrom
        ln -s /dev/hdc /dev/dvd
fi

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 http://www.qrivy.net/~michael/blua/. Note: I used the package (version 1.2.3) found in http://www.qrivy.net/~michael/temp/ 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 http://www.upek.com/support/dl_linux_bsp.asp.
• the pam_bioapi module found at http://www.qrivy.net/~michael/blua/pam_bioapi/, 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 dpkg -i bioapi_1.2.3_i386.deb

Ignore the warning about not finding /usr/lib/libqtpwbsp.so, 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/UPEK_BSP_file.zip
sh install.sh

pam_bioapi

It's necessary to use a patch from http://badcode.de/downloads/fingerprint.patch 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
./configure
make
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 
./Sample 
cp spiney.bir /etc/bioapi1.10/pam/{5550454b-2054-464d-2f45-535320425350}

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/pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi1.10/pam/

Note: by using the complete path to the pam_bioapi.so 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

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 http://nax.hn.org/pub/bioapi/xscreensaver-4.22_alternativeAuth.diff 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/pam_bioapi.so {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/pam_bioapi.so {5550454b-2054-464d-2f45-535320425350} /etc/bioapi1.10/pam/

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

Graphics Card

The next pages provide information about how to configure the built-in ATI Radeon graphics card.

X -configure

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

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

RADEONDRIVER=<config>

append="RADEONDRIVER=<config>"

/sbin/lilo

Harddisk

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 kernel.org, 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 http://rtr.ca/dell_i9300/kernel/kernel-2.6.13/ 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:

• the libata_passthru has been included into the vanilla kernel, so only the suspend/resume-patch is still necessary, an up-to-date version for 2.6.15-rc6 and also the 2.6.15 final can be found at http://tpctl.sourceforge.net/tmp/sata_pm.2.6.15-rc6.patch.

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.

Infrared

The nsc-ircc kernel module needs a patch to work, which you can download at http://shamrock.dyndns.org/~ln/linux/.

To apply the patch go to the root directory of the kernel source code and issue

patch -p1 < /path/to/downloaded/nsc-ircc-pnp.2.6.12.diff

After that you have to recompile and install the kernel as described on the kernel configuration page.

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

ENABLE="true"
DISCOVERY="true"
DEVICE="irda0"
DONGLE="none"
SETSERIAL=""

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
irtty_sir
sir_dev
irda

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

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:

#!/bin/sh
PIDFILE="/var/run/irattach.pid"

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

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.

Special Keys

Three software packages are needed:

• the ibm-acpi kernel module (get the latest version from http://ibm-acpi.sf.net) so that the kernel's ACPI subsystem gets the appropriate ACPI events.
• the ACPI daemon acpid, to run commands for these ACPI events
• and last but not least tpb, the Thinkpad Buttons program, so that the buttons that don't send ACPI events can be used too.

You can install acpid and tpb with

apt-get install acpid tpb

ibm-acpi

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

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

acpid

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:

event=ibm/
action=/etc/acpi/actions/ibm.sh "%e"

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

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

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

tpb

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/tpb_callback.sh tells tpb to run that script for the various events in recognizes.

I copied the example script from /usr/share/doc/tpb/callback_example.sh 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:

  (zoom)
                case $2 in
                        (on)
                                /usr/bin/X11/xzoom
                                ;;
                        (off)
                                killall xzoom
                                ;;
                esac
                ;;

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.

Suspend to RAM

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

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.