Virtually rewiring laptop keyboards

You may remember I had problems with my laptop a few months before, because it refused to boot until I unplugged the CMOS battery. This by the way happened again, to the point I need to remember to buy a new CMOS battery next time I’m in the States (the european prices are crazy insane, and I’ll be back reasonably soon). This is the start of a story for the same laptop, but it has nothing to do with the CMOS in this case.

I have recently replaced my work laptop with an HP Chromebook from the previous MacBook Pro I was using. If you’re curious for my reasons, they boil down to traveling too much, and the MBP being too heavy. I briefly considered an Air, but given the direction they go to, the Chromebook works better for the work needs.

If you didn’t know, Chromebooks don’t come (by default) with a Caps Lock key. Maybe it’s a public service, making it more difficult to shout on the Internet, maybe it’s because whoever designed the keyboards was nostalgic of the control key in place of the caps lock, I’m not sure. Instead of moving the control key, they introduced a new search button, which triggers the search box as well as function as a “Fn” modifier, to access features such as page up/down, home and end. I liked the approach and it’s actually fairly handy. Unfortunately it means that now I have a third way (in addition to the Asus and the Dell keyboards) to access these functionalities, which makes my muscle memory suffer badly. It also meant I kept typing all-caps on my Asus laphttps://lkml.org/lkml/2008/6/6/480top when I tried using the modifier (and failed) and that was pissing me off.

On Apple USB and Bluetooth keyboards there is a Fn button, but it’s handled entirely in software. Indeed if you have one such keyboard, particularly the 60% version (those without numpad and separate isles for movement keys), and you want to use it on Linux you need to enable a kernel module to implement the correct emulation. I know that because it bit me when they first introduced it, as I was using a full-size Apple keyboard instead, and the numlock emulation was making me unable to type.

This is give or take the way it works on the Chromebook, mostly out of necessity of sharing the Fn modifier with the Search button. And it allows you to change which key is Search/Fn in software, which is handy. Why can’t I do that with my Asus laptop? Well, I can disable the Caps Lock at least, and replace it with Control like so many people do already, after all I use Emacs and they tell me it’s much better to use Emacs that way (I don’t know about it, I tried it briefly, but my muscle memory works better with the pinky-control). But that’s not exactly what I want.

I could try remapping Ctrl+arrows to behave the same way as Fn+arrows but that’s not quite what I want either because then I lose the skip-ahead/forwards that I want from Ctrl+arrows. So I need to come up with alternatives. Much as I wish this was going to be a step-by-step procedure to fix this, it’s not, and it’s instead a musing of what may or may not work.

The first option would be to implement the Fn in software, either by the kernel, X11 or libinput level. This could actually be interesting to make the Fn behaviour of Apple keyboards generic enough. I don’t really know where to start with that one, because between systemd, libinput and Wayland the input layers flow changed so much that I’m completely lost.

The other option is more daring and possibly more interesting: rewiring the laptop keyboard by changing what the keys actually send over the PS/2 bus. As Hector suggested over twitter, the keyboard is handled as part of the Embedded Controller (EC) firmware, and it is not untold of modifying a laptop’s EC although a quick search doesn’t turn up anyone doing so on an Asus laptop to change the keyboard scancodes.

Does it mean I can do it? Does it mean I will? I’m not sure yet. Part of the problem is that playing around with an EC is the kind of thing that can easily brick your laptop, and this is currently my only Linux environment in which I do actual work. I could try to re-target my HTPC to be a workstation, and then hack on this laptop like it’s disposable, but the truth is that I spend enough time in the air that I really want to have a laptop, at least as a secondary system.

The first problem is figuring out how run the update. The first step would be figuring out where the EC firmware is. In Matthew’s posts, he found a promising area of the update file within the image, based off a size and the (known) EC firmware version. In my case I don’t have that luck, since the only version I can see from the Linux host is the BIOS revision, which is 219. On the other hand, if I look at the Asus download page versions 212 and 216 explicitly mention an EC firmware update, so it would at least make it easy to verify whether my guess is right if I am to guess which area of the firmware image is the EC firmware itself.

