Shallow Thoughts : : May

How to fix usbview and /proc/bus/usb in Ubuntu Hardy

Ah, I so love progress. I was working with powertop to try to make my system more efficient, and kept seeing a USB device I didn't recognize showing up as a frequent source of wakeups. lsusb didn't show it either, so I tried firing up usbview.

Except it didn't work: on Hardy it brings up an error window complaining about not being able to open /proc/bus/usb, which, indeed, is not mounted despite being enabled in my kernel.

A little googling showed this was an oft-reported bug in Ubuntu Hardy: for instance, bug 156085 and bug 151585, both with the charming attitude I so love in open source projects, "No, we won't enable this simple fix that reverts the software to the way it worked in the last release; we'd prefer to keep it completely broken indefinitely until someone happens to get around to fixing it right."

Okay, that's being a little harsh: admittedly, most of the programs broken by this are in the "universe" repository and thus not an official part of Ubuntu. Still, why be rude to users who are just trying to find a way around bustage that was deliberately introduced? Doesn't Ubuntu have any sort of process to assign bugs in universe packages to a maintainer who might care about them?

Anyway, the workaround, in case you need usbview or qemu/kvm or anything else that needs /proc/bus/usb, is to edit the file /etc/init.d/mountdevsubfs.sh and look for the line that says:

# Magic to make /proc/bus/usb work

Uncomment out the lines immediately following that line, then either reboot or run the last command there by hand.

(In case you're wondering, usbview showed that the USB device causing the powertop wakeups was the multi-flash card reader. I'm suspecting hald-addons-storage is involved -- powertop already flagged hal's cdrom polling as the number-one power waster. I don't know why the flash multicard reader shows up in usbview but not in lsusb.)

Tags: ubuntu, usb
[ 21:45 May 31, 2008    More linux | permalink to this entry | ]

The falcon, the owl and the chickadees

We went for a little afternoon walk at RSA yesterday. I was out of the car and waiting for Dave when I saw motion out of the corner of my eye and heard a thump! of something hitting the ground a few feet away. Maybe something fell out of that tree? It sounded like it fell right ... there ... what's that? It looks almost like ... a bird? But why would a bird fall out of a tree? Is it dead?

And then the bird came to life, stretched its wings, and turned into a kestrel that exploded off the ground and flew away. I never did see if it caught whatever it was after, but I'm happy to have had the chance to see the little falcon make a strike so close to me.

Later, on the trail, a spotted towhee burst out of a tree and flew past us. Then a small woodpecker emerged from the same cluster of branches the towhee had just left. As we drew nearer we could hear quite a commotion up in the branches ... a dozen or more small birds, mostly chickadees, chattering and darting in and out like bees around a hive. It seemed centered on ... that unmoving spot there ... wait, doesn't it look a bit owl-shaped to you?

I snapped a few pictures, but none of the small owls in the bird guides have a facial pattern like this. It was smaller than a screech owl, but young screech owl is still my best guess.

And as long as I'm posting nature pictures, the bullfrogs are back at the Walden West Scum Lake. Just floatin' there, though ... they weren't making any noise or moving around.

Tags: nature, birds, owl, falcon, kestrel, bullfrog
[ 23:18 May 30, 2008    More nature/birds | permalink to this entry | ]

Crikey in Python, and generating key events with XTest

A user on the One Laptop Per Child (OLPC, also known as the XO) platform wrote to ask me how to use crikey on that platform.

There are two stages to getting crikey running on a new platform:

1. Build it, and
2. Figure out how to make a key run a specific program.

The crikey page contains instructions I've collected for binding keys in various window managers, since that's usually the hard part. On normal Linux machines the first step is normally no problem. But apparently the OLPC comes with gcc but without make or the X header files. (Not too surprising: it's not a machine aimed at developers and I assume most people developing for the machine cross-compile from a more capable Linux box.)

We're still working on that (if my correspondant gets it working, I'll post the instructions), but while I was googling for information about the OLPC's X environment I stumbled upon a library I didn't know existed: python-xlib. It turns out it's possible to do most or all of what crikey does from Python. The OLPC is Python based; if I could write crikey in Python, it might solve the problem. So I whipped up a little key event generating script as a test.

