Weird behaviour with the Fn key in Ubuntu 22.04

[AndreasNasman]

I've noticed some strange behavior with the Fn key when using xrdp in Ubuntu 22.04.

When pressing the Fn key, it's interpreted as a Delete key. This can be viewed in View Keyboard Layout; here I'm pressing down the Fn key and the Delete key lights up:

This issue isn't that major, but it's quite odd, and it can cause some occasional confusion when clicking the Fn key.

Xrdp version: 0.9.17-2ubuntu2
Ubuntu version: 22.04

Windows specs:
Edition: Windows 10 Pro
Version: 21H2
OS build: 19044.1620
Experience: Windows Feature Experience Pack 120.2212.4170.0

PC specs:
Model: ThinkPad P14s Gen 2a
BIOS version: R1MET45W 1.15

[matt335672]

Hi @AndreasNasman

What do you get for the following command:-

sudo grep -E '(keyboard)|(keymap)' /var/log/xrdp.log

we'll try to figure out what keyboard your client is sending over.

I take it everything is OK on the Windows 10 side with the keyboard?

[AndreasNasman]

Hi!

Here's the output of the grep:

$ sudo grep -E '(keyboard)|(keymap)' /var/log/xrdp.log
[20220404-18:00:29] [INFO ] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x04], keyboard_subtype:[0x00], keylayout:[0x00000409]
[20220404-18:00:29] [INFO ] xrdp_load_keyboard_layout: model [] variant [] layout [us] options []
[20220404-18:00:29] [INFO ] Loading keymap file /etc/xrdp/km-00000409.ini
[20220404-18:00:29] [WARN ] local keymap file for 0x00000409 found and doesn't match built in keymap, using local keymap file

With this test, my host (Windows) language and keyboard layout are set to English (US) and everything works fine there, including the Fn key.

Could the last warning have anything to do with the issue I'm having?

[WARN ] local keymap file for 0x00000409 found and doesn't match built in keymap, using local keymap file

[matt335672]

No, that's fine.

Can you explain your unedited post, where you have this line:-

[20220404-17:48:40] [INFO ] xrdp_load_keyboard_layout: Keyboard information sent by the RDP client, keyboard_type:[0x2110110], keyboard_subtype:[0x02], keylayout:[0xA0000409]

The '0xA0000409' is not something I can see in the MS keyboard identifier list here. It suggests your keyboard is other than completely standard, but I'm afraid I don't know what.

0x00000409 maps to a standard US English keyboard.

[AndreasNasman]

I use EurKey by default, forgot to change it before doing the test. 🙂 The edited post is with English (US) as the layout and the Fn key behaves as Delete in Ubuntu still.

[AndreasNasman]

Can I somehow log what the Fn key is interpreted as on the Ubuntu side?

[matt335672]

You can use the xev utility to see what scancode the Fn key is being interpreted as.

As I correct in thinking this key is an extra key to a standard keyboard? I've got a full-size UK keyboard in front of me here, and it has no Fn key. On an Acer laptop I user for testing, there's an Fn key, but it doesn't generate a keypress that xev can see.

What do you want the Fn key to do when it's pressed in Ubuntu?

[AndreasNasman]

You can use the xev utility to see what scancode the Fn key is being interpreted as.

Here are the result from running xev and repeatedly pressing the Fn key.

First with Xrdp. As you can see, it's interpreted as a Delete keystroke:

Next, running the VM straight with Hyper-V. Not sure how its interpreted, but it's not a Delete key:

As I correct in thinking this key is an extra key to a standard keyboard? I've got a full-size UK keyboard in front of me here, and it has no Fn key. On an Acer laptop I user for testing, there's an Fn key, but it doesn't generate a keypress that xev can see.

It's the Fn key of a ThinkPad P14s Gen 2a laptop, with a Nordic keyboard layout:

What do you want the Fn key to do when it's pressed in Ubuntu?

Nothing, really; I want similar behavior as connecting to the VM with Hyper-V (see picture above).

Here's an example where the Fn key behaving as Delete is an issue. At work, I have a keyboard that's missing the Home key. To simulate it, I press Fn + ⬅️. Say I want to copy some text from Ubuntu to Windows. I highlight the word, copy it, and navigate to Windows with the keyboard. To do that, I would press Ctrl + Alt + Home, although I have no Home key, so the shortcut is then Ctrl + Alt + Fn + ⬅️. I forgot to un-highlight the text, and the Delete key event from the Fn key deletes the text in Ubuntu as I'm moved over to Windows.

It's not a major issue by any means, just an annoyance that I don't understand why it's happening.

Xrdp otherwise seems like a more appealing environment, enabling Enhanced mode in Hyper-V. The only issues so far I've found are this one and #2092.

[matt335672]

Can you use xev to see what the keycode is for delete?

