Partially unexpected key mapping in secondary wlroots WM #3050

CaptainBloodz · 2024-04-28T17:58:36Z

xrdp version

0.10.80

Detailed xrdp version, build options

xrdp --version
xrdp 0.10.80
  A Remote Desktop Protocol Server.
  Copyright (C) 2004-2024 Jay Sorg, Neutrino Labs, and all contributors.
  See https://github.com/neutrinolabs/xrdp for more information.

  Configure options:
      --prefix=/usr
      --build=x86_64-pc-linux-gnu
      --host=x86_64-pc-linux-gnu
      --mandir=/usr/share/man
      --infodir=/usr/share/info
      --datadir=/usr/share
      --sysconfdir=/etc
      --localstatedir=/var/lib
      --disable-dependency-tracking
      --disable-silent-rules
      --docdir=/usr/share/doc/xrdp-9999
      --htmldir=/usr/share/doc/xrdp-9999/html
      --with-sysroot=/
      --libdir=/usr/lib64
      --localstatedir=/var
      --enable-pam
      --disable-kerberos
      --enable-jpeg
      --enable-tjpeg
      --disable-debug-all
      --disable-fuse
      --disable-ipv6
      --disable-neutrinordp
      --enable-vsock
      --disable-xrdpvr
      --with-systemdsystemunitdir=/lib/systemd/system
      build_alias=x86_64-pc-linux-gnu
      host_alias=x86_64-pc-linux-gnu
      CFLAGS=-march=native -mtune=native -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -pipe -Wa,-mbranches-within-32B-boundaries 
      LDFLAGS=-Wl,-O1 -Wl,-fuse-ld=bfd 
      CXXFLAGS=-march=native -mtune=native -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -pipe -Wa,-mbranches-within-32B-boundaries 

  Compiled with OpenSSL 3.0.13 30 Jan 2024

Operating system & version

PRETTY_NAME="Gentoo Linux"

Installation method

other

Which backend do you use?

xorgxrdp

What desktop environment do you use?

lxde/openbox

Environment xrdp running on

skylake iGP

What's your client?

remmina

Area(s) with issue?

Other

Steps to reproduce

Using xev while running any secondary wlroots WM (sway,labwc,hyprland) with with pc104 defined keyboard.

✔️ Expected Behavior

Proper key mapping

❌ Actual Behavior

Most keys between alpha block and numpad block have unexpected values as listed below:

up arrow:
detected:
keycode 98 (keysym 0xff26, Katakana)
expected:
keycode 98 (keysym 0xff52, Up)

left arrow:
detected:
keycode 100 (keysym 0xff23, Henkan_Mode)
expected:
keycode 100 (keysym 0xff51, Left)

right arrow:
detected:
keycode 102 (keysym 0xff22, Muhenkan)
expected:
keycode 102 (keysym 0xff53, Right)

down arrow:
detected:
keycode 104 (keysym 0xff8d, KP_Enter)
expected:
keycode 104 (keysym 0xff54, Down)

insert
detected:
keycode 106 (keysym 0xffaf, KP_Divide)
expected:
keycode 106 (keysym 0xff63, Insert)

del
detected:
Can't capture, add light to the screen
expected:
state 0x10, keycode 107 (keysym 0xffff, Delete)

pgdown
detected:
keycode 105 (keysym 0xffe4, Control_R)
expected:
keycode 105 (keysym 0xff56, Next)

pgup
detected:
keycode 99 (keysym 0xff25, Hiragana)
expected:
keycode 99 (keysym 0xff55, Prior)

home
detected:
keycode 97 (keysym 0x0, NoSymbol)
expected:
keycode 97 (keysym 0xff50, Home)

end
detected:
keycode 103 (keysym 0x0, NoSymbol)
expected:
keycode 103 (keysym 0xff57, End)

printscreen/sysreq
detected:
keycode 111 (keysym 0xff52, Up)
expected:
keycode 111 (keysym 0xff61, Print)

scrolllock
detected:
keycode 78 (keysym 0xff14, Scroll_Lock)
expected:
keycode 78 (keysym 0xff14, Scroll_Lock)

pause/break
detected:
keycode 110 (keysym 0xff50, Home) in repeated mode
expected:
keycode 110 (keysym 0xff6b, Break)

