From unknown Tue Apr 28 14:02:34 2026
X-Loop: owner@bugs.x2go.org
Subject: Bug#674: [X2Go-Dev] Bug#674: keycode -> keycode translation harmful (makes configuration complex)
Reply-To: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>, 674@bugs.x2go.org
Resent-From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
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 04:50:02 +0000
Resent-Message-ID: <handler.674.B674.141594059914861@bugs.x2go.org>
Resent-Sender: owner@bugs.x2go.org
X-X2Go-PR-Message: followup 674
X-X2Go-PR-Package: x2goserver
X-X2Go-PR-Keywords: 
Received: via spool by 674-submit@bugs.x2go.org id=B674.141594059914861
          (code B ref 674); Fri, 14 Nov 2014 04:50:02 +0000
Received: (at 674) by bugs.x2go.org; 14 Nov 2014 04:49:59 +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=-1.9 required=5.0 tests=BAYES_00,URIBL_BLOCKED
	autolearn=ham version=3.3.2
Received: from freya.das-netzwerkteam.de (freya.das-netzwerkteam.de [88.198.48.199])
	by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id 634105DB42
	for <674@bugs.x2go.org>; Fri, 14 Nov 2014 05:49:57 +0100 (CET)
Received: from grimnir.das-netzwerkteam.de (grimnir.das-netzwerkteam.de [78.46.204.98])
	by freya.das-netzwerkteam.de (Postfix) with ESMTPS id E25B33A01;
	Fri, 14 Nov 2014 05:49:56 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
	by grimnir.das-netzwerkteam.de (Postfix) with ESMTP id A1E353C733;
	Fri, 14 Nov 2014 05:49:56 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at grimnir.das-netzwerkteam.de
Received: from grimnir.das-netzwerkteam.de ([127.0.0.1])
	by localhost (grimnir.das-netzwerkteam.de [127.0.0.1]) (amavisd-new, port 10024)
	with ESMTP id CKqANlJ7PCt7; Fri, 14 Nov 2014 05:49:56 +0100 (CET)
Received: from grimnir.das-netzwerkteam.de (localhost [127.0.0.1])
	by grimnir.das-netzwerkteam.de (Postfix) with ESMTPS id 50D343C730;
	Fri, 14 Nov 2014 05:49:56 +0100 (CET)
Received: from p5B284965.dip0.t-ipconnect.de (p5B284965.dip0.t-ipconnect.de
 [91.40.73.101]) by mail.das-netzwerkteam.de (Horde Framework) with HTTP;
 Fri, 14 Nov 2014 04:49:56 +0000
Date: Fri, 14 Nov 2014 04:49:56 +0000
Message-ID: <20141114044956.Horde.hIYkTC6p9toL-RPK9auXKg2@mail.das-netzwerkteam.de>
From: Mike Gabriel <mike.gabriel@das-netzwerkteam.de>
To: Robert Siemer <Robert.Siemer@backsla.sh>, 674@bugs.x2go.org
In-Reply-To: <54654F43.1020306@backsla.sh>
User-Agent: Internet Messaging Program (IMP) H5 (6.2.2)
Accept-Language: en,de
Organization: DAS-NETZWERKTEAM
X-Originating-IP: 91.40.73.101
X-Remote-Browser: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101
 Firefox/32.0 Iceweasel/32.0
Content-Type: multipart/signed; boundary="=_R5dCHH9be0_PM4xEBmqeXw1";
 protocol="application/pgp-signature"; micalg=pgp-sha1
MIME-Version: 1.0

This message is in MIME format and has been PGP signed.

