setxkbmap and include path
There are so many problems with setxkbmap that it is difficult to know where to start; but let us start with the -I
option:
setxkbmap -I $HOME/.xkb -option '' -config clerew.conf clerew -print
where clerew.conf contains
Model = "sun-type6-unix-usb"
Layout = "gb"
Symbols = "pc+gb+inet(evdev)+clerew"
Geometry = "sun(type6unix)"
So I keep my local tweak in ~/.xkb/symbols/clerew and my .conf file is also in ~/.xkb (which seems to be the fashionable place for such things).
So I expect it to look in ~/.xkb for what it wants, and if that fails it should revert to /usr/share/X11/xkb. And so it does.
BUT (and this is seen in the source code, which I downloaded), one would expect it to fail if some file could not be found in either place - but NO. It will complain if a Rules file cannot be located and if the .conf file cannot be located, but give it a non-existent keycodes, types, compat, layout, symbols or geometry file (e.g. "+foobar" in my .conf file) and it does not bat an eyelid. Surely that is a BUG if ever there was one. Not even a Warning is given.
Anyhow, if you run my example it prints
xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "clerew" };
xkb_geometry { include "sun(type6unix)" };
};
which is a valid .xkb file, so you store it in someplace whence it can be compiled directly to your Display with
xkbcomp -I$HOME/.xkb someplace :0
and there it is; your new layout is there for the remainder of this login (observe that xkbcomp is fussy about not having a space after -I
, so let's call that BUG2).
So now let's try and do it all with setxkbmap:
setxkbmap -v 10 -I $HOME/.xkb -option '' -config clerew3.conf
Setting verbose level to 10
locale is C
Didn't find file ./clerew3.conf
Didn't find file /usr/share/X11/xkb/clerew3.conf
Found file /home/chl/.xkb/clerew3.conf
After config file:
rules: evdev
model: sun-type6-unix-usb
layout: gb
symbols: pc+gb+inet(evdev)+clerew
geometry: sun(type6unix)
Trying to load rules file ./rules/evdev...
Trying to load rules file /usr/share/X11/xkb/rules/evdev...
Success.
Warning! Multiple definitions of symbols
Using config file, ignoring rules file
Warning! Multiple definitions of geometry
Using config file, ignoring rules file
Applied rules from evdev:
rules: evdev
model: sun-type6-unix-usb
layout: gb
Trying to build keymap using the following components:
keycodes: evdev+aliases(qwerty)
types: complete
compat: complete
symbols: pc+gb+inet(evdev)+clerew
geometry: sun(type6unix)
Error loading new keyboard description
I used maximum verbosity, so you can see what it was trying to do. Observe that it also looks in the current directory for wanted files; it decided for itself that it needed the rules file evdev (my original .conf file had carefully omitted any mention of any rules file, preferring to specify exactly what symbols files were needed); and it gave the well known unhelpful error message which people have been complaining about for many years.
However, I know exactly what had gone wrong; it had totally failed to pass on the -I $HOME/.xkb
to xkbcomp, or wherever the further action takes place, so that is BUG3.
But I have the source code, so I can see that what it does with all the (perfectly correct) recipe provided is to call
xkb = XkbGetKeyboardByName(dpy, deviceSpec, &cmdNames,
XkbGBN_AllComponentsMask,
XkbGBN_AllComponentsMask &
(~XkbGBN_GeometryMask), True);
And that call makes no provision for handing over any include path. Moreover the function XkbGetKeyboardByName is TOTALLY UNDOCUMENTED in any place that Google can find, and that lack of documentation constitutes BUG4.
Hovever, using strace one can see that it opens up a stream to the X-server, and one can only assume that there is a call of xkbcomp in there. And one can see that all the correct information is passed over the stream (without the include path of course), and that the unhelpful error message comes back via that same stream.
Now BUG5 may be off-topic for this list, but I will mention it anyway. After all that work, and even if you hack your way past the lack of an include path, all you have achieved is a temporary change to your keyboard configuation, which will disappear as soon as you log out. Even a call of setxkbmap -query
will not show the changes you have made. The question of how to make your changer Permanent has been asked many times, and I have seen many answers, but I don't believe any of them (especially the ones marked 'SOLVED').
So BUG5 may be an issue for GNOME, or Qt, or wherever else, but I would welcome some pointers to it here. All I have been able to find starts out from the assumption that you have a correct and working Rules file, to which you can specify options, Variants and Layouts. Maybe it is done through /etc/default/keyboard or maybe is is done through dconf, but the whole point of my tweak is that it changes the mapping of couple of keys in a way that was not foreseen by any Rules File, and hence it cannot be submitted as a permanent feature by any means I can discern; the Gods have spoken as to what mere mortals are permitted to do, and anyone who wishes otherwise is a Heretic.