Tag: Rants

Soooo, for the last several days my main desktop system, recently installed with Xubuntu 9.10, has come up without networking services. The eth0 network interface is there, the (static!) IP is correct, Web browsing works… but NFS shares aren’t mounted and, upon poking around, other vital system services weren’t started.

Worse, networking can’t be manually started, either, and there are no diagnostic log messages.

Sometimes rebooting helps, sometimes it doesn’t. The problem is definitely timing-related, so sometimes pausing before signing in makes it work. Sometimes it doesn’t.

Come to find out that Karmic has revised how system services get started during boot. The intricacies are lost on me, but the old Unix-style /etc/init.d/ model is now obsolete. Documentation on upstart, the replacement, is sketchy at best.

We’re to type sudo service mumble start|stop|restart when we want to do things manually. Oh, maybe only start and stop have been implemented; everything else is defunct, but you can’t use the old method, either.

Except that something in upstart 0.6.3-11 is broken / different, to the extent that system services no longer start up properly. Evidently that upgrade happened here in the very recent past, part of the usual system update routine. I do this manually, but there wasn’t any heads-up notice mentioning “Oh, by the way, this update will kill your system”, so I just installed it.

Downgrading to -10 resolves the problem for many people, not including me, but that is not regarded as an actual fix. The older version has similar problems and downgrading just pushes the symptoms somewhere else. Part of the problem is that logging doesn’t (seem to) happen from upstart for any of the affected services.

Now, Linux distributions started as a way to bottle up various combinations of upstream programs in known-good configurations, so that we end-user types didn’t have to go through the Linux From Scratch effort. That model seems largely dead; each major distro now applies so much floobydust to their combination that any resemblance to the upstream programs is purely coincidental.

Like, for example, did you know that you’re probably not running OpenOffice, but Go-OO? Never heard of it? Me, either. Do the obvious search and see what you’ve not been told. Hint: Mono is still optional.

Long ago, in a universe far away, I actually enjoyed beta testing software. These days, I just want it to work; I have other things to do. It’s painfully obvious that Windows isn’t the answer, but it’s becoming evident that (at least) Ubuntu has lost sight of the “it just works” goal.

When vital parts of the system (like, for example, networking and system service startup) Just Don’t Work, something has gone badly wrong in the distro’s QA process. Yes, some problems remain hard to find, but when they’re reported (by other folks; I’m not first in line by any means) something should happen muy pronto.

When a desktop environment (like, for example) KDE can’t handle two independent monitors, but has all manner of glitzy 3D effects, the development effort has wandered off into the bushes of irrelevancy. The fact that KDE can claim to have fixed 10,000 bugs in the 4.3 release is not, to my mind, much to brag about.

To quote the immortal Iphigenia Deme, “That’s obscene-gerund enough!”

Right now, I have a column to finish and ship, with another right behind. With any luck, this system will hang together long enough to get those done, at which point I must devote some time to finding out which, if any, distros have a better recent track record.

Some early fiddling indicates Arch Linux, which is sort of like Linux From Scratch with bigger and sorta-kinda snap-together pieces, should do the trick. Most important: it’s agnostic with respect to which desktop environment you pick, unlike the GNOME-oriented Ubuntu chassis that sorta-kinda allows you to bolt on KDE or Xubuntu bodywork.

Quick summary of what’s needed: separate X sessions, right-hand session on a rotated-to-portrait monitor, Wacom tablet pinned to the left monitor, left- and right-handed trackballs. This configuration was fine in Kubuntu 8.04, got flaky in 8.10, and fell apart after that.

There may well be upstream problems with some of those pieces, which generally isn’t something a distro can fix. I contend they could better apply their resources to fixing such problems than screwing up something else.

More to follow…

I type well enough that OpenOffice’s default word completion isn’t helpful, so the first thing I do in the first document I open after a new installation is turn word completion off. Having just installed Xubuntu 9.10 with OpenOffice 3.1, I rummaged through the menus and couldn’t find that option. OK, I’ll let my fingers do the walking through the online Help.

Huh. For some inexplicable reason, the OOo help files aren’t installed by default in Kubuntu 9.10 or Xubuntu 9.10. I install them, only to find:

Word Completion
Set the options for completing frequently occurring words while you type.
To access this command…
Choose Tools – AutoCorrect Options – Word Completion tab
Enable word completion
Stores frequently used words, and automatically completes a word after you type three letters that match the first three letters of a stored word.

Which is absolutely correct, should you happen to be editing a text document at the time. Oddly enough, the Word Completion tab doesn’t appear in that dialog box when you’re editing a spreadsheet… but the setting applies to spreadsheets.

So.

• Save and close the spreadsheet
• Open a new, blank text document
• Do the menu dance just like the Help text describes
• Un-check the mumble Enable word completion box.
• Discard the text document
• Re-open the spreadsheet

There, now, wasn’t that obvious?

