XRDP Keyboard evdev support?
mhoffmann75 opened this issue · 13 comments
Is it possible to switch XRDP to evdev keyboard rules or at least make it compatible?
All ubuntu 20.04 flavors (gnome, xfce, ...) seem to use 'evdev' keyboards:
setxkbmap -query -v
Trying to build keymap using the following components:
keycodes: evdev+aliases(qwertz)
types: complete
compat: complete
symbols: pc+de+inet(evdev)
geometry: pc(pc105)
rules: evdev
model: pc105
layout: de
However when i connect to this same machines via XRDP i get a 'base' rule with a 'xfree86' setting:
setxkbmap -query -v
Trying to build keymap using the following components:
keycodes: xfree86+aliases(qwertz)
types: complete
compat: complete
symbols: pc+de
geometry: pc(pc104)
rules: base
model: pc104
layout: de
As far as i understand this might be intended to make it compatible for Xvnc sessions. However i don't use Xvnc sessions as i connect to Xorg sessions via xorgxrdp extensions.
So, how can i switch XRDP to evdev to make it behave exactly like it does on the X console?
My problem arises with certain applications (mostly remote consoles) that do work on the machine's X console as intended but having keyboard issues when i access my machine via XRDP. They all suffer the same problem of ignoring alt-gr keys (german keyboard @, , ...) and actually no cursor keys - only cursor-down seems to be enter.
The same effect appears if i switch keyboard to 'evdev' in running XRDP session via setxkbmap -rules evdev
Then all applications have this same problem. So it seems to me that these applications won't play with 'base' mode but need 'evdev' rules?
So question is, what can be done to make XRDP play with 'evdev' rules. I tried this on ubuntu 20.04, xubuntu20.04 with xrdp 0.9.12 (ubuntu repos) and 0.9.18 built from source - all the same. Any ideas?
Is this a bug or a limitation of the current implementation?
neutrinolabs/xrdp#179 seems to imply that there is a way to switch to evdev rules (breaking Xvnc - but that would be ok for me) but it does not tell what needs to be done to achieve this. As this is quite old i'm not sure if it still applies.
I'm going to move this to the xorgxrdp repository, as I think it's more relevant there.
Hi @mhoffmann75
First of all, I must stress this isn't an area I know much about at all. This information may not be that useful, or maybe there's a better way to do this.
The xorgxrdp driver (unsurprisingly) includes a keyboard driver. As part of this driver the rules set to use for the keyboard is specified. It appears to me to be hard-coded to "base". If there is a way to override it via options I haven't found it yet.
If I apply this patch to xorgxrdp:-
diff --git a/xrdpkeyb/rdpKeyboard.c b/xrdpkeyb/rdpKeyboard.c
index 4061b53..f2491ca 100644
--- a/xrdpkeyb/rdpKeyboard.c
+++ b/xrdpkeyb/rdpKeyboard.c
@@ -82,7 +82,7 @@ xrdp keyboard module
#define N_PREDEFINED_KEYS \
(sizeof(g_kbdMap) / (sizeof(KeySym) * GLYPHS_PER_KEY))
-static char g_base_str[] = "base";
+static char g_base_str[] = "evdev";
static char g_pc104_str[] = "pc104";
static char g_us_str[] = "us";
static char g_empty_str[] = "";I get the following in my xrdp session:-
$ setxkbmap -query -v
Trying to build keymap using the following components:
keycodes: evdev+aliases(qwerty)
types: complete
compat: complete
symbols: pc+gb+gb:2+inet(evdev)
geometry: pc(pc104)
rules: evdev
model: pc104
layout: gb,gb
variant: ,
With a UK keyboard I can't tell any difference in the mappings. A UK keyboard is really not very interesting though, compared to all the other keyboards out there. Maybe that is the same for you as well, but it's probably worth a try.
Changing this in rdpKeyboard.c does indeed make the XRDP session come up with evdev keyboard instead of xfree86 base. But it instantly suffers from exactly the same special-character and cursor key problems that i had before with certain apps and switching to evdev on the fly via setxkbmap -rules evdev. So its good to know that with this patch the start keyboard can be defined but unfortunately it does not solve my problem.
Thanks for the update.
As I said, it's not an area I'm at all familiar with.
The RDP client sends a keyboardLayout type over to the server during the initial connection setup. It might be worth checking this is correct, before X even gets involved.
Again, with my UK keyboard, I get messages like the following in /var/log/xrdp.log during an initial connection on a recent build:-
[20220318-14:27:18] [INFO ] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x04], keyboard_subtype:[0x00], keylayout:[0x00000809]
[20220318-14:27:18] [INFO ] xrdp_load_keyboard_layout: model [] variant [] layout [gb] options []
- Do you get similar messages? If so, what are they?
- Does the keyboard appear to be working on the xrdp login screen, as far as you can tell?
I have changed the key codes and type in the rdpKeyboard.c accordingly to https://github.com/neutrinolabs/x11rdp/blob/devel/X11R7.6/rdp/rdpkeyboardevdev.c
This seems to work for german keyboard from windows and mac os quite well. All keys seems to behave as expected and for all apps i was able to test.
See my changes here: mhoffmann75@16b8fbd
I guess this needs a lot more testing for different keyboards and languages.
However this change would still break xorgxrdp support for non-evdev systems, so we might need some configure option to support both?
That's interesting, but somewhat out of my knowledge to comment on I'm afraid.
Have you had a chance to look in /var/log/xrdp.log above? Any additional knowledge at this point would be useful.
Thanks.
Yes, i did check xrdp.log.
All i could find is a warning, which i think can be interpreted as "info" as it tells me that it loads the file which is there from the ubuntu deb:
[WARN ] local keymap file for 0x00000407 found and doesn't match built in keymap, using local keymap file
So this is OK to me.
Some rdp client software seems to negotiate a keyboard, which seems reasonable to me:
[20220318-17:05:12] [INFO ] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x04], keyboard_subtype:[0x00], keylayout:[0x00000407]
[20220318-17:05:12] [INFO ] xrdp_load_keyboard_layout: model [] variant [] layout [de] options []
...
[20220318-17:05:12] [INFO ] Loading keymap file /etc/xrdp/km-00000407.ini
[20220318-17:05:12] [WARN ] local keymap file for 0x00000407 found and doesn't match built in keymap, using local keymap file
I will test some more with the changes i made and report back.
Something else to throw into the mix for you - the /etc/xrdp/km-00000407.ini file comes from the genkeymap/xrdp-genkeymap utility. km00000407.ini is stored in git under instfiles/, as it needs an X server to generate it.
I just ran genkeymap/dump-keymaps.sh on an Ubuntu 20.04 X server. The file I get in instfiles/km-00000407.ini is somewhat different from the released one.
Have a look at neutrinolabs/xrdp#180. It references neutrinolabs/xrdp#179 which you mention above, and may be responsible for the differences.
In other words, on your system, it may be worth regenerating /etc/xrdp/km-00000407.ini to see what happens.
Thanks for pointing that out, but I had tried generating new keymap files while on evdev before but it did not change anything for me. I will take a closer look to find the actual differences.
Hello.
I have recently received a report from a CentOS server user I administer that
When logging in with Xorg, they reported that when they pressed the cursor key down, Enter was typed.
On closer inspection, the problem was not identified in GNOME applications.
The event occurred when logging into the HPE ProLiant's iLO5 Web-UI from FireFox and launching the HTML5 remote console.
The cursor keys as well as incert/home/PageUp/PageDown/Enter on the Key Pad etc. were not the expected key inputs.
Further investigation showed that the same was true when launching the virtual machine's web console via VMware ESXi 6.7's web-UI and logging into the GNOME desktop.
The situation suggests that the problem only occurs in applications that refer directly to scancode and not Keysym.
The situation is similar to issue #355.
I applied the patch created @mhoffmann75 to xorgxrdp ver 0.9.19.
The cursor keys now work correctly in applications that refer directly to the X11 scancode.
However, some keys specific to the Japanese JP106/109 keyboard did not work: backslash, pipe, underscore and other important keys for shell operations were not available, so I modified the patch for Japanese JP106/109 keyboards.
So far it works fine.
I noticed in the process of creating the patch that the keyboard "/ ?
BR keyboard "/ ? " key and the JP keyboard "" key were in the same RDP scancode 113.
This suggests that one code cannot follow all languages/keyboards.
I thought that xorgxrdp also needs a mechanism to judge the language and keyboard type and switch the X11 scancode.
At the same time, switching the input driver from base to evdev could also have a significant impact on users worldwide.
I thought it would be necessary to add an input_driver parameter to the Xorg section of xrdp.ini, which would use base by default and switch to evdev if necessary.
Is there a workaround that does not involve patching sources?
@lostmsu - for now, stick for base rules for xrdp, or use the VNC backend. There are limitations to this - media keys won't work, and applications with hard-coded X11 keycodes won't work either.
I'm working in this area currently, so I'm hoping something will land in devel fairly soon.