<div dir='auto'><div>Entschuldigung for late reply. This was a busy week.</div><div dir="auto"><br></div><div dir="auto">Anyway. I've tested your suggestions:</div><div dir="auto">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).</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">So for now it seems like a bug to me.<br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">2 сент. 2019 г. 14:39 пользователь Ulrich Sibiller <uli42@gmx.de> написал:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">On Mon, Sep 2, 2019 at 4:48 AM <gleb.shipitsyn@gmx.com> wrote:
<br>
>
<br>
> 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.
<br>

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

<br>
> See, there are two situations:
<br>
> 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.
<br>

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

<br>
> 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.
<br>

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

<br>

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

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

<br>
One thing you can try: add
<br>

<br>
X2GO_NXAGENT_DEFAULT_OPTIONS+=" -keyconv off"
<br>

<br>
to /etc/x2go/x2goagent.options and retry.
<br>

<br>
Uli
<br>
</p>
</blockquote></div><br></div></div></div>