The recent Ubuntu 9.10 release uses HAL & UDEV to permit hotplugging USB mice / trackballs / tablets without killing the X server. This is a vast improvement over the Bad Old Days, with two minor issues:

1. You must now write an FDI file to configure your widget
2. There is absolutely no documentation on how to do that

Basically, you’re left to find a blog post somewhere that describes an fdi file for something similar to your widget, then puzzle out how to get from there to what you have. If you’re reading this (and you’re not one of the few dozen folks who read my posts for their pure amusement value), then you’ve probably stalled on Step 2 and arrived here via search engine.

So, here’s how the rest of the story goes down. I assume you’ve read all the various posts scattered here & there and have a vague notion of what goes into an fdi file and why it’s needed. I am not an expert on this stuff, but I did manage to get a few things working with an afternoon of concerted heads-down effort.

Start with the widget plugged in. Type:

lshal | less

Then rummage through that steaming pile until you find the stanzas that (seem to) have something to do with the widget. One stanza should mention a driver that sounds familiar: evdev, wacom, whatever you formerly found in /etc/X11/xorg.conf.

For example, I want to flip the buttons on my Kensington Expert Mouse (it’s really a trackball) to make it left-handed. The userland GUI mouse configuration isn’t relevant, because I also have a tablet and another trackball that must remain right-handed.

Here’s the appropriate stanza for the trackball, with the key lines highlighted:

udi = '/org/freedesktop/Hal/devices/usb_device_47d_1020_noserial_if0_logicaldev_input'
 info.capabilities = {'input', 'input.mouse'} (string list)
 info.category = 'input'  (string)
 info.parent = '/org/freedesktop/Hal/devices/usb_device_47d_1020_noserial_if0'  (string)
 info.product = 'Kensington      Kensington Expert Mouse'  (string)
 info.subsystem = 'input'  (string)
 info.udi = '/org/freedesktop/Hal/devices/usb_device_47d_1020_noserial_if0_logicaldev_input'  (string)
 input.device = '/dev/input/event7'  (string)
 input.originating_device = '/org/freedesktop/Hal/devices/usb_device_47d_1020_noserial_if0'  (string)
 input.product = 'Kensington      Kensington Expert Mouse'  (string)
 input.x11_driver = 'evdev'  (string)
 linux.device_file = '/dev/input/event7'  (string)
 linux.hotplug_type = 2  (0x2)  (int)
 linux.subsystem = 'input'  (string)
 linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.3/usb5/5-1/5-1:1.0/input/input20/event7'  (string)

I don’t know what the difference between info.product and input.product might be, but it looks like the same string for both.

Most of the fdi files I’ve seen try to match the largest possible number of different devices. I take the other tack: I only have one of the things and if I get something similar, it’ll likely be configured entirely differently. So, my fdi files assume one widget of that type, match its name directly without thinking, and are pared to the bare minimum.

I called the file 10-expertmouse.fdi and plunked it in /usr/share/hal/fdi/policy/20thirdparty. The proper directory seems to move around, the files get renamed, and so forth and so on. This was the correct file in the correct spot for the current Ubuntu 9.10 configuration…

<?xml version="1.0" encoding="ISO-8859-1"?>
<deviceinfo version="0.2">
 <device>
 <match key="input.product" string="Kensington      Kensington Expert Mouse">
 <merge key="input.x11_options.ButtonMapping" type="string">3 8 1 4 5 6 7 2</merge>
 </match>
 </device>
</deviceinfo>

You get the X button numbers using xev; write them on the trackball for future reference.

The default Expert Mouse trackball buttons are:

• upper-left = 2 — middle mouse button
• upper-right = 8 — page back in browsers, mostly
• lower-left = 1 — left mouse button
• lower-right = 3 — right mouse button

So the ButtonMapping line swaps (2 & 8) and (1 & 3). If you prefer not interchanging the 2 and 8 buttons, so as to keep the “page back” button on the upper-left corner, then 3 2 1 will suffice.

The scroll ring emits buttons 4 and 5 as usual. If you don’t like the rotation-to-up/down mapping you can (presumably) swap those using ZAxisMapping as you did before.

The syntax for, say, button mapping is whatever the driver expects and if you can find that doc, great. I used whatever I used in xorg.conf and that seems to work; it matches what the current evdev doc suggests. Leaving out all the config other than the button mapping line seems to work, but I’m sure that’s not a general rule. Maybe it only works with devices that are already automagically recognized as some sort of mouse or tablet.

With that fdi file in place, you just unplug and replug the trackball: no need to reboot or restart X or whatever you’re thinking.

Here’s the new stanza…