Anything else?

Reported faulty keys are working fine in xrdp/x11 primary WM.
Working fine too when running wlroot WM as primary, i.e. no xrdp.

The text was updated successfully, but these errors were encountered:

matt335672 · 2024-04-29T09:40:53Z

Welcome back @CaptainBloodz.

Interesting problem.

The way this currently works is that xorgxrdp translates the RDP scancodes into "base" X11 keycodes. These are then mapped to keysyms using the normal X11 mechanisms.

xorgxrdp needs to be told what the XKB model and layout are for this to work properly. This bit may be going wrong.

What do you get for the following commands?

sudo grep load_keyboard_layout /var/log/xrdp.log ?
(In wlroot, no xrdp) setxkbmap -query -v
(In wlroot, xrdp) setxkbmap -query -v

piovisqui · 2024-05-17T21:29:36Z

I have the same problem with Rocky Linux 9.4. The OS is running inside HyperV and I connected using mstsc. If I connect with HyperV console the keyboard works.

rpm -qa | grep xrdp
xrdp-selinux-0.9.25-2.el9.x86_64
xrdp-0.9.25-2.el9.x86_64
xorgxrdp-0.9.20-1.el9.x86_64

The down arrow gives ENTER
Left, up and right arrow gives nothing
Insert gives slash '/'

I have the same weird key codes as the previous user:

xev | sed -n 's/^.*state \([0-9].*\), keycode *\([0-9]\+\) *\(.*\), .*$/keycode \2 = \3, state = \1/p'
keycode 100 = (keysym 0xff23, Henkan_Mode), state = 0x0
keycode 100 = (keysym 0xff23, Henkan_Mode), state = 0x0
keycode 98 = (keysym 0xff26, Katakana), state = 0x0
keycode 98 = (keysym 0xff26, Katakana), state = 0x0
keycode 102 = (keysym 0xff22, Muhenkan), state = 0x0
keycode 102 = (keysym 0xff22, Muhenkan), state = 0x0
keycode 104 = (keysym 0xff8d, KP_Enter), state = 0x0
keycode 104 = (keysym 0xff8d, KP_Enter), state = 0x0
keycode 106 = (keysym 0xffaf, KP_Divide), state = 0x0
keycode 106 = (keysym 0xffaf, KP_Divide), state = 0x0

The above log is for the arrow keys and Insert.

sudo grep load_keyboard_layout /var/log/xrdp.log
20240517-17:51:26] [INFO ] xrdp_load_keyboard_layout: model [] variant [] layout [us] options []
[20240517-18:08:22] [INFO ] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x04], keyboard_subtype:[0x00], keylayout:[0x00010416]
[20240517-18:08:22] [INFO ] xrdp_load_keyboard_layout: model [] variant [] layout [us] options []
[20240517-18:15:32] [INFO ] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x04], keyboard_subtype:[0x00], keylayout:[0x00010416]
[20240517-18:15:32] [INFO ] xrdp_load_keyboard_layout: model [] variant [] layout [us] options []

Inside the RDP

setxkbmap -query -v
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+br+inet(evdev)+level3(ralt_switch)
geometry:   pc(pc105)
rules:      evdev
model:      pc105
layout:     br
options:    lv3:ralt_switch

Inside the console:

setxkbmap -query -v
Trying to build keymap using the following components:
keycodes:   evdev+aliases(qwerty)
types:      complete
compat:     complete
symbols:    pc+br+inet(evdev)
geometry:   pc(pc105)
rules:      evdev
model:      pc105
layout:     br
options:    lv3:ralt_switch

matt335672 · 2024-05-20T13:11:54Z

@piovisqui - can you confirm you're using the VNC backend (since you're on Rocky)?

Thanks.

piovisqui · 2024-05-21T17:48:37Z

Do you mean what's configured in SessionType?

[Xvnc]
name=Xvnc
lib=libvnc.so
username=ask
password=ask
ip=127.0.0.1
port=-1

matt335672 · 2024-05-22T10:38:14Z

Sorry - fat fingers.

Yes, that's fine.

At the moment, I don't think your issue is not the same as the OP's issue - @CaptainBloodz is using a development version of xrdp and also isn't using VNC. I could be wrong though, so let's dig down a little.

