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

Also, Netcraft should really know better. Check out the Netcraft information for the UCT website. It’s not like this information hasn’t been around for a while; all the open-source whois tools started using the AfriNIC server long ago. (I myself submitted the bug and patch for FreeBSD.) So really, they need to get with the program.

Update: I may have maligned Netcraft unfairly. Although they get the UCT information wrong, most SA sites do show up correctly. SAIX, for example. I’ve sent them a bug report.

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…

I’ve also found the time to finally upgrade the Wordpress install that runs this blog. (It was still at 2.3.3, and the current is 2.6.5!) As you will notice, I’ve also returned to the default Wordpress theme. I know it’s boring, but it actually looks fine and it works well enough.

My phone and DSL line started having issues about a week ago, and it was becoming progressively worse: there was heavy crackle on the voice circuit, and the DSL line was showing about 20% packet loss. On Thursday evening I reported the problem through the fault reporting website.

Early this morning they phoned me and informed me that the technician would be able to visit later today, and he did indeed arrive at about 11. Because of the nature of the problem – an issue with the lines between my building and the distribution box – he had to travel back and forth a few times between my flat and the box on Main Road, so the process did take a while. Nonetheless, throughout the experience he was friendly, efficient, and competent.

I should mention in particular that at no point did I have to deal with the notorious callcenters and the interminable on-hold music. I didn’t have to spend any of my cell-phone minutes waiting for someone to take note of my problem. All I had to do was fill out the form on the website, and wait for them to get back to me – which only took two working days.

This is a marked contrast from my experience two years ago with my parents’ broken phone line, where it took five days and many hours on the phone to get the DSL and line repairs departments to agree on who was responsible for fixing the problem.

Where does the data come from?
The City of Cape Town has posted on the web the load shedding timetable as an Excel spreadsheet. I do a bit of manual manipulation on the spreadsheet before dumping it to a CSV file. Then I have a script which parses the CSV file and generates a SQLite database.

What’s the bot coded in?
Python. (Of course.) It uses the xmpppy module to do the Jabber communication, and SQLObject for the database.

How does it work?
The bot is actually made up of two separate components. There is a control daemon that is always available on Jabber, which accepts subscriptions and responds to your commands. Then there is a queuerunner fired by cron at the appropriate times, which sends the warning messages; it uses a negative Jabber priority, so your messages to the control daemon will never go to the queuerunner by accident.

How many users do you have?
As of 18 April, there are 20 users. The average user subscribes to warnings for two different locations.

To set it up, ask your Jabber client to subscribe to loadshed@frith.co.za – in Pidgin that’s the “Add Buddy” command, in GMail it’s “Invite to chat”. The loadshed bot will accept your subscription, and reciprocate with a subscription request to you. When you accept it, the bot will send you instructions about how to proceed.

You can search the list of suburbs by sending the message “search [text]“, which will give you a list of suburbs in the City Council’s list with a name matching “[text]“. Then you can subscribe to warnings for a suburb with “subscribe [number]“, where [number] is the number that was listed next to the suburb in the search results. There’s also a “list” command which shows what susburbs you’re subscribed to; and “unsubscribe [number]” which works in the same way as “subscribe”.

The bot will send you warnings 15, 10, 5, and 2 minutes before the load shedding period is scheduled to start. A planned future development is to make the warning times configurable.

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 the process I (through my own stupidity) lost the images that should appear in some of the posts. I think I have a backup at home, so they may or may not reappear later.

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