Unfortunately, it didn't solve the OLPC problem (they don't include python-xlib on the machine either) but it was a fun exercises, and might be useful as an example of how to generate key events in python-xlib. It supports both event generating methods: the X Test extension and XSendEvent. Here's the script: /pykey-0.1.

But while I was debugging the X Test code, I had to solve a bug that I didn't remember ever solving in the C version of crikey. Sure enough, it needed the same fix I'd had to do in the python version. Two fixes, actually. First, when you send a fake key event through XTest, there's no way to specify a shift mask. So if you need a shifted character like A, you have to send KeyPress Shift, KeyPress a. But if that's all you send, XTest on some systems does exactly what the real key would do if held down and never released: it autorepeats. (But only for a little while, not forever. Go figure.)

So the real answer is to send KeyPress Shift, KeyPress a, KeyRelease a, KeyRelease Shift. Then everything works nicely. I've updated crikey accordingly and released version 0.7 (though since XTest isn't used by default, most users won't see any change from 0.6). In the XSendEvent case, crikey still doesn't send the KeyRelease event -- because some systems actually see it as another KeyPress. (Hey, what fun would computers be if they were consistent and always predictable, huh?)

Both C and Python versions are linked off the crikey page.

Tags: programming, crikey, X11, python
[ 15:50 May 25, 2008    More programming | permalink to this entry | ]

Fixing scanner permissions on Hardy

Dave needed something scanned. Oh, good! The first use of a scanner under a new distro is always an interesting test. Though the last few Ubuntu releases have been so good about making scanners "just work" that I was beginning to take scanners for granted. "Sure, no problem," I told Dave, taking the sketch he gave me.

Ha! Famous last words. For Hardy, I guess the Ubuntu folks decided that users had had it too easy for a while and it was time to throw us a challenge. Under Hardy, scanning works fine as root, but normal users can't access the scanner. sane-find-scanner sees the scanner, but xsane and the xsane-gimp plug-in can't talk to it (except as root).

It turns out the code for noticing you plugged in a scanner and setting appropriate permissions (like making it group "scanner") has been removed from udev, the obvious place for it ... and moved into hal. Except, you guessed it, whatever hal is supposed to be doing isn't working, so the device's group is never set to "scanner" to make it accessible to non-root users. Lots of people are hitting this and filing bugs (search for scanner permissions), in particular bug 121082 and bug 217571.