--=_R5dCHH9be0_PM4xEBmqeXw1
Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=20=20
>=20challenging to have a custom keyboard configuration over x2go, while=20=
=20
>=20it is running perfectly on the local machine.
>
> With a Linux X2Go client the keyboard configuration could be=20=20
>=20entirely transparent, like an ssh-session with X11-forwarding is.=20=20
>=20But it isn=E2=80=99t.
>
> Background: In X11, the keycodes (numbers, e.g. 98) are sent by the=20=20
>=20X11-keyboard driver to the X11-core. These numbers also get reported=20=
=20
>=20to the applications. The applications in turn ask the X-server what=20=
=20
>=20they should make out of those keycodes (e.g. 'a', called =E2=80=9Csymbo=
ls=E2=80=9D).
>
> The "final" problem I=E2=80=99m describing here is independent of the=20=
=20
>=20=E2=80=98keyboard settings=E2=80=99 of the x2go client. Nevertheless I =
describe here=20=20
>=20only the effects as seen with a configuration of "leave keyboard=20=20
>=20settings alone and don=E2=80=99t do anything about it=E2=80=9D.
>
> With this kind of configuration the X-clients on the X2Go-server get=20=
=20
>=20the same answer to for keycodes =E2=86=92 symbols requests as they get=
=20=20
>=20local, but they get it from the X2Go-server (nxagent or something).=20=
=20
>=20It seems that these settings get copied over to the X2Go-server and=20=
=20
>=20are left alone. I call those settings the =E2=80=9CXKB configuration=E2=
=80=9D.
>
> A different X2Go-client keyboard configuration (e.g. auto), by the=20=20
>=20way, would only reconfigure that XKB configuration, which can also=20=
=20
>=20be done by hand with xkbcomp or setxkbmap.
>
> =E2=80=94But the keycodes coming from the X2Go-client do not get sent ove=
r=20=20
>=20as is. The are =E2=80=9Cmangled=E2=80=9D or =E2=80=9Ctranslated=E2=80=
=9D in between, especially on=20=20
>=20any Linux client with evdev input device drivers.
>
> There is no X11 way to reconfigure those keycodes, as they normally=20=20
>=20come 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=20=20
>=20other platforms.
>
> Second question: It turned out that the keycodes received by the=20=20
>=20applications on the X2Go-server are exactly those that an old=20=20
>=20pre-evdev Linux machine would generate. Those codes are written down=20=
=20
>=20and shipped with Xorg (X-Server) in the file keycodes/xfree86. The=20=
=20
>=20file used these days with the evdev driver is keycodes/evdev, where=20=
=20
>=20those known values are recorded.
>
> After changing my XKB configuration, completely =E2=80=9Cfaking=E2=80=9D =
a key on my=20=20
>=20keyboard to be something else, the X2Go server (or nxagent or=20=20
>=20whatever) still knew how to translate the keycode of it.
>
> After some trial and error I found out that the translation instance=20=
=20
>=20knowns about my original keyboard with the help of the some X=20=20
>=20property on the root window:
>
> $ xprop -root _XKB_RULES_NAMES
> _XKB_RULES_NAMES(STRING) =3D "evdev", "pc104", "us", "altgr-intl", ""
>
> The first string, here "evdev" dicts the rules file to use for XKB=20=20
>=20configuration changes. Note: this X property is not part of the XKB=20=
=20
>=20configuration, but setxkbmap read and records those five strings,=20=20
>=20which guide XKB configuration composition so to say. (Those five=20=20
>=20strings are rules, model, layout, variant and options, and they only=20=
=20
>=20guide which XKB configuration pieces to load. Those pieces are named=20=
=20
>=20keycodes, types, compat, symbols and geometry.)
>
> I don=E2=80=99t know if X2Go actually reads and parses the rules file and=
=20=20
>=20the XKB snippets or if the mappings are hardcoded, but changing the=20=
=20
>=20first string in _XKB_RULES_NAMES (which dictates which rules file to=20=
=20
>=20use) influences how the translation is done.
>
> the following rules files dictate which keycodes to use:
>
> evdev =E2=86=92 evdev
> xfree86 =E2=86=92 xfree86
> base =E2=86=92 xfree86
>
> When starting or resuming an X2Go session, the _XKB_RULES_NAMES=20=20
>=20property is initially set to "xfree86", "null", "null", ... in the=20=
=20
>=20nxagent. It really looks like that this X11 intermediary wants to=20=20
>=20fake =E2=80=9Cxfree86 hardware=E2=80=9D (i.e. old PC hardware + kernel)=
. As my=20=20
>=20current setup has no =E2=80=9Cxfree86 settings=E2=80=9D nowhere, I assu=
me that this=20=20
>=20is fixed.
>
> In effect: changing _XKB_RULES_NAMES to something where the rules is=20=
=20
>=20set to =E2=80=9Cxfree86=E2=80=9D or =E2=80=9Cbase=E2=80=9D, no translat=
ion takes place (or the=20=20
>=20translation is 1:1). This has to be configured before X2Go session=20=
=20
>=20resume or startup. Note that this does not change the XKB=20=20
>=20configuration (it would only influence the next setxkbmap run).
>
> Once no real keycode translation takes place, no XKB keyboard=20=20
>=20(re-)configuration is necessary as the copied local setup is=20=20
>=20probably exactly what you want.

I guess this is the best analysis on what happens in NX around=20=20
keyboard=20stuff, 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=20=20
provide=20a recipe for setting the correct / transparent keyboard setup=20=
=20
in=20the X2Go Session?

A sequence of commands on the client-side, a sequence of commands on=20=20
the=20server-side, something like that...

THANKS!
Mike


--=20

DAS-NETZWERKTEAM
mike=20gabriel, 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.x=
fb

--=_R5dCHH9be0_PM4xEBmqeXw1
Content-Type: application/pgp-signature
Content-Description: Digitale PGP-Signatur
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAABAgAGBQJUZYn0AAoJEJr0azAldxsxbE0P/31d9ipVzrvh7ZElI4FN2k/H
s1cZFd4FiiT4hRKk8KLPlFsN2tMg/RNzWZ1LxzuXmFAsc52CcmdIOPWLqGFfe0uX
3Zm1aVCnzn+tFpypdYK3BfY+oYP8LtC2UTrRM02MihXCWNgJ2B1UFa/2rkUnDpzp
2+B5FKFEdno+OSkOnM3dmK972rMUWsW0GvT/76gfwMyCSJh7k0PJ6yBjnZB9PU57
oPvB/+DbaltpcAmeF/rHlVO34bQ5lbw0hszBNlotwzcEs2ddNLBU0TsoftuWXCFU
Z6Qs0XWFuIMx4d6L+IYWJJeeFfBNyeMa2nE6Omit6W+FQa1BIcpaMgvFXpLSqQc+
/Omz/ONfFv8nA2uSiUK9Ote8xvXL98BjpaJMmCULycZEvvx/7GYHGSXWj4LYjY6u
8uxaT3Xhyu00i/1I+1laEOzcvbl0ZcvL+bJUYLFiZxKKp6A5vb+L/n8tlHW8NsVq
tFqiYbCbTr3bXHDFi8h8Fj9O//0c3BAibJqEobece/x5zOolvm3/jW645jJkA0vH
NbeIt/S4q4iaDeb0OhHFWbaC/pw904OKwK7hIFqU1ftdTp+Uh5ipenSUoqJC6hHb
EIVhHJPg/7mZTItuhNN6q6xDZFpYTnen9TtkiFOXt6psQzXbOpp9DWcQYHibt6AD
CrVS4fVNiY2Bs3XVLNGi
=WlVz
-----END PGP SIGNATURE-----

--=_R5dCHH9be0_PM4xEBmqeXw1--
