Content-Type: text/shitpost

About a month ago I posted a long lament about the difficulty of figuring out what was going on with my bluetooth keyboard. I had made some additional progress on it by the following day, but I'm just getting around now to writing it up.

1. Norman Yarvin wrote to suggest that I look at the ArchLinux wiki page about keyboard configuration. This was extremely helpful. I had mentioned “the wild and uncharted jungles of the Linux keyboard system… I wish I could draw you a map here, but I don't have one.” The ArchLinux page is not a map, but it is helpful advice from an experienced guide. In particular, there are a lot of examples.

2. One cause of my problems is that I was trying to set the ralt option. But this is misspelled: it’s not ralt, it’s compose:ralt, because it’s declared in the ralt section of the compose file. (That's /usr/share/X11/xkb/symbols/compose.) I didn't realize I had this wrong, because setxkbmap is happy to set that option anyway, even though it means nothing.

   In the previous article, I even asked about this:

   If the problem is that it doesn't know what ralt means any more, why doesn't it just say so? Was I supposed to write it as compose:ralt? Maybe?

   If setxkbmap had issued some kind of warning when I misspelled compose:ralt as ralt, instead of silently doing something useless that ultimately had no effect, I would have avoided around half of my problems in this area.

3. This leads us into my complaint that setxkbmap -query and setxkbmap -print both seem to do the same thing, the manual does not explain the difference, but they produce inconsistent output. I said:

   one form will say that the keyboard options include some things, and the other form will say that they don't.

   The manual describes them:

     -print              Print a complete xkb_keymap description and exit
     -query              Print the current layout settings and exit
   

   The -query option just spits back the options you set. The -print option tries to resolve those options using the files under /usr/share/X11/xkb and to use those files to translate the options into a format acceptable to the xkbcomp command.

   If some of your options are unresolvable (and therefore meaningless) the -print option will silently discard them. I had set the meaningless ralt option, so it was omitted from the output of -print but not from the output of -query.

4. I wept openly as I wrote:

   While writing up this section, the mappings on the bluetooth keyboard went away. …

   …

   I was going to say more about this, but somewhere in the previous paragraph the bluetooth keyboard started working properly again.   Fuck if I know.

   I did some more digging on this and I think I found the answer: it was just a hardware hiccup. The Bluetooth connection was briefly dropped, and when it reconnected the keyboard configuration was reinitialized. Since my configuration file contained the wrong things, the configuration was reinitialized incorrectly.

   Why did it switch back though? No idea.

5. I issued a threat about what I would do “if you send me mail that tells me I was stupid because everyone knows…”. Nobody dared do this.

   But Daniel Wagner sent me a link to a slide presentation by Daniel Stone, one of the principal authors of the Wayland display server. Of particular interest is the sentiment on slides 70 and 71:

   three people on this earth understand X input

   really wish I wasn't one of them

   The rest of the presentation was very interesting. I said to M. Wagner:

   I have been wondering for years if X's vaunted network transparency was as big a failure as it seemed: an interesting idea, worth trying out, but one that eventually turned out to be more trouble than it was worth. Of course, you can run the client on a different machine than on the server, but hardly anyone ever does, because the performance is bad. But I wasn't sure if maybe there were super-important applications of remote X clients that I wasn't aware of.

   But this person's view seems to be that I was correct, it was a mistake.

   Stone's presentation confirmed this idea, and some other ones I had had about X as a failed design.

6. I asked:

   Is there a way to address the two keyboards separately? I don't know.

   I think the answer here is, get the ID number for the keyboard you want from the xinput command, and then use that with the -device option of setxkbmap. The setxkbmap man page does not mention xinput, by the way. You Just Have To Know.

7. At one point I got everything into the right state and asked “was it just a fluke?” Yeah, pretty much. I had added the meaningless ‘ralt’ option and sent a udev trigger to reinitialize the keyboard. But in addition to reinitializing itself with ralt it also reinitialized itself from wherever else it was supposed to. (I think.)

8. I ended with the following questions:

   1. Can I find out what device file to use in the [udev trigger] command, without needing a human being eyeball the log file? I don't know.

      I still don't know this, but it seems less important now that I don't need to use udev any more.

   2. Will my change to /etc/default/keyboard persist past my next login? I don't know.

      Xorg has a habit of overwriting my changes to its configuration on server startup, but this change persisted.

   3. Why did it fix the control-key mapping as well as the compose key, when all I said to do was to add the ralt option? I don't know.

      Probably it was some unrelated reinitialization, and ralt itself was a red herring.

9. The correct solution was to add compose:ralt (the correct name of the option) to the XKBOPTIONS= line in /etc/keyboard/default, which now looks like this:

       XKBMODEL="pc105"
       XKBLAYOUT="us"
       XKBVARIANT=""
       XKBOPTIONS="compose:ralt,ctrl:nocaps"
       BACKSPACE="guess"
   

   I think at some point I had ralt in there instead of compose:ralt, and setxkbmap was happily and silently throwing it away.

The Bluetooth keyboard's up-cursor key has Home printed on it in blue, suggesting that Fn+Up will send a “Home” message, but it seems not to do that. I'm trying to fix it, because I am a glutton for punishment.

I have made some progress. I have gotten Fn+Up to come through to Emacs as Super-A, which may not sound like much but is actually a step in the right direction. It means I have correctly configured the Fn key as a third-level shift (which Emacs calls “Super”) and then the up-cursor is probably sending ESC [ A or something like that.

With the help of the ArchLinux Wiki page, I will get it figured out sooner or later. Or I might decide that it would be more fulfilling to run amuck with an ax. We'll see.

Thanks to Norman Yarvin, Daniel Wagner, and especially to the authors of the ArchLinux Wiki page.