At a technical level, there's a lot of indirection going on here. The RDP protocol uses virtual scan codes to represent keys. These are converted in xrdp to X11 keycodes in xrdp/lang.c using a hard-coded table. The X server, whichever one we're using then maps those keycodes to an actual input data stream.

Esentially, if you're getting a different keycode for the delete key and the Fn key we can do something at the xrdp level. If they are the same, you'll need to figure out a way to change the virtual scan code which is getting passed over the link.

[AndreasNasman]

I see! Thanks for the explanation!

The Delete key seems to give the exact output as pressing the Fn key. Here I spam the Delete key:

If they are the same, you'll need to figure out a way to change the virtual scan code which is getting passed over the link.

I guess this is the next step then? 🙂

[matt335672]

Indeed.

That'll be down to something in the Windows settings, or possibly the BIOS. By the time the code gets to us, there's not a lot we can do I'm afraid.

[AndreasNasman]

Yeah. I mean it works in Windows and when I launch the VM in Hyper-V so not really sure where to change things when the Fn key works otherwise. The issue is quite minor anyway, so I think I'll just drop it.

Thanks for the help and explanations! ❤️

[dpzimmer]

Indeed.

That'll be down to something in the Windows settings, or possibly the BIOS. By the time the code gets to us, there's not a lot we can do I'm afraid.

How is that possible that windows RDP client sends a delete keypress when the 'Fn' key is pressed when connected to an XRDP server, but not when connected to a native Windows server? Is is possible that the keypress is fundamentally misinterpreted at the server end? The whole thing is clear as mud to me, because I would expect that the 'Fn' key would be interpreted only on the client hardware/OS and not forwarded as a keypress at all.

Contrary to the OP opinion, processing an unwanted 'delete' keypress IS a big deal. 'Fn' keys are found on most laptops without full size keyboards.

[matt335672]

@dpzimmer - you make some good points. Thanks for that.

Are you also experiencing this issue? If so, what kind of keyboard do you have and what is the layout? I'll need to try to reproduce this using a soft keyboard I think.

[dpzimmer]

@dpzimmer - you make some good points. Thanks for that.

Are you also experiencing this issue? If so, what kind of keyboard do you have and what is the layout? I'll need to try to reproduce this using a soft keyboard I think.

Hi Matt,

Yes, I am experiencing literally the exact same behavior as Andreas.

My system is "Lenovo ThinkPad T14 Gen 3" running "Windows 11 Pro 22H2". The keyboard layout is attached.

I am connecting to "Ubuntu 23.04" as well as other slightly less recent Ubuntu versions, all experiencing the same issue.

Thanks,
Don.

[matt335672]

@dpzimmer, @AndreasNasman

I've connected my laptop with an Fn key up to and xrdp server. I can see keyboard events for key presses in the xrdp_fastpath_process_input_event() function. When I press the Fn key however, no message at all is being received from the Windows side.

This stackoverflow article suggests there is no scancode for the Fn key:-
https://stackoverflow.com/questions/24423724/what-is-the-key-scan-code-of-the-fn-key-for-use-in-autohotkey-ahk

I've also tried running these utilities:-

• Passmark Keyboard Test Utility. This shows the Fn key as being untestable.
• sharpkeys does not react at all when the Fn key is pressed.

I don't understand why your laptops are behaving differently. This may be Lenovo-specific functionality. I've done some looking around without huge amounts of success. Ther's this webpage for example, which suggests there may be a BIOS setting to change the operation of this key:-

https://gadgetsfeed.com/how-to-disable-fn-key-on-lenovo-laptop/

I also found some refernces to an FnLock key which certainly @dpzimmer does not have. Try pressing Fn+ ESC and see if the operation of the Fn key changes.

By all means investigate further using the utilities and links above. I don't have the hardware to take this any further, but it's certainly an interesting topic.

[matt335672]

I've had a bit more of a think about this; the behaviour you're both seeing must be caused by the xrdp server receiving a scancode when the Fn key is pressed.

It would be very useful indeed if either of you is able to install one of the utilities above on your systems and see if you can get a scancode from the Fn key. If there is one, and if it's being sent over the RDP link I can trace it through the keyboard logic on the server side.

[dpzimmer]

Hi Matt,

Regarding "Try pressing Fn+ ESC and see if the operation of the Fn key changes.", It toggles the FnLock state, but no change in behaviour when pressing the Fn key alone.

Following up with the tools you suggested, and one more online tool (images below), it seems that a keycode of 0xFF (not a valid code) is forwarded, which would match against anything if your are using bitwise AND at the receiving end.

[matt335672]

Thanks for the swift reply @dpzimmer

The scancode used by RDP is I believe the "BIOS Key Code". So in this case it would be 99 (0x63). Also the E0 is I believe significant and is also visible in the Keyboard Scan Code Specification. I don't know how this gets communicated over the RDP link.

I'll need to read and experiment further, but I think we've discovered why xrdp behaves differently from a Windows Server.