Since you're using VNC, this may be fixable by generating (or regenerating) your key mapping file.

Can you tell me what you get for this command :-

sudo grep keymap /var/log/xrdp.log

I'm pretty sure from what you've said that the keymap code you should be trying to load is 00000416 for Brazilian Portuguese, but maybe something else is going on here.

piovisqui · 2024-05-22T14:54:20Z

The log:

[root@localhost ~]# grep keymap /var/log/xrdp.log | tail
[20240517-17:51:26] [INFO ] Loading keymap file /etc/xrdp/km-00010416.ini
[20240517-17:51:26] [WARN ] local keymap file for 0x00010416 found and doesn't match built in keymap, using local keymap file
[20240517-18:08:22] [INFO ] Loading keymap file /etc/xrdp/km-00010416.ini
[20240517-18:08:22] [WARN ] local keymap file for 0x00010416 found and doesn't match built in keymap, using local keymap file
[20240517-18:15:32] [INFO ] Loading keymap file /etc/xrdp/km-00010416.ini
[20240517-18:15:32] [WARN ] local keymap file for 0x00010416 found and doesn't match built in keymap, using local keymap file
[20240522-10:42:42] [INFO ] Loading keymap file /etc/xrdp/km-00010416.ini
[20240522-10:42:42] [WARN ] local keymap file for 0x00010416 found and doesn't match built in keymap, using local keymap file
[20240522-10:51:03] [INFO ] Loading keymap file /etc/xrdp/km-00010416.ini
[20240522-10:51:03] [WARN ] local keymap file for 0x00010416 found and doesn't match built in keymap, using local keymap file
[root@localhost ~]# ls /etc/xrdp/km*.ini
/etc/xrdp/km-00000406.ini  /etc/xrdp/km-00000410.ini  /etc/xrdp/km-00000419.ini  /etc/xrdp/km-00000813.ini
/etc/xrdp/km-00000407.ini  /etc/xrdp/km-00000411.ini  /etc/xrdp/km-0000041d.ini  /etc/xrdp/km-00000816.ini
/etc/xrdp/km-00000409.ini  /etc/xrdp/km-00000412.ini  /etc/xrdp/km-00000807.ini  /etc/xrdp/km-0000100c.ini
/etc/xrdp/km-0000040a.ini  /etc/xrdp/km-00000414.ini  /etc/xrdp/km-00000809.ini  /etc/xrdp/km-00010409.ini
/etc/xrdp/km-0000040b.ini  /etc/xrdp/km-00000415.ini  /etc/xrdp/km-0000080a.ini  /etc/xrdp/km-00010416.ini
/etc/xrdp/km-0000040c.ini  /etc/xrdp/km-00000416.ini  /etc/xrdp/km-0000080c.ini  /etc/xrdp/km-19360409.ini

I have tried without success:

setxkbmap br
localectl set-keymap br

matt335672 · 2024-05-23T11:10:42Z

The problem is (I think) the missing keymap file.

Here's some background info. This is a complicated area. Please tell me if I'm not explaining it well.

The magic number 0x00010416 is obtained from the RDP client. It identifies your keyboard as "Portuguese (Brazil ABNT2)". See here and here. If your keyboard is not this model, there's a problem with the client which needs to be identified first.

Current versions of XRDP translate incoming RDP scancodes into X11 keycodes using a private table. For a VNC server we then need to generate a VNC key event which requires an X11 KeySym.

This conversion is done by looking up the keycode in one of the shift state tables in /etc/xrdp/km-00010416.ini

Interestingly this file doesn't seem to be part of the standard RPM. This makes me a bit nervous as the origins and nature of this file are unknown.

Could you give us the results of these commands so we can see exactly what we're dealing with?

rpm -qf /etc/xrdp/km-00010416.ini
ls -l /etc/xrdp/km-00010416.ini

Thanks.

piovisqui · 2024-05-23T16:14:24Z

Yes, the keyboard is ABNT2.

Here:

[root@localhost ~]# rpm -qf /etc/xrdp/km-00010416.ini
file /etc/xrdp/km-00010416.ini is not owned by any package
[root@localhost ~]# ls -l /etc/xrdp/km-00010416.ini
-rw-r--r--. 1 root root 9168 May 17 17:12 /etc/xrdp/km-00010416.ini
[root@localhost ~]# ls -l /etc/xrdp/km-00000416.ini
-rw-r--r--. 1 root root 9168 Mar 11 10:46 /etc/xrdp/km-00000416.ini

