From mike.gabriel@das-netzwerkteam.de Fri Nov 14 05:49:57 2014 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 To: Robert Siemer , 674@bugs.x2go.org Subject: Re: [X2Go-Dev] Bug#674: keycode -> keycode translation harmful (makes configuration complex) 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--