But it might be easier. UEFITool supports reading these update files, as they are AMI Aptio capsules, and it should be possible then to extract a listing of object trees and checksum that tells you what actually changed between two versions. Unfortunately that would only tell you what and not how, but it’s a starting point. Unfortunately, the documentation of the tool itself already points out that many AMI features are not implemented because of the author’s NDA. Of course the moment when you look for aptio capsule format you find a post by Nikolaj’s about the AFU utility.

This may be a throw-in post just to give a random idea, or it may follow up with more details, and maybe some code to get the list of changed files in the capsule, but I have not started on this yet and I’m not sure I’ll do. The tools are out there, and it would be an interesting game to play, the problem is, nowadays, mostly the time.

Of the two options, implementing the second Fn key (without changing the one that is there) is obviously the one that has the most potential to be useful: if it can be made generic enough, it can be used on any keyboard, laptop or not, and might allow simplifying the Fn key handling in the Apple keyboards, by moving it away from a Apple-specific driver. So if someone has ideas of where this should fit nowadays, I’m happy to hear about those.

Back to Cinnamon!

Okay after my negative experience I’m now back to try Cinnamon, and I have a quite different story to tell.

First of all, thanks to Julian, I found that the issue I was having with the keyboard only involved my user’s settings, and not the code by itself. After a bit more fiddling around, I found a more detailed case where this happens.

My keyboard layout of choice is the so-called US Alternate International (us alt-intl); unfortunately even with the recent improvements in Input hotplug for Xorg, it seems like configuring Xkb on the configuration file, or on the directories, is not recognized by the evdev driver (at least), which is why I configured it with GNOME, Xfce, and, by reflection, Cinnamon, to change the layout of the keyboard — and that’s where the problem lies. When GNOME3 or Cinnamon are started, and they set the keyboard layout (both do it the same way as in both cases you configure it through GSettings), the Alt_L and Meta keys get somehow swapped… but not in all cases, as Emacs was still getting it right (which meant that just switching the two is not going to help me).

I guess I should track it down even further than this, but for the moment, I solved this by using setxkb in my ~/.xsession file, and that doesn’t seem to cause any trouble.

The other issue I reported, was that clutter is unstable when using nvidia hardware; to be precise, the issue is with nvidia-drivers (surprised?), and it’s actually the second issue that I find with their drivers in the last few weeks: the other was Calibre being able to get Xorg to eat so much memory that the system gets unresponsive, just by the sake of being launched, and add to that Skype that was unable to render *at all*….

So I decided to give a try to what Pesa suggested me to solve the Skype (Qt) issue: I decided to try the nouveau driver. Actually I wanted to try that a couple of weeks ago, but after reading through their website I wasn’t sure that my video card (NVIDIA GT218) was supported or if I had to deal with dumping the firmware out of the nvidia drivers and whatever else… but the other day, after screwing my own system over, and needing to boot from SysRescue, I found out that the driver they load is … nouveau, and it worked decently well.

So since this is weekend, and the time was right, I decided to give it a try — and the results are great! Clutter works fine, Cinnamon works fine, and while I haven’t tried anything that is running in OpenGL proper yet (no games), and Google’s Maps GL reports not working with this implementation (not that I care much), it works definitely well enough for what I usually do. I haven’t tried audio out on the DisplayPort connection, but it’s not like I’ve ever tried it before… Suspension works very fine.

And yes for now my experience with Cinnamon is terrific!

International problems

I’m probably one quite strange person myself, that I knew, but I never thought that I would actually have so many problems when it comes to internationalisation, especially on Linux, but not limited to. I have written before that I have problems with my name (and a similar issue happened last week when the MacBook I ordered for my mom was sent by TNT to “Diego Petten?” – which wouldn’t then be found properly by the computer system when looking up the package by name), but lately I have been having even worse problems.