I've copied the km-00000416.ini into km-00010416.ini and it still did not work.

matt335672 · 2024-05-23T17:55:00Z

Thanks.

Try this to regenerate the file completely using the current X server. We've established that the two X servers we're discussing are broadly compatible.

Log in on the console
Check the keyboard is working properly.

Enter these commands:-

xrdp-genkeymap /tmp/km-00010416.ini
sudo cp /tmp/km-00010416.ini /etc/xrdp/
sudo chmod 644 /etc/xrdp/km-00010416.ini
sudo chown root: /etc/xrdp/km-00010416.ini

Please post the output of ls -l /etc/xrdp/km-00010416.ini for the record.

This might seem a bit pointless, but it isn't. There's an implicit assumption that the same X11 keycodes are used by the keymap generator and the runtime X server - this isn't always the case. I'm working on a way to remove this assumption, but in the meantime we have to work with what we've got.

piovisqui · 2024-05-23T18:18:25Z

I generated the file:
ls -l /etc/xrdp/km-00010416.ini -rw-r--r--. 1 root root 14687 May 23 15:01 /etc/xrdp/km-00010416.ini

Still not fully working.
Some special characters work, like tilde and cedilla ( ~ ç )

This sequence is 0,1,2...9 using the num lock numbers:

xev | sed -n 's/^.*state \([0-9].*\), keycode *\([0-9]\+\) *\(.*\), .*$/keycode \2 = \3, state = \1/p'
keycode 90 = (keysym 0xff9e, KP_Insert), state = 0x0
keycode 90 = (keysym 0xff9e, KP_Insert), state = 0x0
keycode 87 = (keysym 0xff9c, KP_End), state = 0x0
keycode 87 = (keysym 0xff9c, KP_End), state = 0x0
keycode 88 = (keysym 0xff99, KP_Down), state = 0x0
keycode 88 = (keysym 0xff99, KP_Down), state = 0x0
keycode 89 = (keysym 0xff9b, KP_Next), state = 0x0
keycode 89 = (keysym 0xff9b, KP_Next), state = 0x0
keycode 83 = (keysym 0xff96, KP_Left), state = 0x0
keycode 83 = (keysym 0xff96, KP_Left), state = 0x0
keycode 84 = (keysym 0xff9d, KP_Begin), state = 0x0
keycode 84 = (keysym 0xff9d, KP_Begin), state = 0x0
keycode 85 = (keysym 0xff98, KP_Right), state = 0x0
keycode 85 = (keysym 0xff98, KP_Right), state = 0x0
keycode 79 = (keysym 0xff95, KP_Home), state = 0x0
keycode 79 = (keysym 0xff95, KP_Home), state = 0x0
keycode 80 = (keysym 0xff97, KP_Up), state = 0x0
keycode 80 = (keysym 0xff97, KP_Up), state = 0x0
keycode 81 = (keysym 0xff9a, KP_Prior), state = 0x0
keycode 81 = (keysym 0xff9a, KP_Prior), state = 0x0

matt335672 · 2024-05-23T19:30:27Z

It may not seem like it, but that's progress.

I'm sorry this is taking a bit longer than either of us would like. The keyboard mappings haven't been touched for a fair while and they're starting to show it. The good news is this is an area I'm currently trying to improve at present - this level of file hackery should not be necessary.

Let's sort the keypad out.

The reason the keypad isn't working is down to a change in the XKB sub-system which is in your version of CentOS. My notes of it are here if you're interested.

I think you can reasonably address this by

Take a copy of your new /etc/xrdp/km-00010416.ini for safety.
Edit /etc/xrdp/km-00010416.ini (not the copy). Scroll down and find the [shift] section.
Within the [shift] section find the definitions for keys 79-91.

Replace the generated definitions with these:-

Key79=65463:55
Key80=65464:56
Key81=65465:57
Key82=65453:45
Key83=65460:52
Key84=65461:53
Key85=65462:54
Key86=65451:43
Key87=65457:49
Key88=65458:50
Key89=65459:51
Key90=65456:48
Key91=65454:46