Fortunately, the fix is quite easy if you have a copy of your old gutsy install: just copy /etc/udev/rules.d/45-libsane.rules from gutsy to the same place on hardy. (If you don't have your gutsy udev rules handy, I attached the file to the latter of the two bugs I linked above.)

Then udev will handle your scanner just like it used to, and you don't have to wait for the hal developers to figure out what's wrong with the new hal rules.

Tags: linux, ubuntu, scanner, udev, hal
[ 16:56 May 22, 2008    More linux | permalink to this entry | ]

How to set your time zone

My laptop's clock has been drifting. I suspect the clock battery is low (not surprising on a 7-year-old machine). But after an hour of poking and prodding, I've been unable to find a way to expose the circuit board under the keyboard, either from the top (keyboard) side -- though I know how to remove individual keycaps, thanks to a reader who sent me detailed instructions a while back (thanks, Miles!) -- or the bottom. Any expert on Vaio SR laptops know how this works?

Anyway, that means I have to check and reset the time periodically. So this morning I did a time check and found it many hours off. No, wait -- actually it was pretty close; it only looked like it was way off because the system had suddenly decided it was in UTC, not PDT. But how could I change that back?

I checked /etc/timezone -- sure enough, it was set to UTC. So I changed that, copying one from a debian machine -- "US/Pacific", but that didn't do it, even after a reboot.

I spent some time reading man hwclock -- there's a lot of good reading in that manual page, about the relation between the system (kernel) clock and the hardware clock. Did you know that you're not supposed to use the date command to set the system time while the system is running? Me neither -- I do that all the time. Hmm. Anyway, interesting reading, but nothing useful about the system time zone.

It has an extensive SEE ALSO list at the end, so I explored some of those documents. /usr/share/doc/util-linux/README.Debian.hwclock is full of lots of interesting information, well worth reading, but it didn't have the answer. man tzset sounded promising, but there was no such man page (or program) on my system. Just for the heckofit, I tried typing tz[tab] to see if I had any other timezone-related programs installed ... and found tzselect. And there was the answer, added almost as an afterthought at the end of the manual page:

Note that tzselect will not actually change the timezone for you. Use 'dpkg-reconfigure tzdata' to achieve this.

Sure enough, dpkg-reconfigure tzdata let me set the time zone. And it even seems to be remembered through a reboot.

Tags: linux, debian, ubuntu, vaio
[ 11:04 May 16, 2008    More linux | permalink to this entry | ]

Oak wants to be a quail, or maybe a wren

The young mockingbird fledgelings have decided they like us. Oak in particular took a liking to our backyard, and particularly the lawn. It seems he wants to be a quail when he grows up: he loves to run (not hop) around the yard, and flies only when threatened (though once he gets going, he flies quite competently). When he's not being a quail he practices being a wren, cocking his tail up the way wrens do. I managed to get couple of pictures of Oak.

Cedar likes the backyard too, but stays above ground in the chinquapin or the orange tree. In the evenings, they sing a duet, somewhat lower EEPs from Cedar and higher ones from Oak (Oak can sing two notes, but when Cedar's singing Oak takes the soprano line). Holly remains in the front yard, a distant third EEP.

Meanwhile, I've finally managed to attract some goldfinches to the thistle sock hanging outside the office window. Photos (not good ones) here.

Update: Oak continued to play quail in the backyard for the next week, gradually spending more time flying and less time EEPing for his parents. The turning point was when Oak and Cedar discovered the sweet petals of the guava tree's flowers. It takes some flying skill to get into a guava tree: you have to hover a bit while you pick your entry spot, then power your way in. The chicks begged their parents to get them guava petals, but when the petals didn't materialize fast enough they got motivated to improve their flying skills to get their own petals. By May 22 they were pretty much fending for themselves, emitting an occasional half-hearted EEP but mostly foraging for themselves. I see them both most evenings, but I never see three chicks at one time; I may have been wrong about there being a third chick, though it certainly seemed that way on that first day.

Tags: nature, birds, urban wildlife
[ 21:46 May 12, 2008    More nature/birds | permalink to this entry | ]

Feeding Fledgelings

After I wrote about the mockingbird fledgelings the other day, someone asked me how long the parents keep feeding them. I checked past blog entries -- that year they fledged on June 25, were still being fed on July 10 and were still EEPing but no longer being fed on July 20. A little over two weeks.

Two of this year's chicks, who fledged four days ago, can fly pretty well now for short bursts, but they tire very quickly and can't stay up for a long flight.

Just now, at sunset, Oak (I'm naming them for to the trees they ended up in when they fledged) flew from the oak over to the back porch roof and spent ten or fifteen minutes begging from there, in nice view of my office window. He was EEPing louder than the other chicks, and both parents were feeding him as fast as they could find bugs. Oak is as big as a towhee, and fat and fluffy, with a spotted breast and a short stubby tail less than two inches long. He still has some of that scrowly wide yellow bill that says "Feed me, mama!"

At one point a parent showed up with a pyracantha berry, but Oak was already being fed. The parent tried a little squawk, maybe to see if Cedar wanted anything, but almost dropped the berry in the process. So with an air of "oh, what the heck!" it swallowed the berry.

Then Cedar started crying from the chinquapin (or whatever the weird tree in the backyard is) and drew the parents' attention away from Oak. After another few minutes of fruitless eeping Oak decided to get some of that action and joined Cedar. Then they both flew down to the lawn, where for the first time I could see both at the same time. Cedar is a lot slimmer than Oak, but with a longer tail, maybe half the length of an adult's.

Oak was in the wildflower bed, actively hunting for food and occasionally finding something to swallow, though I don't have a lot of confidence that they were insects rather than dirt clods. Cedar wasn't hunting for food very actively, but took a few desultory pecks at the pavement and once picked up and swallowed something (a piece of a leaf, I think). Every now and then one parent would glide in from the front yard, and whichever chick noticed it first and eeped would get fed.

I haven't seen Holly today. I thought I heard some eeping from the direction of the holly in the front yard, but never definitely located the third chick.

The evening wore on, though, and the chicks have found trees to roost in for the night and have finally stopped eeping. Mom is taking a well-deserved break while Dad sings the family a lullaby.

Tags: nature, birds, urban wildlife
[ 22:00 May 08, 2008    More nature/birds | permalink to this entry | ]

Chicks everywhere

It's definitely spring now! The air is filled with the cheeping of baby birds demanding feeding.

I thought we didn't have a nesting mockingbird pair this year, because there's been almost no singing. I've heard chicks cheeping from the yard across the street, but nothing in our yard.

Until today, that is. This morning, there's a mocker chick in the holly tree in the front yard and another one in the red oak in the back yard, both making noisy demands to be fed. The parents are having a hard time, between hunting and flying back and forth between the two chicks.

The chicks are staying too high up for any good photos, but they're easy to see in binoculars. They're a bit bigger than house sparrows, but still very baby-like, with short tails, fluffy spotted downy chests and big wide yellow bills. They can flutter from branch to branch pretty well, but aren't comfortable going farther than that, especially on this windy morning. I wonder if the wind explains how the two fledgelings ended up in trees so far apart?

(Update a couple of days later: turns out there are actually three chicks. One of them is confident enough to fly in the open and perch on power lines; the other two haven't moved from their respective trees.)

I'm hearing lots of California towhee pings, too (they make a noise like a submarine sonar ping) and there's a towhee pair foraging more actively than usual in the garden, so I'm pretty sure there are some towhee chicks somewhere nearby, getting ready to fledge.

After watching the fledgelings in the yard for a while, I decided to take a peek at some Peregrine falcon webcams. The IndyStar falcon-cam is easy -- two views to choose from, and it pops up a window with an image that refreshes every 30 seconds. Works everywhere. The San Jose falcon-cam is a lot trickier, since their page is loaded with elaborate "pop up the Microsoft Windows Media Player plug-in, and if you don't have that, you're out of luck" code. But Sarah and I and some folks in #linuxchix worked it out a few months ago before there was much to see: it's actually a Realplayer stream, which realplay itself can't play but vlc sometimes can: vlc rtsp://bird-mirror.ucsc.edu/birdie-sj.sdp

It doesn't work every time -- I have to try it five or six times before I get anything. I'm told that this is a common problem -- RTSP streams are notorious for having problems with NAT, so if you're anywhere behind a firewall, keep cheeping with vlc and eventually the server will feed you some falcon images.

Tags: nature, birds, urban wildlife
[ 13:24 May 04, 2008    More nature/birds | permalink to this entry | ]

Two font mysteries solved

This has been a good week for fonts: two longstanding mysteries solved.

The first concerns the bitstream vera sans mono I've been using as a terminal font in apps like rxvt and xterm. I'd been specifying it in ~/.Xdefaults like this:
XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-*-*-iso10646-1

The mystery is that I'd noticed that in xterm, the font looked slightly different -- slightly uglier -- than in rxvt (both apps use the same X class name of XTerm). It was hard to put my finger on what was different -- the shape of all the letters looked the same, but it just seemed a little more ragged, and a little less compact, in xterm. I figured it was just a minor difference in their drawing code, or something.

Well, I was fiddling with fonts (trying to get the new-to-me "Inconsolata" font working) and I noticed that iso10646 bit. I didn't know what 10646 was, but shouldn't it be 8859-1 or 8859-15, the codes for the Latin-1 alphabet? After finishing up my Inconsolata experiments, when I set the font back to Vera I changed the line to XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-*-*-iso8859-15 and moved on to other things.

Until the next morning, when I booted up to a surprise: my main terminal window no longer fit on the screen. It seems it had reverted to the other (uglier) version of Vera Sans Mono, which is also very slightly taller, so instead of being a couple of lines shorter than the screen height, it was a couple of lines too tall to fit.

I checked .Xdefaults -- yes, it was still Vera. What was going on? I finally remembered the one thing I had changed: the language setting on the font, from 10646-1 to 8858-15. I changed it back: sure enough, now the font was pretty again and the terminal was short enough to fit.

I fired up xfontsel and did some experimenting. It turned out the difference between the two almost-identical Vera sans mono bold roman fonts is a field xfontsel calls "spc". It can be either 'c' or 'm'. The 'c' version is the pretty, compact font; the 'm' is the uglier, taller one. For some reason, specifying 10646-1 makes "spc" default to 'c', while 8859-15 makes it default to 'm'. But specifying 'c' in the font specifier gets the good version regardless of which language is specified.

So this would work: XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-c-*-*-*

But then I read up on 10646-1 and it turns out to mean "the whole unicode character set". That sounds like a good idea, so I kept it in my font specifier after all: XTerm*font: -bitstream-bitstream vera sans mono-bold-r-normal-*-12-*-*-*-c-*-iso10646-1

(For the moment I still didn't know what spc, c or n meant; read on if you're curious.)

The second insight concerned a longstanding mystery of Dave's. He has been complaining for quite a while about the way Ubuntu's modern pango-based apps all refuse to see bitmapped fonts. (It bothered me too, but less so, because the terminal and editor apps I use can see X fonts.)

Dave has an Ubuntu install on one machine that he's been upgrading release after release, which does see his bitmapped fonts. But any fresh Ubuntu installation fails to see the fonts. What was the difference?

We knew about the trick of going into /etc/fonts/conf.d, removing the symbolic link 70-yes-bitmaps.conf and replacing it with a link to /etc/fonts/conf.avail/70-yes-bitmaps.conf ... But doing that doesn't actually change anything, and bitmap fonts still don't show up.

The secret turned out to be that you need to run fc-cache -fv after changing the font/conf.d links. This apparently never happens on its own -- not on a reboot, not on installing or uninstalling font packages. Somehow it had happened once on Dave's good install, and that's why it worked there but nowhere else.

I'm not sure how anyone is supposed to find out about fc-cache -- there's no man fontconfig, and the /etc/fonts/conf.avail/README offers no clue, just misleadingly says "Fontconfig scans this directory". man fc-cache mentions /usr/share/doc/fontconfig/fontconfig-user.html, which doesn't exist; it turns out on Ubuntu it's actually /usr/share/doc/fontconfig-config/fontconfig-user.html. But wait, that's just an html-ized manual page for fonts-conf, so actually you could just run man fonts-conf ... your guess is as good as mine why the fc-cache man page sends you on a hunt for html files instead.

man fonts-conf is good reading -- it even solves the mystery of that spc parameter. It stands for spacing and can be proportional, dual-width, monospace or charcell. Aha! And there's lots more useful-looking information in that manual page as well.

Tags: linux, fonts, i18n, mysteries
[ 15:58 May 02, 2008    More linux | permalink to this entry | ]