keyboard issue with xorgxrdp

[iwsbarker]

We are using an old Java applicaton (Oracle Virtual Desktop Client for SunRay) that can be made to work with xrdp/VNC with xmodmap, but we cannot get it to work with xorgxrdp. Several keys map completely incorrectly, and xmodmap changes appear to be ignored. Running xev on the console vs in xorgxrdp shows, for example, that the console uses keycode 116 for the down arrow, while xorgxrdp is using keycode 104 for the down arrow; however, keycode 104 at the console is KP_Enter, and that's how the Java application is also treating keycode 104 (ie. in the Java application, using the down arrow results in the application thinking Enter has been pressed). Running xorg-genkeymap at the console and then using the resulting keymap for the default keyboard layout (km-0409.ini in our case) has no effect on this either.

[jsorg71]

If you run setxkbmap -query you can see that the xrdp session uses the base rules and the console uses evdev. That is why the keycodes differ. I tried to use evdev in xorgxrdp but it was unstable without the evdev kernel module driving it. Applications should not rely on the keycode anyway and this seems like an application bug.

[iwsbarker]

It's definitely an application bug, but unfortunately we're stuck with it - the vendor has discontinued work on it, but we still require it in our production environment for the next couple of years. Any chance of getting xorgxrdp to work with xmodmap like xrdp/VNC did?

[jsorg71]

Hum, xrdp/VNC uses the "base" rules too. Instead of comparing xev output using console vs xrdp/xorgxrdp. Try comparing xrdp/XVNC vs xrdp/xorgxrdp.

[mirabilos]

I’ve debugged these keyboard issues this week.

First off, various clients have various levels of support; freerdp-x11 seems to be the best so far, rdesktop not so much, guacamole even less.

In Debian sid (unstable), keyboard-related stuff, even with completely custom layouts, works fine.

In Debian jessie (stable), we can see the same issues with the Down key triggering Return, when the keyboard layout is loaded by xmodmap; use of setxkbmap is fine. Looking at xev, the keycode is the same while the keysym differs:

• xev on Debian sid, native X.org session, reports keycode 116 (keysym Down) for Cur↓
• xev on Debian sid, xrdp session (from sid), reports keycode 104 (keysym Down)
• xev on Debian jessie, xrdp session (from sid), reports keycode 104 (keysym LP_Enter)

I tracked this down to X.org’s utterly stupid and completely and fully idiotic change of keycodes somewhere between Debian squeeze and wheezy (as noticed by Mika Prokop from Grml.org) which requires one to have separate keyboard layouts for XFree86®, old-style X.org (though these two are almost identical) and new-style X.org. In my layout I’m tracking old and new X.org, respectively, in the “gnu” and “grml” branches.

Funnily enough, loading the “old X.org”-style layout with xmodmap after logging in to xrdp fixes my keyboard issue.

My guess is that X.org somehow gained, since the release of jessie (which had 1.16, unstable has 1.18), a translation layer which converts between old- and new-style keycodes when needed, probably at xmodmap time; xkb-based layouts appear to be fine in either.

This is with xrdp as of 1ˢᵗ of June, 2016. Older versions (~ September 2015) had more keyboard issues.

Cc: @Natureshadow

[iwsbarker]

Would you mind explaining how you got it working using setxkbmap? I tried that too, but still get keycode 104 out of the down arrow. Thanks.

[mennozon]

I know this is a rather old issue but it seems the problem is still there when using xorgxrdp.

Using Debian Buster (xrdp 0.9.9-1, xorgxrdp 1:0.2.9-1) on both machines.

xev locally returns keycode 116 for arrow down, in xrdp using vnc it is also keycode 116 but in xrdp with xorgxrdp the keycode is 104.

For most applications this isn't an issue but things like VNC/java consoles 104 maps to enter making the arrow keys non-functional.

I've also was able to load the keyboard mappings with setxkbmap but the end result is the same.

@mirabilos Could you tell us if your layouts should still resolve this issue?

[jsorg71]

xrdpxorg uses the base rules, console Xorg used evdev rules. Some of the scan codes are different between the two. evdev should be used with the Linux evdev input in kernel. Apps should work with both so shouldn't be a problem. We were using evdev a few years ago but it didn't work as well as it's mean to work with evdev in the kernel.

