Can you please disable automatic keyboard detection in x2goclient for the session and retry? I spend some time last week to look into that and it seems there's a really a bug. I was interrupted and had no time to further track that down. But it seems that the way x2goclient is passing keyboard stuff (by asking for "null/null" which triggers a special path in nx) is not handled correctly for the shadow mode. So disabling automatic keyboard detection in x2go should bypass that broken code. I have not tested, though..
Uli
On Mon, Sep 9, 2019 at 9:23 AM <gleb.shipitsyn@gmx.com> wrote:
Entschuldigung for late reply. This was a busy week.
Anyway. I've tested your suggestions:
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).
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:
- 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.
- 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