Entschuldigung for late reply. This was a busy week.

Anyway. I've tested your suggestions:
1) No difference if I force evdev rules running shadow session - still wrong codes for comma, dot, slash and stuff like that on Russian and English layouts (it works correctly on KZ layout though but it was like that before).

2) As far as I can see no keycodes conversion mode is running. Setting -keycode option on server brakes capability to connect to it (Access denied for user on my windows x2go client). Can't play with it on other clients since something broke on another linux machine so client can't find local desktops and I'm trying to fix it.

So for now it seems like a bug to me.

2 сент. 2019 г. 14:39 пользователь Ulrich Sibiller <uli42@gmx.de> написал:

On Mon, Sep 2, 2019 at 4:48 AM <gleb.shipitsyn@gmx.com> wrote:
>
> What do you mean? Why would I need to set evdev rules on session where evdev rules are already active? I'm not sure what is the point of this.

Well, there are applications that modify the keyboard directly with
xmodmap. Running setxkbmap again will ensure the settings are
re-applied.

> See, there are two situations:
> 1) Remote login aka "separate user with his own desktop" establishes connection with xfree86 rules and alles gut - keys on every layout work exactly as they should.

That is what puzzles me since xfree86 has been removed from NX a long
time ago (what version of nx are you using on the server?). I am not
using x2go from Windows so it might be that VcXsrv is still using
xfree86.

> 2) Remote login aka "show me your desktop" establishes connection to current local session which use evdev rules by default. And most keys are ok, but with exceptions I've mentioned earlier.

NX has an internal translation function that gets activated if evdev
is detected on the _client_ side. Normally this is not used as NX
switches to keyboard clone mode if called by x2go. You can see if this
translation is active by looking at your session logfile on the server
(grep "Keycode conversion" ~/.x2go/C-*/session.log). If the keycode
conversion is active you a behaviour similar to what you described.
Please check in your logfile if keycode conversion is on and report
the result. If you do not find any lines regarding keycode conversion
in the session log it means you are using keyboard clone mode which is
designed to "just do it right". In your case we might hitting a bug
that needs more investigation.


> PS. I would be great if x2goclient would use evdev natively, since it is most common ruleset on modern distros.

Well, as I wrote: It should always clone the settings it finds on the
client side. You are using a so called "shadowed" session ("connect to
local desktop"). That setup is not tested as well as "normal" session
as it is slower by design. It might be that we hitting a bug here.

One thing you can try: add

X2GO_NXAGENT_DEFAULT_OPTIONS+=" -keyconv off"

to /etc/x2go/x2goagent.options and retry.

Uli