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

Problem is, I’d like to stay connected to the UCT network as well so that I don’t use up my precious* data bundle for UCT services, and this requires a bit of custom routing magic. So I have a script:

#!/bin/sh
GATEWAY=137.158.32.97
route add -net 137.158.0.0/16 gw $GATEWAY
route add -net 192.48.253.0/24 gw $GATEWAY
route del default
route add default ppp0

137.158.0.0/16 and 192.48.253.0/24 are the UCT netblocks, and 137.158.32.97 is the router on the subnet that I’m mostly using at the moment. ppp0 is, of course, the name of the interface associated with the HSDPA connection.

The problems with this script currently are that I have to edit it to change the gateway for each subnet that I’m on, that I have to run it manually each time I connect, and that it doesn’t restore the original routing when I disconnect. The first and third problems should be reasonably easy to solve, but the second will probably require that I dig into the mysterious world of NetworkManager. (Cue dramatic music.)

*It’s ourssss, my preciousss… they wants to take it from us, the nasssty Vodacom…

Until very recently, using my external monitor with my laptop required several irritating customisations – you can see the details in my earlier post:

1. To have it switch on, and run in Xinerama mode along with my laptop panel, required fiddling with MetaModes and other fiddly settings of the radeon driver.
2. To drive it at its native resoution (1440×900) i had to add a custom modeline to xorg.conf (except on Fedora, for some reason).
3. If the X server originally started without the external monitor attached, then it would have to be restarted to detect the monitor once it was attached. And restarting X means having to log out and lose all my application state.

XRandR 1.2 has removed all three of these irritations. It requires (almost) no preconfiguration, autodetects all resolutions correctly, and detects monitors when they are plugged in without a restart.

Let’s take a brief look at some of what XRandR can do: this is basically what I do with it daily. Note that at the moment graphical tools to control XRandR are still under development and none are really at a releaseable state (in my opinion); but now that the infrastructure exists in the X server and the drivers, tools to control it will come soon. What I use here is the command-line tool, sensibly named xrandr.

Let’s say I boot the computer without the external monitor plugged in. As you would expect, my desktop is automatically set to the native resolution of the laptop panel (in my case, 1024×768). I can see what resolutions and refresh rates are available:

$ xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2464 x 1024
VGA-0 disconnected (normal left inverted right x axis y axis)
DVI-0 disconnected (normal left inverted right x axis y axis)
LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1024x768 60.0*+ 60.0
   800x600 60.3
   640x480 59.9
S-video disconnected (normal left inverted right x axis y axis)

This tells me that the only attached monitor is the laptop panel (called LVDS); that it can run at the three different resolutions listed, and at the refresh rates listed next to the resolutions. The “*” indicates the mode that is currently in use, and the “+” indicates which mode is preferred by the monitor.

If i wanted to, I could switch to some other resolution:

$ xrandr --output LVDS --mode 800x600

But that looks horrible, so I switch back to the preferred resolution:

$ xrandr --output LVDS --auto

Now everything’s back to normal. There are various rotation and reflection options as well, but I won’t discuss them because (a) they’re silly, and (b) you can look them up in the man page if you need them.

Here comes the interesting part. Now I plug in my external monitor. Nothing happens immediately; but if I run the query command, there’s some new information:

$ xrandr -q
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2464 x 1024
VGA-0 connected (normal left inverted right x axis y axis)
   1440x900 59.9 + 75.0 59.9
   1280x1024 75.0 59.9
   1280x960 74.9
   1360x765 59.8
   1152x864 74.8 60.0
   1024x768 75.1 70.1 65.7 60.0
   832x624 74.6
   800x600 72.2 75.0 60.3 56.2
   640x480 75.0 72.8 66.7 60.0
   720x400 70.1
DVI-0 disconnected (normal left inverted right x axis y axis)
LVDS connected 1024x768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
   1024x768 60.0*+ 60.0
   800x600 60.3
   640x480 59.9
S-video disconnected (normal left inverted right x axis y axis)

So I can now see all the modes supported by the external monitor (called VGA-0). I switch the monitor on:

$ xrandr --output VGA-0 --auto

This switches on the monitor in a sort-of clone mode: the output from the laptop panel is duplicated on the external monitor; but because the external monitor is larger, it appears in the top left, and the desktop size expands to the size of the external monitor. (At the moment, GNOME doesn’t handle this too well, and the GNOME panel stays in the same place, meaning that it’s in the middle of what’s visible on the external monitor.) So now I can switch off the laptop panel:

$ xrandr --output LVDS --off

