The only problem – and this is the main point of this post – was with the soundcard (an Intel HDA). The box has three audio outputs: headphone plugs front and back, and a tinny built-in speaker. Under Ubuntu all three outputs were switched on all the time, and it wasn’t possible to adjust them separately. The purpose of headphones in a shared lab environment is entirely defeated if the built-in speaker is always on! I tried fiddling with all of the multitude of ALSA settings, but nothing worked. It couldn’t have been a hardware problem, because it did the right thing under Windows.

So, the problem was narrowed down to the audio driver, snd-hda-intel to be specific. Some googling established that changing the model parameter to the module might have some effect on the output selection behaviour. Further searching established that the possible values are listed in Documentation/sound/alsa/HD-Audio-Models.txt in the kernel source.

To find out what the possible values are, you have to know which codec your card uses. This you can do by running

cat /proc/asound/card0/codec#0 | grep Codec

For the dx2300 the result was Realtek ALC888. Indeed, under the list of models for the ALC888, there is one called “3stack-hp” for “HP machines with 3stack”. Guessing that this was the correct one, I added to /etc/modprobe.d/alsa-base the line

options snd-hda-intel model=3stack-hp

and rebooted. Hey presto, suddenly the internal speaker switches off when headphones are plugged in.

tl;dr summary: If you have a dx2300 and you’re having problems with the audio under Linux, then add the line options snd-hda-intel model=3stack-hp to the file /etc/modprobe.d/alsa-base (at least in Ubuntu; your distro might put module options in a different file).

Now, on most distributions, I would just run tpb, and it gives a little on-screen display when I press one of the buttons. Ubuntu, however, is different. It has a special hotkeys subsystem which interprets the button presses on all sorts of laptops and passes them to a generic control program. Unfortunately, this system doesn’t know that the ThinkPad interprets the keys on its own; so every time you press a volume key, it gets interpreted in hardware and in software. This is really irritating, because the volume jumps in huge steps every time you press the button. And if you change the volume in software, they get out of sync and it all gets really complicated.

The appropriate behaviour, of course, would be to just display a notification without changing the software mixer’s volume; and I hope the Ubuntu folks will eventually implement this. For the meanwhile, anyway, there is a fix at least for Kubuntu. (Sorry, GNOME users, I don’t know what the equivalent solution is for you).

1. Install the package kmilo-legacy.
2. Arrange to have read access to the device /dev/nvram. On Feisty, at least, this required setting up a custom udev rule by creating a file /etc/udev/rules.d/50-user-custom.rules with contents KERNEL=="nvram", MODE="0664" and running chmod 0664 /dev/nvram to fix the permissions without rebooting.
3. Run kcmshell thinkpad, and then tick the “Run Thinkpad Buttons KMilo Plugin” option and untick the “Change volume in software” option.
4. Remove the file /usr/share/services/kmilo/kmilo_generic.desktop. (Or move it somewhere else, or rename it to something that doesn’t end in .desktop, or whatever else will stop KDE from seeing it.)
5. Log out and log in again.
6. Voila!

One useful side effect is that you will now get on-screen notifications when the other ThinkPad special buttons – like the brightness controls, the ThinkLight button, and so on – are pressed.