X2Go Bug report logs -
#674
keycode -> keycode translation harmful (makes configuration complex)
Full log
Message #10 received at 674@bugs.x2go.org (full text, mbox, reply):
[Message part 1 (text/plain, inline)]
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
[Message part 2 (application/pgp-signature, inline)]
Send a report that this bug log contains spam.
X2Go Developers <owner@bugs.x2go.org>.
Last modified:
Thu Apr 18 01:50:15 2024;
Machine Name:
ymir.das-netzwerkteam.de
X2Go Bug tracking system
Debbugs is free software and licensed under the terms of the GNU
Public License version 2. The current version can be obtained
from https://bugs.debian.org/debbugs-source/.
Copyright © 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson,
2005-2017 Don Armstrong, and many other contributors.