Hi Robert,
On Fr 14 Nov 2014 01:39:31 CET, Robert Siemer wrote:
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.
I guess this is the best analysis on what happens in NX around
keyboard stuff, I have ever read. Thanks for that very good tutorial.
Now about fixing the bug.
I really think we should get evdev support into NX. What do you think?
But for now... so that I get a deeper feeling for this... Could you
provide a recipe for setting the correct / transparent keyboard setup
in the X2Go Session?
A sequence of commands on the client-side, a sequence of commands on
the server-side, something like that...
THANKS! Mike
--
DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148
GnuPG Key ID 0x25771B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xf...