[mirabilos]

jsorg71 dixit:

xrdpxorg uses the base rules, console Xorg used evdev rules. Some of the scan codes are different between the two. evdev should be used with the Linux evdev input in kernel. Apps should work with both so shouldn't be a problem.

Fully agree. If you have an xkb-based layout, things just work; if your layout is xmodmap-based, you have to use the classical scancodes, i.e. those in use with pre-evdev x.org (Debian lenny or so) and XFree86®. On that topic, I wonder, the x.org-using BSDs aren’t likely to use evdev scancodes either since that’s strictly a Linux thing. Having a layout available for both is necessary anyway.

Menno dixit:

@mirabilos Could you tell us if your layouts should still resolve this @issue?

My layout maps scancode to keysym. Applications should use only keysyms whenever possible, and only if not, scancodes, but then exclusively them (mixing leads to https://github.com/performous/performous/issues/487 and similar errors). It is just prepared for both:

$ fgrep 0x68 .Xmodmap* .Xmodmap:keycode 0x68 = KP_Enter Return KP_Enter Return .Xmodmap.rdp:keycode 0x68 = Down Down U2193 U21D3

Basically, my normal (on Debian) .Xmodmap maps 104 to Enter, and the RDP one maps it to Down.

For most applications this isn't an issue but things like VNC/java consoles 104 maps to enter making the arrow keys non-functional.

VNC (vncviewer, virt-manager) works just fine under xrdp.

Which Java™ console are you talking about?

[mennozon]

For most applications this isn't an issue but things like VNC/java consoles 104 maps to enter making the arrow keys non-functional. VNC (vncviewer, virt-manager) works just fine under xrdp. Which Java™ console are you talking about?

When using the web interface of VMware ESXi and Proxmox VE the console of the VMs show this issue, I'm not really sure what vmware uses for their console but I know Proxmox uses novnc. I mentioned java as I remember having this issue with HP iLO as well when using Java for remote console, even with newer iLO versions (4 and 5) that have a html5 console show this behavior.

I only recently found out that when using a vnc session in xrdp this issue is not present, I was hoping this might be a clue in resolving this.

[mirabilos]

Hi Menno,

these things you listed are all proprietary products, so we cannot just look into their source code for hints. But it enables you to ask their authors, as paying customer, for a bugfix.

[mennozon]

Actually, Proxmox VE is opensource, they use novnc (found here.) but I wasn't able to make out how they handle keyboard from there.

[mennozon]

Thanks guys, I was able to figure out some more things but I'm not sure how to resolve the following.

I was able to reproduce this with the latest noVNC git version but I don't know how this will help me, things like older versions of iLO and other proprietary products will never be fixed anyway.

So I was trying to figure out the differences between and xorgxrdp and xvnc session and it seems when using a VNC sessions the keyboard driver is evdev instead of xfree86. I've changed xorgxrdp's keyboard driver to match evdev's keysym mappings.

The keysyms are now correct but the keycodes are still wrong, could you point me in the correct direction on where I can change this?

Only thing I want to change now it that pressing the down key generates keycode 116 instead of 104.

@jsorg71 You mentioned working on xorgxrdp evdev a few years ago, are there any sources online that I could review?

[jsorg71]

@mennozon You can look at the X11rdp keyboard code here https://github.com/neutrinolabs/x11rdp/blob/devel/X11R7.6/rdp/rdpkeyboardevdev.c. Basically, you need ti change the switch statement. X11rdp proceeds the Xorg driver so we didn't bring all the code over. I do remember some problem. I think is was when changing the keymap for different languages. The basic rules worked better then evdev for this. X11rdp is based on a pretty old Xorg code base so it may not be a problem anymore.

[lostmsu]

Heads up, I believe I am facing this on NixOS with xrdp + Plasma on Wayland: https://github.com/NixOS/nixpkgs/issues/319356 (client is Windows 11 mstcs)

xev from nix-shell -p xorg.xev reports Arrow Down as keycode 104, KP_Enter and essentially all programs treat it as such

setxkbmap -query prints:

WARNING: Running setxkbmap against an Xwayland server
rules: evdev
model: pc105
layout: us

[matt335672]

@lostmsu - we don't support Wayland. You must be connecting to some sort of X server for your session. Apologies if you're aware of all this, but it's not clear to me from your brief description (especially for those of us who don't use NixOS) exactly what you're telling us.