One of the first problem has happened while mailing patches with git on mailing list hosted by the Kernel.org servers; my messages were rejected because I used as sender “Diego E. ‘Flameeyes’ Pettenò”, without the double quotes around. For some RFC, when a period is present in the sender or destination names, the whole name has to be quoted in double quotes, but git does not seem to know about that and sends wrong email messages that get rejected. Even adding the escaped quotes in the configuration file didn’t help, so at the end I send my git email with my (new) full name “Diego Elio ‘Flameeyes’ Pettenò” even if it’s tremendously long and boring to read, and Lennart scolded me because now I figure with three different aliases in PulseAudio (on the other hand, ohloh handles that gracefully ).

Little parenthesis, if you’re curious where the “Elio” part comes from; I have legally changed my name, adding “Elio” as part of my first name last fall (it’s not a “second name” in the strict meaning of this term, because Italy does not have the concept of second name, it’s actually part of my first name). The reason for this is that there are four other “Diego Pettenò” in my city, two of which are around my age, and the Italian system is known for mistaking identities; while it does not really make me entirely safe to just add a second name, it should make it less likely that a mistake would happen. I have chosen Elio because that was the name of my grandfather.

So this was one of the problems; nothing really major, and was solved easily. The next problem happened today when I went for writing some notes about extending the guide (for which I still fail to find a publisher; unless I find one, it’ll keep the open donation approach), and, since the amount of blogging about the subject lately has been massive, I wanted to make sure I used the proper typographical quotation marks . It would have been easy to use them from OS X, but from Linux it seems it’s quite more difficult.

On OS X, I can reach the quotation marks on the keys “1” and “2”, adding the Option and Shift keys accordingly (single and double, open and closed); on Linux, with the US English, Alternate International keyboard I’m using, the thing is quite more difficult. The sequence would be something like Right Control, followed by AltGr and ' (or "), followed by < or >; even if I didn’t have to use AltGr to have the proper keys (without AltGr on the Alternate International keyboard the two symbols are “dead keys”, and are used for composing, quite important since I write both English and Italian with the same keyboard), it’s quite a clumsy way to access the two. And it also wouldn’t work with GNU Emacs on X11.

My first idea would have been to use xmodmap to just change the mappings of “1” and “2” to add third and shifted third levels, just like on OS X. Unfortunately adding extra levels with xmodmap seems to only work with the “mode switch” key rather than with the “ISO Level 3” key; the final result is that I had to “sacrifice” the right Command key (I use an Apple keyboard on Linux) to use as “mode switch” (keeping the right Option as Level 3 shift), and then mapping the ¹⁄₂ keys like I wanted. The result is usable but it also means that all the modifiers on the right side have completely different meaning from what they were designed to, and is not easy to remember all of them.

I thought about using the Keyboard Layout Editor but it requires antlr3 for Python, which is not available in Gentoo and seems to be difficult to update, so for now I’m stuck with this solution; next week when the iMac should arrive I’ll probably spend some more time on the issue (I already spent almost the whole afternoon, more than I should have used), I’d sincerely love to be able to set up the same exact keyboard layout for both systems, so I don’t have to remember in which one I am to get the combinations right; I already publish my custom OSX layout that basically implements the Xorg alternate international layout in OSX (you already have the same layout available in Windows as “US International”, so OSX was the only one lacking that), so I’ll probably just start maintaining layouts for both systems in the future.

And I don’t even want to start talking about setting up proper IME for Japanese under this configuration…

Blogging from the PS3

As an experiment, I’m trying to write a blog entry directly from the browser of the PlayStation3. Unfortunately, I’m not used to this keyboard anymore, it’s also quite noisy compared with the ultra-silent Apple keyboards I’ ve been using for the past months. Additionally, it seems to lose quite a bit of keystrokes, so I suppose this entry will be full of grammatical errors. Sorry for that, it’ s just a test anyway.