(GNOME handles this correctly and moves the panel.)

Now, if you look at the query output above, you’ll see that the monitor claims that its preferred mode has a refresh rate of 59.9Hz, although it also supports a 75Hz mode at the same resolution. I find the latter mode more friendly on my eyes, so I switch to it:

$ xrandr --output VGA-0 --mode 1440x900 --rate 75.0

I want to use the extra desktop space available on my laptop panel; but by default it would just be cloning the output of the external monitor, which wouldn’t help. So I use another option to position the outputs:

$ xrandr --output LVDS --auto --left-of VGA-0

This places the panel to the left of the external monitor. There are corresponding --right-of, --above and --below options.

Finally, I want to switch off the external monitor so that I can take my laptop away from the desk:

$ xrandr --output VGA-0 --off

Now I’m back where I started.

This is all very cool, but there are a couple of cautionary notes. The necessary drivers are only included in very recent distro releases (Ubuntu 7.10 and Fedora 8 in particular). Currently only the open-source Intel, Radeon and NV drivers support XRandR 1.2; neither the ATi nor the NVIDIA proprietary drivers support it. For now, you pretty much have to use the command-line tool – though that will change quickly. Finally, you sometimes have to set the Virtual option in xorg.conf to indicate the largest possible size of your desktop – but this is a one-off setting, and I hope that distros will start setting it to a sensible default automatically.

In other news: Microsoft loses anti-trust appeal. All in all, a bad day for IP trolls and monopolists.

SCO lost two-thirds of its value over the weekend after the ruling. It might not be long before they file for Chapter 11 bankruptcy, I imagine.

(click to expand)

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

was quite disturbing. Not in a bad way; it just felt really weird to see the number 3 there. Ever since I’ve been involved with free software, the GPL has been at version 2. I can’t count the number of times I’ve copied those familiar paragraphs into the beginning of a source file, or that familiar COPYING file into a new project.

Other than that, I’m quite happy with the new license. Despite the FUD that has been spread about it, it actually seems perfectly reasonable. The new anti-”tivoisation” and patent licensing clauses are appropriate to the aims of the FSF. True, they inconvenience the “corporate open source” world, which sometimes seems to want to use free software for the convenience while actually avoiding granting users the freedoms we expect. I don’t see this as a problem.

The biggest problem I do see is that GPLv2 and GPLv3 are mutually incompatible. We already have so much trouble with incompatible licenses between different bits of free software with essentially similar licensing goals and it’s irritating that we now have another incompatibility to deal with. (On the other hand, GPLv3 is now compatible with the Apache License, which is an improvement.)

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.

Later that day I was doing the same thing, but in Linux – using Banshee to rip and encode the same CD to AAC (I would use OGG if I didn’t have an iPod). I was also surfing the web with Epiphany, and there was no noticeable slowdown in the web browser. No doubt the ripping/encoding process took a little longer because of the CPU time provided to other processes; but I imagine that most users would rather have their backround tasks take a little longer in return for being able to carry on using the computer while they run.

This is something where Linux really excels: the scheduler is really very good. Windows’ is simply pathetic, and completely unsuited for an interactive system (which doesn’t really make sense, since Windows has never been used as a batch system, as far as I know!).

Section "Device"
Identifier "ATI Technologies, Inc. M22 [Radeon Mobility M300]"
Driver "ati"
BusID "PCI:1:0:0"
Option "DDCMode" "true"
Option "MonitorLayout" "LVDS, TMDS"
Option "MergedFB" "true"
Option "MetaModes" "1024x768+1440x900"
EndSection

and, especially, a special modeline for the 1440×900 mode:

Section "Modes"
Identifier "Modes"
Modeline "1024x768" 76.16 1024 1080 1192 1360 768 769 772 800
Modeline "1024x768" 64.11 1024 1080 1184 1344 768 769 772 795
Modeline "1440x900" 100.000 1440 1456 1464 1480 900 916 924 940 -hsync -v
sync
EndSection

and then the right display settings:

Section "Screen"
Identifier "Default Screen"
Device "ATI Technologies, Inc. M22 [Radeon Mobility M300]"
Monitor "Generic Monitor"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1440x900" "1024x768"
Virtual 1440 900
EndSubSection
EndSection

Even better, AIGLX compositing just works with the open-source drivers; so after installing Beryl I have all the fancy window effects without the hassle and complication of running the Xgl server that you have to use with the fglrx drivers. Admittedly, 3D is somewhat slower with the open-source drivers than it was with the ATi drivers, but it’s not as if I use 3D stuff a lot.