On Wed, Jun 17, 2020 at 1:28 PM Simon Beißer <simon.beisser@hetzner.com> wrote:
You can verify that assumption by running xev inside the x2go session. If you see correct events, keysyms and keycodes, then the browser gets something wrong.
I have tested with xev before and could not find any direct problems. Also within the browser all keys work correctly.
So then the browser's translation is the culprit.
Only in the KVM console the assignment is wrong. It must somehow be in interaction with x2go/nx. I have tried it locally when I log in directly to the X - everything works there.
So when you do that what is the keyboard configuration in X (setxkbmap -query)?
My guess is that the physical key assignment via nx is not correct. With virtual consoles, such as the KVM client, this so-called keycode (KeyboardEvent.code) is probably used. You can then select the actual keyboard layout within the KVM console. Thus the consoles are independent of the keyboard layout selected on the system because they access "KeyboardEvent.code" directly, i.e. the physically transmitted key.
You can also read about it here: https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/code
Here you can check which KeyboardEvent.code was pressed: https://w3c.github.io/uievents/tools/key-event-viewer.html
Using x2go, some keys show wrong values there, e.g. all arrow keys (except arrow up).
Can you reproduce this?
Cannot try right now.
If the session you are starting via x2go happens to be a kde session
We are using xfce.
What keyboard setting is your x2go session using?
We are using xfree86 as keyboard configuration with pc105 de layout.
Argh!! xfree86 is long gone and dead. I wouldn't place any bets on that. Please configure automatic keyboard detection!
Uli