Unfotunately, my idea of trying Timeshift’s demo with keyboard and mouse to see whether I’ll be ready to play UT3 and C&C RA3 (when it comes out) on the PS3 was ruined by the fact that the game ignores keyboard and mouse input. The suck!

Ryan, do you have any comment about UT3 with keyboard on the PS3? I don’t think I’ ll be ever able to play FPS with a joypad…

Setting up a dual-seat system

So I was unable to get all the three monitors working on a single X instance. The 4260 size was too much for X to handle properly, so I decided that the best way to handle this is to get two seats working.

Using a multi-seat system seems like a totally nerd thing, but I would think that with modern multicore CPUs a multiseat system might replace well two or more boxes, if configured properly, in offices and school. But I’ll see to dig deeper into that when I have tried using it for a while.

It might be wroth writing down a few comments about the way I ended up with the video card I’m running now: my 3D Blaster Banshee had the display totally corrupt, I’m still not sure if it’s the video card being broken or an incompatibility between it and the ATi AGP card; the Matrox Mystique didn’t arrive to 1280×1024, I was able to get it at 1024×768 but it’s a bit… too tiny for me, there was not enough video ram (2MB); I ended up trying with an S3 ViRGE just because it looked packed with video ram, and seems like I was right, it supports 1280×1024 just fine… if it wasn’t for the refresh rate. I do hope the problem is with the “ugly pattern” we all know from Xorg, I’ll check better later to see if it works fine with dwm, if it doesn’t, I’ll try to see how it works at 256 colours….

It is strange to see how it’s difficult to find modern mainboards with more than one PCI-E x16 slot, and 16GB of RAM. I decided to get a quad-core for my next box with 16GB of RAM, with the current jobs I’m taking it should be possible for me to get it before June, but I’ll still have to deal with PCI video cards, for that reason (as for why 16GB of RAM… should make it less a pain to deal with repeated compilation of C++ code… and I want to use a few virtual machines); as far as I can see there’s no way to get, with Xorg, two seats working on the same videocard.

By the way, if you follow the Wiki, then you’ll probably see it does not work properly: evdev 1.1 does not respect Phys, evdev 1.2 does not open the devices at all, evdev from GIT works better, but you have to specify the event device to use (nasty, but works perfectly fine as you can symlink stuff around with udev).

Talking about udev, the default /dev/input/by-id symlink are completely useless in my system. The reason is quite easy: I have an Apple Aluminium keyboard (I can’t find anything better to write on!), a Logitech LX700 Cordless Desktop, and since yesterday an MX Revolution mouse; each of these peripherals creates two input device in the kernel (don’t ask me why): the first has one device for the basic keys, plus an extra one for extended keys (like fn); the second has a device for the standard keyboard, plus multimedia keys, and one for the mouse, plus all the extra keys as mouse’s buttons; the third has one device for the mouse, plus one for the extra buttons).

As /dev/input/by-id uses the name and the type of the devices, the Apple keyboard overwrites the symlink by itself, as it obviously has the same name, and has two keyboard devices. The Logitech peripherals instead work quite nicely if they are alone, but as both of them have as internal USB name “Logitech Receiver”, and both have one keyboard and one mouse, … I leave to you guess what happens.

See Greg? This is where usb.ids comes out useful ;)

Anyway, later on today I’ll blog more about the dual-seat system, right now I have some documentation to update and some work to do for my job ;)

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.

Kernel downgrade

For a few months now (more like two years) I got forced to upgrade the kernel as soon as it was released to make sure that ALSA worked as it should, yes, another thing I feel obliged to do for my maintainership; I never had, lately, to downgrade to a previous kernel version, even if the new versions had their own problems, but today the time came.

