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
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
On Tue, Sep 10, 2019 at 10:46 AM <gleb.shipitsyn@gmx.com> wrote:
As much as I can see it makes absolutely no difference if x2goclient has switch set on auto-detect keyboard settings and on disabled keyboard detection. Same wrong keycodes.
If I force russian keyboard in x2goclient it behaves differently: Shift+2 returns "!", not "@" for example. Comma and dot works properly while slash is not. Kinda weird.
Unfortunately I cannot force three keyboard layouts simultaneously and check this way since it does not accept multiple values as argument.
Ok, you can disable keyboard detection in x2goclient _and_ force the keyboard in /etc/x2go/x2goagent.options:
X2GO_NXAGENT_DEFAULT_OPTIONS+=" -keyboard <your choice>"
man nxagent shows you the available options:
keyboard=<string> or kbtype=<string>
query|clone|<model>/<layout>|rmlvo/<rules>#<model>#<lay-
out>#<variant>#<options>
query use the default XKB keyboard layout (see below) and
only allow clients to query the settings but prevent
any changes. query is especially helpful for setups
where you need to set/modify the actual keyboard layout
using core X protocol functions (e.g. via xmodmap). It
is used for MacOS X clients to handle some keyboard
problems that are special for this platform. Note that
in this case XKEYBOARD will always report the default
layout which will most likely not match the experienced
settings.
clone ask the real X server for the keyboard settings using
XKEYBOARD protocol functions and clone them. This is
the recommended setting. For compatibility reasons it
is not the default.
<model>/<layout>
use the given model and layout. A value of null/null is
equivalent to clone. You can not modify keyboard rules,
variant or options this way. Instead preset values are
used. These are base for rules and empty strings for
variant and options.
rmlvo/<rules>#<model>#<layout>#<variant>#<options>
configure the keyboard according to the rmlvo
(Rules+Model+Layout+Variant+Options) description given
after the / and separated by #. This can be used to
fully pass the keyboard configuration of nxagent right
after the start. Example:
rmlvo/base#pc105#de,us#nodeadkeys#lv3:rwin_switch
If keyboard is omitted the internal defaults of nxagent will be
used (rules: base, layout: us, model: pc102, empty variant and
options).Uli
-
gleb.shipitsyn＠gmx.com -
Ulrich Sibiller