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 performous/performous#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: NixOS/nixpkgs#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.