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.
Norman Yarvin wrote to suggest that I look at the ArchLinux wiki
page about keyboard
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.
One cause of my problems is that I was trying to set the
option. But this is misspelled: it’s not
compose:ralt, because it’s declared in the
ralt section of
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
any more, why doesn't it just say so? Was I supposed to write it as
setxkbmap had issued some kind of warning when I misspelled
ralt, instead of silently doing something
useless that ultimately had no effect, I would have avoided around
half of my problems in this area.
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
-query option just spits back the options you set. The
-print option tries to resolve those options using the files
/usr/share/X11/xkb and to use those files to translate the
options into a format acceptable to the
If some of your options are unresolvable (and therefore
-print option will silently discard them. I
had set the meaningless
ralt option, so it was omitted from the
-print but not from the output of
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.
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
But Daniel Wagner sent me a link to a slide presentation by
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
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
But this person's view seems to be that I was correct, it was a
Stone's presentation confirmed this idea, and some other ones I
had had about X as a failed design.
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 man page does
xinput, by the way. You Just Have To Know.
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
also reinitialized itself from wherever else it was supposed to.
I ended with the following questions:
Can I find out what device file to use in the [
command, without needing a human being eyeball the log file? I
I still don't know this, but it seems less important now that I
don't need to use
udev any more.
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.
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
itself was a red herring.
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:
I think at some point I had
ralt in there instead of
setxkbmap was happily and silently throwing
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
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.