This Time Self-Hosted
dark mode light mode Search

One thing I’ll always envy Mac OS X for

Is the fact that X11 is an additional component rather than the main GUI engine. Why this? Because Xorg is years behind anything usable out of the box for something more complex than very very basic configuration.

What’s going on? Well today my Logitech keyboard was acting up on me for the last time, I got tired of having to press Alt three times to get it right, and I decided to put it beside for a while. I probably just have to clean it up, but I finished the compressed air so I cannot do it at the moment. I decided to give a try to the Apple keyboard I bought some months ago and that I used for the data entry job (and still some other times), as it has a very smooth keypress, and, well, I wouldn’t buy a new keyboard before trying to clean the old one. So I plugged it in, and it started typing, although the Control and Command (Apple) keys were swapped.

I tried poking around the config but nothing happened. I ended up changing kernel configuration, but still nothing; after some more poking on xorg.conf I was able to configure it with evdev. The problem is that XKB wasn’t loading the keymaps, causing me to lose the deadkeys of us(alt-intl) that is my favourite way to type text.

After literally hours of log reading and tests and about twelve different xorg.conf versions, I was finally able to find the cause, by running startx from the laptop SSH’d on Enterprise: /var/tmp/xserver-0.xkm was stale from a previous Xorg run that crashed, most likely, and xkbcomp was unable to delete it as it was being ran as my user. Removing the file solved the problem.

Nowhere in the logs was xkbcomp present: the Xorg.0.log file only said that it wasn’t possible to load the XKB keymaps, but didn’t specify what failed. setxkbcomp didn’t help either.

Now I don’t really pretend to have here and now magical input support, like OSX has (and it’s a Microsoft employee who says that!), but it would be nice if there was proper documentation and some diagnostic output from the tools. I say proper documentation because the manpage for evdev driver present in 1.2.0 release refers to some options that are not used by it anymore and are only present in 1.1.

Anyway, I have now my setup working, kudos to evdev as it’s developing pretty well, especially considering that now different source of inputs are being just rewritten to use the event interface. I think this is a good idea for Linux: it doesn’t matter if it’s a keyboard, a mouse, a joystick, the ACPI buttons of a chassis, or an IR remote: it’s just user input. Too bad that my TV card’s IR receiver is not supported (and I don’t have time to work on it).

Now, I wanted to write some entries about other stuff, but after wasting three hours trying to get the keyboards working, I really lost the will to write.

Update (2017-04-28): I feel very sad to have found out over a year and a half later that Michael died. The links in this and other posts to his blog are now linked to the archive kindly provided and set up by Jan Kučera. Thank you, Jan. And thank you, Michael.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.