Keycode 104 is <DOWN> in the base keymap (see /usr/share/X11/xkb/keycodes/xfree86) and <KPEN> in the evdev keymap (see /usr/share/X11/xkb/keycodes/evdev)

If you're using the VNC backend you shouldn't be having this problem. This is sort-of confirmed as the login screen appears to be OK. I'll assume you're using xorgxrdp.

xorgxrdp is hard-coded to expect a "base" keymap at present. I'm currently working to remove this restriction but I'm not there yet.

What does setxkbmap -query tell you from within the XRDP session? It shouldn't report an Xwayland server! I suspect something's set evdev rules, so you might want to try using setxkbmap -rules base -model pc105 -layout us to set it back.

[minhng99]

I'm having this exact issue (the Down Arrow key become Enter key), my OS is the older version so it did not have the latest patch yet. But weirdly it only seems to affect chrome and firefox and only in certain cases where the website grabs the keyboard (like various keyboard test sites) which also happen whenever I need to access a remote server's VNC, it doesn't seem to affect anything else.

Is there somehow I can workaround it?

[mirabilos]

Nguyen Quang Minh dixit:

I'm having this exact issue (the Down Arrow key become Enter key), my OS is the older version so it did not have the latest patch yet.

Is there somehow I can workaround it?

On the remote system, try 'setxkbmap us' (or whatever your desired layout is).

If that does not help, obtain a .Xmodmap for a system that does NOT yet use evdev, such as older BSD with XFree86, or pre-wheezy Debian with X.org, for example by running X on such a system, using setxkbmap to set your desired layout, then using 'xmodmap -pke' to dump the map. Then load that on your RDP session.

Good luck!

PS: for a quick test, you can take my ready-made Xmodmap, but its layout differs a bit from stock US (mostly in that ` and Escape are swapped, and the left Alt key is used for umlauts, so either use the right one or the left Win key for Alt in key combinations; note ~ and Shift-Esc are NOT swapped). You can get it from the download link at: https://mbsd.evolvis.org/cvs.cgi/contrib/samples/dot.Xmodmap?rev=HEAD

I save it as ~/.Xmodmap.rdp so it’s not autoloaded for local logins. Then, when I use xrdp to connect, first thing I do is open an xterm and run 'xmodmap .Xmodmap.rdp', after which the ↓ key and others work fine again.

bye, //mirabilos -- 15:39⎜«mika:#grml» mira|AO: "mit XFree86® wär’ das nicht passiert" - muhaha 15:48⎜<thkoehler:#grml> also warum machen die xorg Jungs eigentlich alles kaputt? :) 15:49⎜<novoid:#grml> thkoehler: weil sie als Kinder nie den gebauten Turm selber umschmeissen durften? -- ~/.Xmodmap wonders…

[minhng99]

@mirabilos

Hi, appreciated for your help, but that key mapping did not seem to change any behavior. Is this an issue of the key mapping in particular? why does it only happen when the keyboard is grabbed by a website, otherwise any kind of scrolling is working correctly.

I don't know where I can even start to debug this issue, is there somehow i can export my current keyboard mapping and just remap that particular down-arrow key? I really need that one

edit:

I've tried to using this script in my browser console to grab the key event:

document.addEventListener('keydown', function(event) {
    console.log('Key pressed:', event.key, ' | Key code:', event.keyCode);
});

It is correctly showing as ArrowDown but for some reason, the keyboard test site still shows it as Enter, it's so strange...

[mirabilos]

Nguyen Quang Minh dixit:

why does it only happen when the keyboard is grabbed by a website, otherwise any kind of scrolling is working correctly.

Ah!

That’s probably the same as when you use an SDL game or a VNC client over an xrdp session: the application uses the scancodes then, but it doesn’t get told the right ones so it back-translates them from the keymap, which is doomed to such failures.

In that case, there is no workaround, sadly.

[matt335672]

I agree with that assessment.

@minhng99 - if you're in a position to compile the devel versions of xrdp and xorgrdp you'll find this should work now (which is why this is closed!) You may of course encounter other problems.