Hello everyone,
we use x2go in our company and it works really well.
However, currently we have noticed two problems that occur in connection with an HTML5 KVM (remote console) client. Maybe one of you has an idea about these issues.
1st question When using the keyboard within the KVM console, we noticed that the arrow down key is incorrectly assigned and triggers an Enter. With the help of a keycode event tool I found that the NumpadEnter is transmitted there, see screenshot in the appendix. It seems that the wrong physical key (key code) is transmitted via x2go/nx. This has nothing directly to do with the keyboard layout used and therefore unfortunately cannot be changed within the virtual console. Is this error known? Is there a fix for it?
2nd question OpenGL/GLX is required for the KVM console. Unfortunately, only GLX1.2 is in use among the current nx-libs, which is why this does not work in Firefox. I have found only VirtualGL as workaround. Do you know other methods to make such applications running?
Best regards Simon
On Wed, Jun 17, 2020 at 11:21 AM Simon Beißer <simon.beisser@hetzner.com> wrote:
we use x2go in our company and it works really well.
However, currently we have noticed two problems that occur in connection with an HTML5 KVM (remote console) client. Maybe one of you has an idea about these issues.
I have experienced such problems with HTML5 KVM clients as well. My impression is that those are still not as powerful and not as sophisticated as their ugly java predecessors. Such minor problems are happening all the time..
Sometimes it helps to align the keyboard and language settings both in the browser and the shell you start the browser from. Sometimes you can adjust keyboard settings in the HTML5 kvm.
1st question When using the keyboard within the KVM console, we noticed that the arrow down key is incorrectly assigned and triggers an Enter. With the help of a keycode event tool I found that the NumpadEnter is transmitted there, see screenshot in the appendix. It seems that the wrong physical key (key code) is transmitted via x2go/nx. This has nothing directly to do with the keyboard layout used
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.
If the session you are starting via x2go happens to be a kde session you might improve the situation by killing the kglobalaccel process which sometimes breaks keyboard by swallowing certain keyrelease events.
and therefore unfortunately cannot be changed within the virtual console. Is this error known? Is there a fix for it?
What keyboard setting is your x2go session using?
2nd question OpenGL/GLX is required for the KVM console. Unfortunately, only GLX1.2 is in use among the current nx-libs, which is why this does not work in Firefox. I have found only VirtualGL as workaround. Do you know other methods to make such applications running?
Yes, there's this workaround: https://wiki.x2go.org/doku.php/wiki:development:glx-xlib-workaround?s[]=glx
Uli
Hi Uli,
Thanks for your quick response.
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.
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.
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?
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.
Yes, there's this workaround:
https://wiki.x2go.org/doku.php/wiki:development:glx-xlib-workaround?s[]=glx
Thanks for this. I'm gonna try that.
Best regards Simon
Am 17.06.2020 um 12:28 schrieb Ulrich Sibiller:
On Wed, Jun 17, 2020 at 11:21 AM Simon Beißer <simon.beisser@hetzner.com> wrote:
we use x2go in our company and it works really well.
However, currently we have noticed two problems that occur in connection with an HTML5 KVM (remote console) client. Maybe one of you has an idea about these issues.
I have experienced such problems with HTML5 KVM clients as well. My impression is that those are still not as powerful and not as sophisticated as their ugly java predecessors. Such minor problems are happening all the time..
Sometimes it helps to align the keyboard and language settings both in the browser and the shell you start the browser from. Sometimes you can adjust keyboard settings in the HTML5 kvm.
1st question When using the keyboard within the KVM console, we noticed that the arrow down key is incorrectly assigned and triggers an Enter. With the help of a keycode event tool I found that the NumpadEnter is transmitted there, see screenshot in the appendix. It seems that the wrong physical key (key code) is transmitted via x2go/nx. This has nothing directly to do with the keyboard layout used
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.
If the session you are starting via x2go happens to be a kde session you might improve the situation by killing the kglobalaccel process which sometimes breaks keyboard by swallowing certain keyrelease events.
and therefore unfortunately cannot be changed within the virtual console. Is this error known? Is there a fix for it?
What keyboard setting is your x2go session using?
2nd question OpenGL/GLX is required for the KVM console. Unfortunately, only GLX1.2 is in use among the current nx-libs, which is why this does not work in Firefox. I have found only VirtualGL as workaround. Do you know other methods to make such applications running?
Yes, there's this workaround: https://wiki.x2go.org/doku.php/wiki:development:glx-xlib-workaround?s[]=glx
Uli
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
So then the browser's translation is the culprit.
I'm not sure about it. The browser implements the standard as it is defined (https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/code) as you can see with the help of this website: https://w3c.github.io/uievents/tools/key-event-viewer.html
So when you do that what is the keyboard configuration in X (setxkbmap -query)?
The local X runs with the following default settings
rules: evdev model: pc105 layout: de variant: nodeadkeys
I have also tried these settings via x2go. Unfortunately, the key code is still interpreted as "NumpadEnter" and is therefore passed on to the KVM console.
Argh!! xfree86 is long gone and dead. I wouldn't place any bets on that. Please configure automatic keyboard detection!
Okay. But it seems still the default in "/etc/x2go/x2goagent.keyboard".
Best regards Simon
Am 17.06.2020 um 13:57 schrieb Ulrich Sibiller:
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
On Thu, Jun 18, 2020 at 10:52 AM Simon Beißer <simon.beisser@hetzner.com> wrote:
So then the browser's translation is the culprit.
I'm not sure about it. The browser implements the standard as it is defined (https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent/code) as you can see with the help of this website: https://w3c.github.io/uievents/tools/key-event-viewer.html
So when you do that what is the keyboard configuration in X (setxkbmap -query)?
The local X runs with the following default settings
rules: evdev model: pc105 layout: de variant: nodeadkeys
I have also tried these settings via x2go. Unfortunately, the key code is still interpreted as "NumpadEnter" and is therefore passed on to the KVM console.
As I wrote, let x2go do the keyboard stuff and so not set an own one. Internally there's is some magic happening which converts some keycodes in certain circumstances. Ensure that setxkbmap -query outputs the same locally and in the session.
Please also check if there's any hint about keycode conversion in the log of the session (~/.x2go/.../session.log), one of these messages Info: Keycode conversion is on Info: Keycode conversion is off Info: Keycode conversion auto-determined as on Info: Keycode conversion auto-determined as off
It should be off in your case.
Argh!! xfree86 is long gone and dead. I wouldn't place any bets on that. Please configure automatic keyboard detection!
Okay. But it seems still the default in "/etc/x2go/x2goagent.keyboard".
Reading that file has been dropped from nx in February of 2017 (3.5.99.17). If x2go still delivers that it is a bug!
Uli
On 6/18/20 4:12 AM, Ulrich Sibiller wrote:
On Thu, Jun 18, 2020 at 10:52 AM Simon Beißer <simon.beisser@hetzner.com> wrote:
Argh!! xfree86 is long gone and dead. I wouldn't place any bets on that. Please configure automatic keyboard detection!
Okay. But it seems still the default in "/etc/x2go/x2goagent.keyboard".
Reading that file has been dropped from nx in February of 2017 (3.5.99.17). If x2go still delivers that it is a bug!
Uli
So, the X2go x2goagent package no longer delivers this file, but the Fedora one does. This is because x2goserver's install_config make rule still installs the file.
-- Orion Poplawski Manager of NWRA Technical Systems 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion@nwra.com Boulder, CO 80301 https://www.nwra.com/
-
Orion Poplawski -
Simon Beißer -
Ulrich Sibiller