X2Go Bug report logs - #674
keycode -> keycode translation harmful (makes configuration complex)

Full log

🔗 View this message in rfc822 format

X-Loop: owner@bugs.x2go.org
Subject: Bug#674: keycode -> keycode translation harmful (makes configuration complex)
Reply-To: Robert Siemer <Robert.Siemer@backsla.sh>, 674@bugs.x2go.org
Resent-From: Robert Siemer <Robert.Siemer@backsla.sh>
Resent-To: x2go-dev@lists.x2go.org
Resent-CC: X2Go Developers <x2go-dev@lists.x2go.org>
X-Loop: owner@bugs.x2go.org
Resent-Date: Fri, 14 Nov 2014 00:50:02 +0000
Resent-Message-ID: <handler.674.B.141592592311413@bugs.x2go.org>
Resent-Sender: owner@bugs.x2go.org
X-X2Go-PR-Message: report 674
X-X2Go-PR-Package: x2goserver
X-X2Go-PR-Keywords: 
Received: via spool by submit@bugs.x2go.org id=B.141592592311413
          (code B); Fri, 14 Nov 2014 00:50:02 +0000
Received: (at submit) by bugs.x2go.org; 14 Nov 2014 00:45:23 +0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on
	ymir.das-netzwerkteam.de
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50 autolearn=ham
	version=3.3.2
X-Greylist: delayed 347 seconds by postgrey-1.34 at ymir.das-netzwerkteam.de; Fri, 14 Nov 2014 01:45:21 CET
Received: from miranda.backsla.sh (woi4u.backsla.sh [213.239.218.239])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTP id 7EC785DB41
	for <submit@bugs.x2go.org>; Fri, 14 Nov 2014 01:45:21 +0100 (CET)
Received: from [192.168.2.107] (dslb-088-074-175-125.088.074.pools.vodafone-ip.de [88.74.175.125])
	by miranda.backsla.sh (Postfix) with ESMTPSA id 8A181D300BD
	for <submit@bugs.x2go.org>; Fri, 14 Nov 2014 02:09:44 +0100 (CET)
Message-ID: <54654F43.1020306@backsla.sh>
Date: Fri, 14 Nov 2014 01:39:31 +0100
From: Robert Siemer <Robert.Siemer@backsla.sh>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: submit@bugs.x2go.org
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

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.

Send a report that this bug log contains spam.