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.
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...
Am 14.11.2014 um 05:49 schrieb Mike Gabriel:
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.
That's what I was thinking when I read it, too ;-) But I'll have to read it again to fully get into it.
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...
Man setxkbmap states this:
If you have an Xserver and a client shell running on different computers and XKB configuration files on those machines are different you can get problems specifying a keyboard map by model, layout, options names. This is because setxkbcomp converts these names to names of XKB configuration files according to files that are on the client side computer, then it sends the file names to the server where the xkbcomp has to compose a complete keyboard map using files which the server has. Thus if the sets of files differ significantly the names that the setxkbmap generates can be unacceptable on the server side. You can solve this problem by running the xkbcomp on the client side too. With the -print option setxkbmap just prints the file names in an appropriate format to its stdout and this output can be piped directly to the xkbcomp input. For example, the command
setxkbmap us -print | xkbcomp - $DISPLAY
makes both steps run on the same (client) machine and loads a keyboard map into the server.
Wouldn't this bypass all this setxkbmap names and files altogether?
Uli
-
Mike Gabriel -
Robert Siemer -
Ulrich Sibiller