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: [X2Go-Dev] Bug#674: Acknowledgement (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: Sat, 13 Dec 2014 00:50:01 +0000
Resent-Message-ID: <handler.674.B674.14184315082713@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.14184315082713
          (code B ref 674); Sat, 13 Dec 2014 00:50:01 +0000
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 <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: uli42@gmx.de, 674@bugs.x2go.org
References: <54654F43.1020306@backsla.sh> <handler.674.B.141592592311413.ack@bugs.x2go.org> <5483D272.8020008@backsla.sh> <CANVnVYK+YXWc_FJqeaEG325AJtGXYSfpD_zx+vbvESOt5WudxA@mail.gmail.com>
In-Reply-To: <CANVnVYK+YXWc_FJqeaEG325AJtGXYSfpD_zx+vbvESOt5WudxA@mail.gmail.com>
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 <Robert.Siemer@backsla.sh> 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.

Send a report that this bug log contains spam.