Here's an example; you can see from your last response that keypad 0 is Key90. The change above should cause key 90 to generate KeySym 65456 ( i.e. 0xffb0, or XK_KP_0) and character 48 (i.e. ASCII '0') when either shift is pressed, or numlock is active.

Please come back to me and let me know how it goes. I'm about to sign off for the day but I should have time to address your reply tomorrow.

piovisqui · 2024-05-23T19:52:35Z

The number pad is working after I changed what you said. Thank you.

I have more info that I should have said sine the beginning.

I also run Kali and when using the HyperV console I have these options:

I believe this means the xrdp is working properly and out of the box. Instead of using the HyperV console we are automatically switched to a RDP session after clicking 'OK'.

dpkg -l | egrep "xrdp|vnc"
ii pipewire-module-xrdp 0.0~git20230609.e9c6c05-0kali1
ii python3-pyvnc 0.1-0kali4
ii tightvncpasswd 1:1.3.10-7
ii tightvncserver 1:1.3.10-7
ii xorgxrdp 1:0.9.19-1
ii xrdp 0.9.24-3
ii xtightvncviewer 1:1.3.10-7

matt335672 · 2024-05-24T09:35:05Z

I'm glad we've got the keypad sorted out.

As regards the rest of your comment:-

I don't think xrdp is at all related to the Kali console. Try disabling the xrdp.service and see if it makes any difference.
Kali uses the xorgxrdp backend by default. The key mapping files are used on the logon screen, but not by the session.

piovisqui · 2024-05-24T13:32:33Z

It's not the default HyperV console, however if you mark "Enhanced session" it does use xrdp. If I do "systemctl stop xrdp" the console crashes.

matt335672 · 2024-05-24T15:23:36Z

OK - thanks for that. It's a feature I knew nothing about.

Is there anything outstanding on the Rocky keyboard?

CaptainBloodz added the bug label Apr 28, 2024

CaptainBloodz changed the title ~~Partially unexpected key mapping~~ Partially unexpected key mapping in secondary wlroots WM Apr 28, 2024

matt335672 closed this as completed May 22, 2024

matt335672 reopened this May 22, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Partially unexpected key mapping in secondary wlroots WM #3050

Partially unexpected key mapping in secondary wlroots WM #3050

CaptainBloodz commented Apr 28, 2024

matt335672 commented Apr 29, 2024

piovisqui commented May 17, 2024

matt335672 commented May 20, 2024

piovisqui commented May 21, 2024

matt335672 commented May 22, 2024

piovisqui commented May 22, 2024 •

edited

matt335672 commented May 23, 2024

piovisqui commented May 23, 2024 •

edited by matt335672

matt335672 commented May 23, 2024

piovisqui commented May 23, 2024

matt335672 commented May 23, 2024

piovisqui commented May 23, 2024 •

edited by matt335672

matt335672 commented May 24, 2024

piovisqui commented May 24, 2024

matt335672 commented May 24, 2024

Partially unexpected key mapping in secondary wlroots WM #3050

Partially unexpected key mapping in secondary wlroots WM #3050

Comments

CaptainBloodz commented Apr 28, 2024

xrdp version

Detailed xrdp version, build options

Operating system & version

Installation method

Which backend do you use?

What desktop environment do you use?

Environment xrdp running on

What's your client?

Area(s) with issue?

Steps to reproduce

✔️ Expected Behavior

❌ Actual Behavior

Anything else?

matt335672 commented Apr 29, 2024

piovisqui commented May 17, 2024

matt335672 commented May 20, 2024

piovisqui commented May 21, 2024

matt335672 commented May 22, 2024

piovisqui commented May 22, 2024 • edited

matt335672 commented May 23, 2024

piovisqui commented May 23, 2024 • edited by matt335672

matt335672 commented May 23, 2024

piovisqui commented May 23, 2024

matt335672 commented May 23, 2024

piovisqui commented May 23, 2024 • edited by matt335672

matt335672 commented May 24, 2024

piovisqui commented May 24, 2024

matt335672 commented May 24, 2024

piovisqui commented May 22, 2024 •

edited

piovisqui commented May 23, 2024 •

edited by matt335672

piovisqui commented May 23, 2024 •

edited by matt335672