So, I’ve installed gentoo-sources-2.6.20, compiled ALSA, all fine (although I know people reported problems with -rt15 and -ck1 kernels; sorry but they seemed to change the API for the modules, which is.. nasty to say the least); start with the the new version to make sure that HAL recognised the card correctly, and then login to X as usual.

KDE starts with the usual three or four windows I care nothing about but are still there, I run xmodmap to load my special keymap for the extra keys on the keyboard, and press the close button… why Amarok appeared?

A quick xev run shows me that some of my keys are aliased one to the other, XF86Close, XF86Excel and XF86Music shows the same 248 keycode… changing the evdev driver didn’t solve anything, I had to start back in 2.6.19 to get my keyboard back.

I don’t really like this feeling, at all.

Another keyboard problem

Seems like my problems with keyboards never ends. Today I wake up, I have to restart X because I kill scim/skim by mistake, and I end up having to restart X, when I do that, I end up with a messed up keyboard, that does not support alt-intl anymore. I had to fight with it a bit more until I ended up installing xkbdata instead of xkeyboard-config, and now it works fine.

Then I released a new version of unieject, 5.3, that will eject USB flash drives by default. On Gentoo you can also use the pmount useflag to blend in better with pmount; basically it installs it suid and on plugdev group exactly as pmount is, and enable use of pumount for umounting. This makes unieject behave almost perfectly on a desktop system :)

Now, to talk of something that is in the topic on many places now, I’d like to say something about hte various women projects that are out there in the last weeks.

I’m not the kind of person who dislikes women in free software, but I’m not sure how much of this is going to help. Also KDE women project didn’t really change much for what can be seen. The reason is that women aren’t different from anybody else when it’s time to develop. They are not special, I know a few good female developers, and a lot that, despite having taken tech programming school, don’t want to program in their life at all; I don’t think there’s nothing in code that might need a “feminine touch”. But well, I’ll be interested to see what’s going to happen with these projects; hopefully as every project it will bring us some improvement.

But I have to say that this view might be biased by the fact that girls usually flee from me >_>

My personal battle with keyboard and xorg: 7.1 stage

Someone might remember some time ago my battles with a keyboard I bought about one year ago, a Logitech LX700, that has a lot of extra keys that I liked to bind to different meaning for easy access to functions and stuff.

In the first place I had to edit xorg 6.8’s evdev driver to have it working, because almost all the extra keys were sent with high byte values, over 255. I also had to use my own custom xkbdata ebuild as I needed to change the keycodes for almost everything.

With the new Xorg 7.1 I had an hard time as the evdev driver was almost completely rewritten, so I gave it a try “vanilla” (almost vanilla at the end, I had to add a patch to avoid the Xorg server to segfault). The good news is that it seems finally to work (almost entirely, I lost the multimedia keys that are the only keys sent on the second event interface).

Now I actually have one “normal” keyboard and a 99 buttons mouse. This is not that perfect actually, as I can’t bind shortcuts in KDE to buttons, so I have either to hack at KDE to allow that, or I’ll have to find how to configure evdev to get me the keys as keys (and then write a map for this keyboard, hopefully sending it upstream this time).

Right now I tried binding the close button with xbindkeys and xvkbd as suggested by a blog post by Juergen Kreileder (and partially by RockMan of KMobileTools – who instead told me to use xsendkeys but that does not seem to work), but this method does not scale well enough for me, at least I have some problems due to the lag of executing the external command every time. I could probably spend some time creating a mouse button -> keysym wrapper, but at this point after finally getting rid of the hacks I would prefer finding a proper solution, either by changing KDE or by configuring the evdev properly.

Kudos to the Xorg developers, a big “Thank you” for the people maintaining the evdev driver, that is becoming better release after release!

And the keyboard lose the match

Ok this is becoming a rite: everytime I buy a new keyboard, something is just wrong and I need to fix it. This time the problem was the extended keys as I already told in the previous blog entries. Well today I think I have dominated it completely, now it works :D

