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.beis...@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 >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ x2go-user mailing list x2go-user@lists.x2go.org https://lists.x2go.org/listinfo/x2go-user
