From Robert.Siemer@backsla.sh Fri Nov 14 01:45:21 2014 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 ; 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 ; 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 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 Subject: keycode -> keycode translation harmful (makes configuration complex) 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. 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-- From mike.gabriel@das-netzwerkteam.de Fri Nov 14 23:50:15 2014 Received: (at 674) by bugs.x2go.org; 14 Nov 2014 22:50:17 +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 28CD85DB41 for <674@bugs.x2go.org>; Fri, 14 Nov 2014 23:50:15 +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 A65453B9C for <674@bugs.x2go.org>; Fri, 14 Nov 2014 23:50:14 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by grimnir.das-netzwerkteam.de (Postfix) with ESMTP id 740633B9BB for <674@bugs.x2go.org>; Fri, 14 Nov 2014 23:50:14 +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 js8ZoLEb3m8T for <674@bugs.x2go.org>; Fri, 14 Nov 2014 23:50:14 +0100 (CET) Received: from grimnir.das-netzwerkteam.de (localhost [127.0.0.1]) by grimnir.das-netzwerkteam.de (Postfix) with ESMTPS id 3F2793B9AF for <674@bugs.x2go.org>; Fri, 14 Nov 2014 23:50:14 +0100 (CET) Resent-Date: Fri, 14 Nov 2014 22:50:13 +0000 Resent-From: Mike Gabriel Resent-To: 674@bugs.x2go.org Resent-Message-ID: <20141114225013.Horde.1Hm1ODxEydW2SMRmQFWOZA1@mail.das-netzwerkteam.de> Received: from localhost (localhost [127.0.0.1]) by grimnir.das-netzwerkteam.de (Cyrus v2.2.13-Debian-2.2.13-9.1) with LMTPA; Fri, 14 Nov 2014 13:46:39 +0100 X-Sieve: CMU Sieve 2.2 Received: from localhost (localhost [127.0.0.1]) by grimnir.das-netzwerkteam.de (Postfix) with ESMTP id 4A5E33C0C6 for ; Fri, 14 Nov 2014 13:46:39 +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 z8ZPHknoqcRR for ; Fri, 14 Nov 2014 13:46:39 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by grimnir.das-netzwerkteam.de (Postfix) with ESMTP id EFB9E3C4DD for ; Fri, 14 Nov 2014 13:46:35 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by grimnir.das-netzwerkteam.de (Postfix) with ESMTP id A51243BBC5 for ; Fri, 14 Nov 2014 13:46:35 +0100 (CET) Received: from ymir.das-netzwerkteam.de (ymir.das-netzwerkteam.de [178.63.100.243]) by grimnir.das-netzwerkteam.de (Postfix) with ESMTP id 58F7A3BB47; Fri, 14 Nov 2014 13:46:28 +0100 (CET) Received: from ymir.das-netzwerkteam.de (localhost [127.0.0.1]) by ymir.das-netzwerkteam.de (Postfix) with ESMTP id 2E5EE5DB41; Fri, 14 Nov 2014 13:46:28 +0100 (CET) X-Original-To: x2go-dev@lists.x2go.org Delivered-To: x2go-dev@ymir.das-netzwerkteam.de X-Greylist: delayed 572 seconds by postgrey-1.34 at ymir.das-netzwerkteam.de; Fri, 14 Nov 2014 13:46:25 CET Received: from mx4.science-computing.de (mx4.science-computing.de [193.197.16.30]) by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id EE4F25DB41 for ; Fri, 14 Nov 2014 13:46:25 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by scmail.science-computing.de (Postfix) with ESMTP id 374E8533A for ; Fri, 14 Nov 2014 13:36:53 +0100 (CET) X-Virus-Scanned: amavisd-new Received: from scmail.science-computing.de ([127.0.0.1]) by localhost (guiness.science-computing.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yjQ_TzK2-R23 for ; Fri, 14 Nov 2014 13:36:52 +0100 (CET) Received: from [10.10.16.123] (pius.science-computing.de [10.10.16.123]) by scmail.science-computing.de (Postfix) with ESMTP id B8796735 for ; Fri, 14 Nov 2014 13:36:52 +0100 (CET) Message-ID: <5465F764.2010805@gmx.de> Date: Fri, 14 Nov 2014 13:36:52 +0100 From: Ulrich Sibiller User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: x2go-dev@lists.x2go.org References: <20141114044956.Horde.hIYkTC6p9toL-RPK9auXKg2@mail.das-netzwerkteam.de> In-Reply-To: <20141114044956.Horde.hIYkTC6p9toL-RPK9auXKg2@mail.das-netzwerkteam.de> Subject: Re: [X2Go-Dev] Bug#674: Bug#674: keycode -> keycode translation harmful (makes configuration complex) X-BeenThere: x2go-dev@lists.x2go.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: X2Go Development Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: x2go-dev-bounces@lists.x2go.org Sender: x2go-dev-bounces@lists.x2go.org X-Kolab-Scheduling-Message: FALSE Am 14.11.2014 um 05:49 schrieb Mike Gabriel: > 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. That's what I was thinking when I read it, too ;-) But I'll have to read it again to fully get into it. > 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... Man setxkbmap states this: ------- If you have an Xserver and a client shell running on different computers and XKB configuration files on those machines are different you can get problems specifying a keyboard map by model, layout, options names. This is because setxkbcomp converts these names to names of XKB configuration files according to files that are on the client side computer, then it sends the file names to the server where the xkbcomp has to compose a complete keyboard map using files which the server has. Thus if the sets of files differ significantly the names that the setxkbmap generates can be unacceptable on the server side. You can solve this problem by running the xkbcomp on the client side too. With the -print option setxkbmap just prints the file names in an appropriate format to its stdout and this output can be piped directly to the xkbcomp input. For example, the command setxkbmap us -print | xkbcomp - $DISPLAY makes both steps run on the same (client) machine and loads a keyboard map into the server. ------- Wouldn't this bypass all this setxkbmap names and files altogether? Uli _______________________________________________ x2go-dev mailing list x2go-dev@lists.x2go.org http://lists.x2go.org/listinfo/x2go-dev From Robert.Siemer@backsla.sh Sun Dec 7 05:17:03 2014 Received: (at 674) by bugs.x2go.org; 7 Dec 2014 04:17:04 +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 X-Greylist: delayed 586 seconds by postgrey-1.34 at ymir.das-netzwerkteam.de; Sun, 07 Dec 2014 05:17:02 CET Received: from miranda.backsla.sh (woi4u.backsla.sh [213.239.218.239]) by ymir.das-netzwerkteam.de (Postfix) with ESMTP id D53735E0E0 for <674@bugs.x2go.org>; Sun, 7 Dec 2014 05:17:02 +0100 (CET) Received: from [192.168.2.107] (dslb-088-074-164-181.088.074.pools.vodafone-ip.de [88.74.164.181]) by miranda.backsla.sh (Postfix) with ESMTPSA id 66724D3014C for <674@bugs.x2go.org>; Sun, 7 Dec 2014 05:38:45 +0100 (CET) Message-ID: <5483D272.8020008@backsla.sh> Date: Sun, 07 Dec 2014 05:07:14 +0100 From: Robert Siemer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: 674@bugs.x2go.org Subject: Re: Bug#674: Acknowledgement (keycode -> keycode translation harmful (makes configuration complex)) References: <54654F43.1020306@backsla.sh> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit > I really think we should get evdev support into NX. What do you think? No, for keyboard configuration no special evdev support is needed. > 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? For the commands see below. – At the moment I remove _XKB_RULES_NAMES from the root window property before starting/resuming x2go. > Wouldn't [running xkbcomp on the client] bypass all this setxkbmap > names and files altogether? I do already run xkbcomp on the client (and local as well) already, but it has no influence on keycode translation. – I’m not sure why you mentioned it... I believe I know the reasoning behind this keycode translation: in a heterogeneous environment, where you resume an x2go session from different workstations, there exists only one way to represent the different keyboards as an unchanging virtual keyboard. Yes: with keycode translation. The alternative would be to reconfigure XKB on each session resume, which I believe is perfectly reasonable. – This is what I (would) do. Allow me to draw a little ascii diagram here (look at it with fixed width font): local Xserver local Xclients x2go Xserv x2go Xclients [1] |==================xterm |==================chromium |==================xlsclients [3] |==================setxkbmap |==================xkbcomp [7] | [2] |------------------------------------|==============xterm |------------------------------------|==============gnome-do [6] |------------------------------------|==============xlsclients [4] |------------------------------------|==============setxkbmap |------------------------------------|==============xkbcomp [8] This is about the X11 protocol level view of an x2go setup. There are two Xservers running: the local one [1] and that x2go Xserver (that is called nxagent?) [2]. Both are drawn as lines made of | The x2go Xserver [2] represents its clients to the real local Xserver [1] as X11 clients, but draws them in a different way (still X11 protocol, though). An xlsclients [4] executed on the x2go server will be run against [2] and show only the x2go Xclients. On the local Xserver [1] an execution of xlsclients [3] lists all Xclients: the local ones and the remote ones. Unfortunately the x2go Xserver [2] does not relay all and everything to the local Xserver [1]. Examples: the X properties of the root window (some kind of “global” storage for X clients) exist twice (in [1] and [2]) and can differ. Also global hotkeys (“passive keygrabs”) of the x2go Xclients will be stored in [2] and have no influence on [1]. The launcher gnome-do [5] registers a hotkey: it will only be delivered to [5] if the local Xserver [1] has no local Xclient waiting for it _and_ any of the x2go client windows is in focus. Otherwise [2] will not even see the key event. Back to XKB. As far as I could observe, the XKB setup consists of an XKB configuration (which can be read and written with xkbcomp [7][8]) and the root window property _XKB_RULES_NAMES (can be read with xprop and setxkbmap and is written as a side effect of setxkbmap). Note that both things exist twice, stored in [1] and [2]. Command line examples: # dump current XKB configuration into one file $ xkbcomp $DISPLAY full.xkb # load full single-file XKB configuration $ xkbcomp full.xkb $DISPLAY # load from multiple files (xkbcomp will read more than one file): # main keymap file triggers inclusion of files from system X11 files $ xkbcomp keymap.xkb $DISPLAY # example keymap.xkb file xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete+my" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+inet(evdev)+eurosign(e)" }; xkb_geometry { include "pc(pc104)" }; }; # load from multiple files and have those searched for in your own tree # otherwise they will be looked for in XKB root /usr/share/X11/xkb $ xkbcomp -I/home/blabla/xkb mykeymap.xkb $DISPLAY # read _XKB_RULES_NAMES $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES(STRING) = "evdev", "pc104", "us,us", "altgr-intl,", "eurosign:e,caps:backspace,compose:rctrl" # interpreted version of the above $ setxkbmap -query rules: evdev model: pc104 layout: us,us variant: altgr-intl, options: eurosign:e,caps:backspace,compose:rctrl # delete _XKB_RULES_NAMES property (and then read it) $ xprop -root -remove _XKB_RULES_NAMES $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES: not found. $ setxkbmap -query Couldn't interpret _XKB_RULES_NAMES property Use defaults: rules - 'base' model - 'pc105' layout - 'us' rules: base model: pc105 layout: us # set _XKB_RULES_NAMES only(!) # I wrote a tool for that (xprop can’t set STRING arrays) # https://github.com/siemer/xproperty $ ./xproperty.py _XKB_RULES_NAMES evdev pc104 us altgr-intl _XKB_RULES_NAMES evdev pc104 us altgr-intl # let setxkbmap read this property, override a part of it # and ask which keymap it would load $ setxkbmap -layout de -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwertz)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+de+inet(evdev)" }; xkb_geometry { include "pc(pc104)" }; }; # without “-print” setxkbmap will write the updated property _and_ # instruct the X11 server to load the resulting configuration # with the help of xkbcomp # → setxkbmap can’t just update the property alone On x2go session startup, the x2go Xserver [2] does a superficial investigation of what keyboard is used on the local Xserver [1] and sets up an incomplete keycode translation to a keyboard known as “xfree86”. It further creates an imperfect copy of the XKB configuration from [1] to [2]. The _XKB_RULES_NAMES property on [2] is set to rules=xfree86, model = pc???, layout = us(?) [I forgot the details]. Why is it a superficial investigation? – It takes the rules name from _XKB_RULES_NAMES and deducts the resulting keycodes directly from that (I believe). Even though in a common setup rules name “evdev” results in one specific set of keycodes and rules name “xfree86” in another specific set of keycodes, this is not a must. Why is the keycode translation incomplete? – As far as I observed it, “unusual” or unknown keycodes are not translated and passed as-is. Why is the XKB configuration copy imperfect? – I did a XKB dump on the local Xserver [1] and the x2go Xserver [2] after starting a new session. Keys with four levels of symbols turned into two-level-keysyms. – _Loading_ (i.e. xkbcomp/setxkbmap) a four-level configuration is no problem, though. Note: the imperfect copy of the XKB configuration is almost always useless, because the copied configuration does not match the new (translated) keycodes! Resuming an x2go session triggers the same superficial keyboard investigation, the translation kicks in again, but the XKB configuration is not touched (i.e. is not copied from [1] to [2]). Deleting the _XKB_RULES_NAMES property before session startup/resume or setting the first part (that is the “rules” part) to some unknown string results in untranslated keycodes. Please pardon me for repeating myself in some instances. Robert From ulrich.sibiller@gmail.com Mon Dec 8 00:07:29 2014 Received: (at 674) by bugs.x2go.org; 7 Dec 2014 23:07:29 +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.3 required=5.0 tests=BAYES_40,FREEMAIL_FROM, FREEMAIL_REPLYTO,FREEMAIL_REPLYTO_END_DIGIT,T_DKIM_INVALID,URIBL_BLOCKED autolearn=no version=3.3.2 Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id DF9075E0E0 for <674@bugs.x2go.org>; Mon, 8 Dec 2014 00:07:28 +0100 (CET) Received: by mail-lb0-f177.google.com with SMTP id b6so2858828lbj.22 for <674@bugs.x2go.org>; Sun, 07 Dec 2014 15:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=RkW4FyP+GYKrWkx4KXwa6K1eo/y9MGj/ZshOgq8ng34=; b=GMjyV8Bv65ew2CWCHvo3nOKRHk+0UcKeBYXk6dNeRSyTx9724imwdEamKwgBP5XEUS /ZklJU0PnHocDRJrvg9i804+tJr4YpX0jXIDtEq12QI2QGZ1tLSFXfRwXz4OlHqZEIcg whb8AbBXvSX3ss2VQS5n05nUBp1oHGRiXOFp1YfPgwsLKFqVgu0+cgWjI1VKmCmHfWEW Y1IvlbO1rYgZ0hm3wXi9kSeIjNRQcZ1QXpOpHgQJc8hX9XKzMj1puScp5uypvoXmSdA7 e+uypcyDUjhW8pm/yRc8GTzSF9UZVkfPs+tTNVSgO7SC9yedbp6NN/qhWmB84kO9P+aa l24Q== X-Received: by 10.152.36.232 with SMTP id t8mr13555949laj.6.1417993647929; Sun, 07 Dec 2014 15:07:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.89.101 with HTTP; Sun, 7 Dec 2014 15:07:07 -0800 (PST) Reply-To: uli42@gmx.de In-Reply-To: <5483D272.8020008@backsla.sh> References: <54654F43.1020306@backsla.sh> <5483D272.8020008@backsla.sh> From: Ulrich Sibiller Date: Mon, 8 Dec 2014 00:07:07 +0100 Message-ID: Subject: Re: [X2Go-Dev] Bug#674: Acknowledgement (keycode -> keycode translation harmful (makes configuration complex)) To: Robert Siemer , 674@bugs.x2go.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Dec 7, 2014 at 5:07 AM, Robert Siemer wr= ote: > On x2go session startup, the x2go Xserver [2] does a superficial > investigation of what keyboard is used on the local Xserver [1] and sets = up > an incomplete keycode translation to a keyboard known as =E2=80=9Cxfree86= =E2=80=9D. It > further creates an imperfect copy of the XKB configuration from [1] to [2= ]. > The _XKB_RULES_NAMES property on [2] is set to rules=3Dxfree86, model =3D= pc???, > layout =3D us(?) [I forgot the details]. > > Why is it a superficial investigation? =E2=80=93 It takes the rules name = from > _XKB_RULES_NAMES and deducts the resulting keycodes directly from that (I > believe). Even though in a common setup rules name =E2=80=9Cevdev=E2=80= =9D results in one > specific set of keycodes and rules name =E2=80=9Cxfree86=E2=80=9D in anot= her specific set of > keycodes, this is not a must. > > Why is the keycode translation incomplete? =E2=80=93 As far as I observed= it, > =E2=80=9Cunusual=E2=80=9D or unknown keycodes are not translated and pass= ed as-is. > > Why is the XKB configuration copy imperfect? =E2=80=93 I did a XKB dump o= n the local > Xserver [1] and the x2go Xserver [2] after starting a new session. Keys w= ith > four levels of symbols turned into two-level-keysyms. =E2=80=93 _Loading_= (i.e. > xkbcomp/setxkbmap) a four-level configuration is no problem, though. > > Note: the imperfect copy of the XKB configuration is almost always useles= s, > because the copied configuration does not match the new (translated) > keycodes! > > Resuming an x2go session triggers the same superficial keyboard > investigation, the translation kicks in again, but the XKB configuration = is > not touched (i.e. is not copied from [1] to [2]). > > Deleting the _XKB_RULES_NAMES property before session startup/resume or > setting the first part (that is the =E2=80=9Crules=E2=80=9D part) to some= unknown string > results in untranslated keycodes. I am not sure if I am getting this right. Will using xkbcomp on the local server, pushing the result to the nxagent and loading it there result in a clean keyboard setup or not? Do we need to disable setting up the translation within the nx code to make that work? Uli BTW: You can find the code for the keycode translation in nx-x11/programs/Xserver/hw/nxagent/Keyboard.c. It seems some kind of translation from evdev to pc105 is done. You can also see that if there is no "xfree86" rules file the one called "xorg" is used instead (if available, of course). From Robert.Siemer@backsla.sh Sat Dec 13 01:45:06 2014 Received: (at 674) by bugs.x2go.org; 13 Dec 2014 00:45:08 +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 miranda.backsla.sh (woi4u.backsla.sh [213.239.218.239]) by ymir.das-netzwerkteam.de (Postfix) with ESMTP id 0D01E5E0F6 for <674@bugs.x2go.org>; Sat, 13 Dec 2014 01:45:05 +0100 (CET) Received: from [192.168.2.107] (dslb-088-074-164-181.088.074.pools.vodafone-ip.de [88.74.164.181]) by miranda.backsla.sh (Postfix) with ESMTPSA id A797CD30154; Sat, 13 Dec 2014 02:16:54 +0100 (CET) Message-ID: <548B8C0E.7020701@backsla.sh> Date: Sat, 13 Dec 2014 01:45:02 +0100 From: Robert Siemer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: uli42@gmx.de, 674@bugs.x2go.org Subject: Re: [X2Go-Dev] Bug#674: Acknowledgement (keycode -> keycode translation harmful (makes configuration complex)) References: <54654F43.1020306@backsla.sh> <5483D272.8020008@backsla.sh> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 08/12/14 00:07, Ulrich Sibiller wrote: > On Sun, Dec 7, 2014 at 5:07 AM, Robert Siemer wrote: >> On x2go session startup, the x2go Xserver [2] does a superficial >> investigation of what keyboard is used on the local Xserver [1] and sets up >> an incomplete keycode translation to a keyboard known as “xfree86”. It >> further creates an imperfect copy of the XKB configuration from [1] to [2]. >> The _XKB_RULES_NAMES property on [2] is set to rules=xfree86, model = pc???, >> layout = us(?) [I forgot the details]. >> >> Why is it a superficial investigation? – It takes the rules name from >> _XKB_RULES_NAMES and deducts the resulting keycodes directly from that (I >> believe). Even though in a common setup rules name “evdev” results in one >> specific set of keycodes and rules name “xfree86” in another specific set of >> keycodes, this is not a must. >> >> Why is the keycode translation incomplete? – As far as I observed it, >> “unusual” or unknown keycodes are not translated and passed as-is. >> >> Why is the XKB configuration copy imperfect? – I did a XKB dump on the local >> Xserver [1] and the x2go Xserver [2] after starting a new session. Keys with >> four levels of symbols turned into two-level-keysyms. – _Loading_ (i.e. >> xkbcomp/setxkbmap) a four-level configuration is no problem, though. >> >> Note: the imperfect copy of the XKB configuration is almost always useless, >> because the copied configuration does not match the new (translated) >> keycodes! >> >> Resuming an x2go session triggers the same superficial keyboard >> investigation, the translation kicks in again, but the XKB configuration is >> not touched (i.e. is not copied from [1] to [2]). >> >> Deleting the _XKB_RULES_NAMES property before session startup/resume or >> setting the first part (that is the “rules” part) to some unknown string >> results in untranslated keycodes. > > I am not sure if I am getting this right. Will using xkbcomp on the > local server, pushing the result to the nxagent and loading it there > result in a clean keyboard setup or not? That depends on whether the keycode translation is on or off. If the translation it is not in effect, then yes, you get a setup like you have without x2go. If the translation is on, you get a skewed setup. Note that the x2go (with the setting of “do nothing”) does a non-perfect copy with the same effect: if the translation is effective, the keyboard is skewed and you are force to load at least “something” to fix XKB. If the translation is off, you “only” need to load XKB configuration if that non-perfect copy annoys you... Btw, the forme is exactly what I do: dump local XKB configuration, make sure I don’t get a translation in x2go and load it on the other side. > BTW: You can find the code for the keycode translation in > nx-x11/programs/Xserver/hw/nxagent/Keyboard.c. Thanks for the pointer! I had a look at it. As I suspected: the translation is “bad”. Sometimes two different keycodes are translated to the same keycode. How are you supposed to tell them apart on the remote side? You can’t. > It seems some kind of translation from evdev to pc105 is done. The naming is a little funny: the keycodes generated by the kernel before evdev were not called like that, were they? > Do we need to disable setting > up the translation within the nx code to make that work? That would be great as a first step. From ulrich.sibiller@gmail.com Tue Dec 16 10:40:27 2014 Received: (at 674) by bugs.x2go.org; 16 Dec 2014 09:40:28 +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,FREEMAIL_FROM, T_DKIM_INVALID,URIBL_BLOCKED autolearn=ham version=3.3.2 Received: from mail-la0-f51.google.com (mail-la0-f51.google.com [209.85.215.51]) by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id F30D05DB1C for <674@bugs.x2go.org>; Tue, 16 Dec 2014 10:40:26 +0100 (CET) Received: by mail-la0-f51.google.com with SMTP id ms9so10908515lab.10 for <674@bugs.x2go.org>; Tue, 16 Dec 2014 01:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-type:content-transfer-encoding; bh=u7N8pkXpuPti5W5Oi9yk9v5jl1oRu+wpayXAmAHGC70=; b=VqBIl8Lb+mbvhx7BxnWcyx5Tx0lo6DamzqJIoCivCM0wylZkxnjN4bNridTwjhm3uF 4EbzZAr4KlR9f0Z+9dSP7DAlZJQeDpnJZe1D9/aIfKlAtnNAP17LaOZ7vyz9yer+C/mc Pg8abw5Gix5b8DlJmSzVSVv7CciMpTwlHeEoShpKalSm9RbJq4DIFSxDyJiIFGz/XQJC BvpnRjEHxNBmbnJbsvy/grWlp23GuUC1IkHEvtK8huVp6XtYz9whxZrfbW+bTrCpikWk KqObHOdLoRqxY/97rKAJA31E4uuaIDqqWbH+4B45RYkOdJ9SswO7IS9M9xFrJZz2uCfG UPNQ== X-Received: by 10.112.172.194 with SMTP id be2mr7010280lbc.53.1418722826472; Tue, 16 Dec 2014 01:40:26 -0800 (PST) MIME-Version: 1.0 Sender: ulrich.sibiller@gmail.com Received: by 10.112.89.101 with HTTP; Tue, 16 Dec 2014 01:40:06 -0800 (PST) In-Reply-To: References: <54654F43.1020306@backsla.sh> <5483D272.8020008@backsla.sh> <548B8C0E.7020701@backsla.sh> From: Ulrich Sibiller Date: Tue, 16 Dec 2014 10:40:06 +0100 X-Google-Sender-Auth: tbj6HEausJvv-_yBfOZrhzXYo3E Message-ID: Subject: Fwd: [X2Go-Dev] Bug#674: Acknowledgement (keycode -> keycode translation harmful (makes configuration complex)) To: 674@bugs.x2go.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sat, Dec 13, 2014 at 1:45 AM, Robert Siemer w= rote: > If the translation is on, you get a skewed setup. > > Note that the x2go (with the setting of =E2=80=9Cdo nothing=E2=80=9D) doe= s a non-perfect > copy with the same effect: if the translation is effective, the keyboard = is > skewed and you are force to load at least =E2=80=9Csomething=E2=80=9D to = fix XKB. If the > translation is off, you =E2=80=9Conly=E2=80=9D need to load XKB configura= tion if that > non-perfect copy annoys you... > Thanks for the pointer! I had a look at it. As I suspected: the translati= on > is =E2=80=9Cbad=E2=80=9D. Sometimes two different keycodes are translated= to the same > keycode. How are you supposed to tell them apart on the remote side? You > can=E2=80=99t. > >> It seems some kind of translation from evdev to pc105 is done. > > The naming is a little funny: the keycodes generated by the kernel before > evdev were not called like that, were they? I don't think so. >> Do we need to disable setting >> up the translation within the nx code to make that work? > > That would be great as a first step. I was wondering why this translations had been introduced. It emerged between nxagent 3.2.0-10 and 3.3.0-9. The changelog between these releases contains (among others) these changes: nxagent-3.3.0-9 - Changed Keyboard initialization and reset. This change should fix TR11F02129, TR11F02131, TR11F02132. nxagent-3.3.0-4 - Fix the XKB map load in the case of 64 bit server. nxagent-3.3.0-3 - Fixed TR10F02119. If the remote X display is using evdev keyboard then copy maps from remote. nxagent-3.2.0-12 - Fixed TR08E01814. Added shadow keymap initialization in order to enable nxcompshad to translate keycodes across different layouts. So it MIGHT have been introduced mainly for shadow sessions. The TR10F02119 refers to Ubuntu 8.10, which - according to some other posts I found - is the version that introduced evdev. So the fix that solved evdev problems is causing problems when evdev is enabled. I also looked at the source and found that clearing the property seems to be the only way to disable the translation. (apart from disabling XKB completely). Uli From mike.gabriel@das-netzwerkteam.de Tue Dec 16 15:42:33 2014 Received: (at 674) by bugs.x2go.org; 16 Dec 2014 14:42:35 +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 365B65DB1C for <674@bugs.x2go.org>; Tue, 16 Dec 2014 15:42:33 +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 BD18013A3; Tue, 16 Dec 2014 15:42:32 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by grimnir.das-netzwerkteam.de (Postfix) with ESMTP id A439C3BACC; Tue, 16 Dec 2014 15:42:32 +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 8Y-CsHZwoYwi; Tue, 16 Dec 2014 15:42:32 +0100 (CET) Received: from grimnir.das-netzwerkteam.de (localhost [127.0.0.1]) by grimnir.das-netzwerkteam.de (Postfix) with ESMTPS id 702393BABC; Tue, 16 Dec 2014 15:42:32 +0100 (CET) Received: from 46.115.132.150 ([46.115.132.150]) by mail.das-netzwerkteam.de (Horde Framework) with HTTP; Tue, 16 Dec 2014 14:42:32 +0000 Date: Tue, 16 Dec 2014 14:42:32 +0000 Message-ID: <20141216144232.Horde.p3bJGuiwLTCcXJi7k7d_Dw6@mail.das-netzwerkteam.de> From: Mike Gabriel To: Ulrich Sibiller , 674@bugs.x2go.org Subject: Re: [X2Go-Dev] Bug#674: Fwd: Bug#674: Acknowledgement (keycode -> keycode translation harmful (makes configuration complex)) References: <54654F43.1020306@backsla.sh> <5483D272.8020008@backsla.sh> <548B8C0E.7020701@backsla.sh> In-Reply-To: User-Agent: Internet Messaging Program (IMP) H5 (6.2.2) Accept-Language: en,de Organization: DAS-NETZWERKTEAM X-Originating-IP: 46.115.132.150 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="=_Mvz3T8ADky09f-Bit6cGtQ1"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 This message is in MIME format and has been PGP signed. --=_Mvz3T8ADky09f-Bit6cGtQ1 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Ulrich, On Di 16 Dez 2014 10:40:06 CET, Ulrich Sibiller wrote: > On Sat, Dec 13, 2014 at 1:45 AM, Robert Siemer=20=20 >=20 wrote: > >> If the translation is on, you get a skewed setup. >> >> Note that the x2go (with the setting of =E2=80=9Cdo nothing=E2=80=9D) do= es a non-perfect >> copy with the same effect: if the translation is effective, the keyboard= is >> skewed and you are force to load at least =E2=80=9Csomething=E2=80=9D to= fix XKB. If the >> translation is off, you =E2=80=9Conly=E2=80=9D need to load XKB configur= ation if that >> non-perfect copy annoys you... > >> Thanks for the pointer! I had a look at it. As I suspected: the translat= ion >> is =E2=80=9Cbad=E2=80=9D. Sometimes two different keycodes are translate= d to the same >> keycode. How are you supposed to tell them apart on the remote side? You >> can=E2=80=99t. >> >>> It seems some kind of translation from evdev to pc105 is done. >> >> The naming is a little funny: the keycodes generated by the kernel befor= e >> evdev were not called like that, were they? > > I don't think so. > >>> Do we need to disable setting >>> up the translation within the nx code to make that work? >> >> That would be great as a first step. > > I was wondering why this translations had been introduced. It emerged > between nxagent 3.2.0-10 and 3.3.0-9. The changelog between these > releases contains (among others) these changes: > > nxagent-3.3.0-9 > > - Changed Keyboard initialization and reset. This change should fix > TR11F02129, TR11F02131, TR11F02132. > > nxagent-3.3.0-4 > > - Fix the XKB map load in the case of 64 bit server. > > nxagent-3.3.0-3 > > - Fixed TR10F02119. If the remote X display is using evdev keyboard > then copy maps from remote. > > nxagent-3.2.0-12 > > - Fixed TR08E01814. Added shadow keymap initialization in order to > enable nxcompshad to translate keycodes across different layouts. > > So it MIGHT have been introduced mainly for shadow sessions. The > TR10F02119 refers to Ubuntu 8.10, which - according to some other > posts I found - is the version that introduced evdev. So the fix that > solved evdev problems is causing problems when evdev is enabled. > > I also looked at the source and found that clearing the property seems > to be the only way to disable the translation. (apart from disabling > XKB completely). > > Uli Note that you can view the changes between versions of nxagent via=20=20 nx-libs.git=20[1]. Use the "commitdiff" links in the right column... Mike [1] http://code.x2go.org/gitweb?p=3Dnx-libs.git;a=3Dshortlog;h=3Drefs/heads= /nxagent --=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 --=_Mvz3T8ADky09f-Bit6cGtQ1 Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJUkETYAAoJEJr0azAldxsxl1EP/iC50CKOTzTa5aLQzaFaqdGL pdOJMOGWt8QCCDNkOLU3RA+pTGxb+JmiM+lzFriLvBON2kXn/T+LunHAsbf0EWeJ Ng3Dxk2/dmc3WMHcxL6nM7hkS1iN1/lVZjhveRLGj8ETDtCHjDnm0VM1OqtnuCpw Ic92DLnfKGfANZigm8jxlvIFsjoFRwsaKOYXpsDNWRUM+NRj0OIxCl0d8DRA6xqF TWCt6tsTL01c3mdMIyOkZklffzkzAvc8Vp2xBAeKoRG4oan20OJ+2zgRy5LiUm8H 6KQKkXTPd9lYfrQG4nXC5uNMPkXiE8N+0+9zaG1XlmaLN0VTyDqTkelj7s++Bnc3 +H0w88WggqITY3SOvBv7TaVaKvBvnQf1kzSlSjt7ODkaLkIuUcJ0MuAo/m/o5ZOU VpBdDb01NFtv9u2Hc2ty8HMtzbpFbzQVg0utcah0ZhDs3AxVKmoOpah45E28jTlv 1k4e1BgqtLyH/gt/7ZFsn3MP0HmNvPsALoQGtxd6yEtNKvVXU3Wz3a1sVcyAdNV5 e6C6nqBaLspLmbeFt0oanUr/AY9vc9kqWvgY6xj/VYpe/hu1s9FXg8LaoBJAvI6D UDaEN9dCZrLRiv5sogTHT/quzQLZueOkEt2vfKXmQgxXekqB0sWg3kRHv5+j3otc 8laHd/iheO1yK6SGw6fJ =6dX+ -----END PGP SIGNATURE----- --=_Mvz3T8ADky09f-Bit6cGtQ1--