udi = '/org/freedesktop/Hal/devices/usb_device_47d_1020_noserial_if0_logicaldev_input'
 info.capabilities = {'input', 'input.mouse'} (string list)
 info.category = 'input'  (string)
 info.parent = '/org/freedesktop/Hal/devices/usb_device_47d_1020_noserial_if0'  (string)
 info.product = 'Kensington      Kensington Expert Mouse'  (string)
 info.subsystem = 'input'  (string)
 info.udi = '/org/freedesktop/Hal/devices/usb_device_47d_1020_noserial_if0_logicaldev_input'  (string)
 input.device = '/dev/input/event7'  (string)
 input.originating_device = '/org/freedesktop/Hal/devices/usb_device_47d_1020_noserial_if0'  (string)
 input.product = 'Kensington      Kensington Expert Mouse'  (string)
 input.x11_driver = 'evdev'  (string)
 input.x11_options.ButtonMapping = '3 8 1 4 5 6 7 2'  (string)
 linux.device_file = '/dev/input/event7'  (string)
 linux.hotplug_type = 2  (0x2)  (int)
 linux.subsystem = 'input'  (string)
 linux.sysfs_path = '/sys/devices/pci0000:00/0000:00:1d.3/usb5/5-1/5-1:1.0/input/input21/event7'  (string)

Shazam! Suddenly, the trackball is completely left-handed and that configuration survives hotplugging and all that happens without killing X.

Well, at least that’s what you’d expect, based on all the doc you can find on the Web.

As it turns out, something in the Ubuntu 9.10 udev mouse event hal X input button stack absolutely prohibits swapping buttons 1 and 3. You can verify this by looking at what the X button IDs are, using xinput:

xinput list --short
"Virtual core pointer"    id=0    [XPointer]
"Virtual core keyboard"    id=1    [XKeyboard]
"Logitech Logitech USB Headset"    id=2    [XExtensionKeyboard]
"Microsoft Comfort Curve Keyboard 2000"    id=3    [XExtensionKeyboard]
"stylus"    id=4    [XExtensionKeyboard]
"stylus cursor"    id=5    [XExtensionKeyboard]
"eraser"    id=6    [XExtensionKeyboard]
"Microsoft Comfort Curve Keyboard 2000"    id=7    [XExtensionKeyboard]
"Power Button"    id=8    [XExtensionKeyboard]
"Power Button"    id=9    [XExtensionKeyboard]
"Macintosh mouse button emulation"    id=10    [XExtensionPointer]
"Logitech USB Receiver"    id=12    [XExtensionPointer]
"Kensington      Kensington Expert Mouse"    id=11    [XExtensionPointer]

xinput get-button-map "Kensington      Kensington Expert Mouse"
1 8 3 4 5 6 7 2 9 10 11 12

Notice that buttons 2 and 8 are swapped, so you know the fdi file is in full effect.

You can force the button mapping using xinput like this (leaving 2 and 8 unswapped, for effect):

xinput set-button-map "Kensington      Kensington Expert Mouse"  3 2 1 4 5 6 7 8
xinput get-button-map "Kensington      Kensington Expert Mouse"
3 2 1 4 5 6 7 8 9 10 11 12

As you might expect by now, whenever the trackball disconnects itself, the xinput mapping Goes Away and the button handedness changes. That completely defeats the entire purpose of the whole obscene-gerund HAL fdi concept.

You might then think you could whip up a nice udev rule that would fire off xinput when the trackball reappears, but udev scripts execute outside the entire user-terminal-X paradigm: xinput complains that it can’t talk to the X server. Of course, you can’t hear it scream, because it’s not connected to a terminal…

Game over. Thanks for playing.

Equally of course, there’s no documentation for the Officially Approved way to configure these devices, if, indeed, there is a way.

Oh, and the real punch line? HAL is (about to be?) Officially Deprecated, so all this information is (or should be, shortly, we’re told) completely obsolete.

I would love to be proved wrong. Let me know…

Surprisingly, Xubuntu 9.10 not only enumerates all the mouse-like objects, but also allows you to set their handedness. That part works fine, but occasionally the Kensington trackball’s scroll ring stops working for a while: xev reports no “button” events happening. Then, unpredictably, it starts up again and works fine. I’d love to believe it’s a hardware problem, but I have two of the things and it happens with both of ’em.

Tomorrow: fun with a Wacom tablet.

Once again, it seems to be impossible to set a static IP address in the Latest & Greatest version of Kubuntu… with KDE 4.whatever, the triumph of glitz over usability.

This seems peculiar, as Unix-oid operating systems have networking built into their DNA since the beginning and every single Unix-oid system has a network connection of some sort. Evidently, all Ubuntu systems for the last couple of years have had only wireless NICs and nobody in their whole obscene-gerund testing universe has ever tried to set a static IP address.

Maybe I’m exaggerating, but it does look that way.

The fix is the same as in 8.10… as described there.

This time, use KPackageKit (aka, the KDE package manager) to remove network-manager & plasma-widget-network-manager. Evidently, the Gnome version is pooched, too.

Sheesh…