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:
>
> 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 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.xfb