Package: x2goserver Version: 4.0.1.18
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:
Why are the keycodes translated?
What logic does this translation follow?
How can I influence it?
To the first question: it might be an artifact which is needed for other platforms.
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 are recorded.
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.