The solution of this required quite a bit of work, but 34 hours after I bought the keyboard, it was working fine. I have prepared a patch which can be used to make it working, but it’s not complete yet.

If you want to know in deep which problem was it, the solution I found and the way to make it work if you have one, continue the read of this entry.

The problem

X.org uses a 8-bit field to contain the keycode of a given key, this because of the limitation of AT and other protocols. This field is actually used with 7-bit in AT-compatible keyboards (like classic PS2 ones) because of a protocol limitation: the 8th bit (0x80) is used to deal with keyup/keydown event. That is, the sequence of event seen by the keyboard manager is, for example for the ‘V’ key: 0x2F 0xAF; the keyboard manager then &0x7F to have the keycode and &0x80 to recognize the keyup/down.

This limits the number of possible keys on AT protocols to 128 (well actually a bit less as 8 codes are reserved so you have 120 keys). My keyboard, like many of the ones I considered to buy, have more than 128 keys (note that the basic keyboard is usually 105 keys).

The kernel was reporting in atkbd just the “base” keys which was able to be read by scancodes with the 7-bit + 1 field to Xorg with the normal keyboard driver, so I thought of using the new evdev one which uses the input event driver, where I was able to see all the keys of the keyboard

The problem is: as the extra keys have a code > 127, they should go in the range 0x80-0xFF.. but those are codes used by atkbd to see the keyup/keydown, so how Logitech dealt with them?

The solution was probably simple at their eyes, USB supports 16-bit codes, and so the input event driver does, so they just used codes >0xFF.

So I selected the evdev driver in X, and then tried it.. ZoomIn key was seen as ‘V’, becasue its code should have been 0x12F, with V code being 0x2F.

As the first try to enlarge the size of the code field in X resulted in a complete failure, I started thinking for alternative less-invasive solutions.

The solution

The binary code for a base key is: X n n n n n n n, where n is a bit and X is ignored as keyup/keydown bit. The binary code for an extended is n X n n n n n n n. The evdev driver doesn’t need to know about the keyup/keydown bit; actually the codes it receives have that bit stripped off anyway, as the event type deals with keyup/keydown.

At this point the solution was clear, as the resulting code is a 9-bit field with 8 meaningful bits and 1 bit discarded, I just needed to remove that single bit and then have n n n n n n n n as the keycode. Easy said, difficult to do actually.

The problem resided in the fact that there was a “key translation” code in the evdev driver, as the keys seen via evdev are quite different from the ones seen by the atkbd driver so to avoid rewriting all the rules, they just added a code which translates the evdev codes in atkbd compatible codes, but this crimpled a lot fo the extra keys I have, so I managed to remove all that cruft, and then I needed to remap all the base key which used a different code (arrows, ins/del/pgdown/pgup and so on). This took quite a while to find out how to do that as there aren’t docs about this on X.org site as far as I could see, so it required many hours to me to hack that.

Then I configured the extra keys with codes/keysysm pairs for a new “logilx700” model, so to have the key available in KDE.

Unfortunately, it wasn’t all clear.

The problems still present

There are still a couple of issues I wasn’t able to smash this night but I hope to do soon;

the WIN key doesn’t react as it should and is ignored by KDE (note: I found the problem while I was here so this should be fixed in the patch I linked before but I haven’t tried it right now);
the ZoomIn/ZoomOut keys aren’t well-read by the system, and I’m not able to use them on KDE for now;
the mouse’s buttons are seen like buttons as they are and they aren’t remappable on KDE.. this is something which needs to be changed in kdelibs.. I’ll try;
this is the major problem: some keys are “ghosts” of other, for example if I press the “windows list” key it acts like a Stop key. I’m not sure what’s the deal with them but I’ll try to find out soon, they are just a few, the main ones works fine as they should.

Anyway the keyboard itself works well and is quite comfortable to use, a good choice :)

As soon as I’ve cleared out the above problems I’ll submit the patch to Xorg to see if it’s good enough.