Bug#674: keycode -> keycode translation harmful (makes configuration complex)
Robert Siemer <Robert.Siemer <at> backsla.sh>
2014-11-14 00:39:31 GMT
This bug report is about keyboard configuration issues: it is very
challenging to have a custom keyboard configuration over x2go, while it
is running perfectly on the local machine.
With a Linux X2Go client the keyboard configuration could be entirely
transparent, like an ssh-session with X11-forwarding is. But it isn’t.
Background: In X11, the keycodes (numbers, e.g. 98) are sent by the
X11-keyboard driver to the X11-core. These numbers also get reported to
the applications. The applications in turn ask the X-server what they
should make out of those keycodes (e.g. 'a', called “symbols”).
The "final" problem I’m describing here is independent of the ‘keyboard
settings’ of the x2go client. Nevertheless I describe here only the
effects as seen with a configuration of "leave keyboard settings alone
and don’t do anything about it”.
With this kind of configuration the X-clients on the X2Go-server get the
same answer to for keycodes → symbols requests as they get local, but
they get it from the X2Go-server (nxagent or something). It seems that
these settings get copied over to the X2Go-server and are left alone. I
call those settings the “XKB configuration”.
A different X2Go-client keyboard configuration (e.g. auto), by the way,
would only reconfigure that XKB configuration, which can also be done by
hand with xkbcomp or setxkbmap.
—But the keycodes coming from the X2Go-client do not get sent over as
is. The are “mangled” or “translated” in between, especially on any
Linux client with evdev input device drivers.
There is no X11 way to reconfigure those keycodes, as they normally come
from the driver and are fixed for each key.
Three questions came to my mind:
1) Why are the keycodes translated?
2) What logic does this translation follow?
3) How can I influence it?
To the first question: it might be an artifact which is needed for other
Second question: It turned out that the keycodes received by the
applications on the X2Go-server are exactly those that an old pre-evdev
Linux machine would generate. Those codes are written down and shipped
with Xorg (X-Server) in the file keycodes/xfree86. The file used these
days with the evdev driver is keycodes/evdev, where those known values
After changing my XKB configuration, completely “faking” a key on my
keyboard to be something else, the X2Go server (or nxagent or whatever)
still knew how to translate the keycode of it.
After some trial and error I found out that the translation instance
knowns about my original keyboard with the help of the some X property
on the root window:
$ xprop -root _XKB_RULES_NAMES
_XKB_RULES_NAMES(STRING) = "evdev", "pc104", "us", "altgr-intl", ""
The first string, here "evdev" dicts the rules file to use for XKB
configuration changes. Note: this X property is not part of the XKB
configuration, but setxkbmap read and records those five strings, which
guide XKB configuration composition so to say. (Those five strings are
rules, model, layout, variant and options, and they only guide which XKB
configuration pieces to load. Those pieces are named keycodes, types,
compat, symbols and geometry.)
I don’t know if X2Go actually reads and parses the rules file and the
XKB snippets or if the mappings are hardcoded, but changing the first
string in _XKB_RULES_NAMES (which dictates which rules file to use)
influences how the translation is done.
the following rules files dictate which keycodes to use:
evdev → evdev
xfree86 → xfree86
base → xfree86
When starting or resuming an X2Go session, the _XKB_RULES_NAMES property
is initially set to "xfree86", "null", "null", ... in the nxagent. It
really looks like that this X11 intermediary wants to fake “xfree86
hardware” (i.e. old PC hardware + kernel). As my current setup has no
“xfree86 settings” nowhere, I assume that this is fixed.
In effect: changing _XKB_RULES_NAMES to something where the rules is set
to “xfree86” or “base”, no translation takes place (or the translation
is 1:1). This has to be configured before X2Go session resume or
startup. Note that this does not change the XKB configuration (it would
only influence the next setxkbmap run).
Once no real keycode translation takes place, no XKB keyboard
(re-)configuration is necessary as the copied local setup is probably
exactly what you want.
x2go-dev mailing list
x2go-dev <at> lists.x2go.org