Right shift key not detected by wslg

[BrianShTsoi]

Windows build number:

Windows 10.0.19045.2364

Your Distribution version:

20.04

Your WSL versions:

WSL version: 1.0.3.0 Kernel version: 5.15.79.1 WSLg version: 1.0.47 MSRDC version: 1.2.3575 Direct3D version: 1.606.4 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.19045.2364

Steps to reproduce:

1. Open gedit/emacs with windows terminal
2. Type while holding the right shift key

Expected behavior:

Letters should be capitalized when right shift key is pressed.

Actual behavior:

Letters are not capitalized when right shift key is pressed. Other keys behave properly. Left shift key and caps lock properly capitalize letters. Left shift key properly produced lower case letters when pressed while caps lock is on, but right shift key has no effect when caps lock is on. Right shift key behaves properly outside WSLg, such as while in the wsl terminal. Everything works fine if I use VcXsrv instead of WSLg

[hideyukn88]

@BrianShTsoi, thanks for reporting the issue. As I tried at my end, the right shift key works as expected and it doesn't exhibit the issue you mentioned. What keyboard layout are you using at Windows side, and do you happen to manually modify at Linux side (such as xkbsetmap)? And would you please share the equivalent log lines at your /mnt/wslg/weston.log as below. Mine has like below with English (United States) layout, thanks!

[12:46:15.264] kbd_layout:0x409 kbd_type:0x4 kbd_subType:0x0 kbd_functionKeys:0xc
[12:46:15.264] convert_rdp_keyboard_to_xkb_rule_names: matching model=pc105 layout=us variant=(null) options=(null)

[BrianShTsoi]

Thank you for the quick response. I used Microsoft PinYin (Simplified Chinese) as my keyboard layout. After reading your comment I switched to a US keyboard layout and the right shift key works properly. I also tried Microsoft Quick (Traditional Chinese) and the right shift key doesn't work. So I suppose the issue is about non-US keyboard layouts and at least I have a work around now. I did not manually modify anything on the Linux side. here's my log lines in /mnt/wslg/weston.log

[13:56:14.196] kbd_layout:0x804 kbd_type:0x4 kbd_subType:0x0 kbd_functionKeys:0xc
[13:56:14.197] convert_rdp_keyboard_to_xkb_rule_names: matching model=pc105 layout=(null) variant=(null) options=(null)

Thanks!

[hideyukn88]

@BrianShTsoi, I installed Chinese (Simplified, Chine) - Microsoft Pinyin keyboard layout and right shift key works just same way as left shift key, thus I don't observe the issue you described, and observed same log at weston.log. What do you see with xev -event keyboard with right shift key? Below is from my environment, which shows "Shift_R" is pressed and released, do you see this? thanks!

KeyPress event, serial 35, synthetic NO, window 0x600001,
    root 0x390, subw 0x0, time 28034, (154,32), root:(553,560),
    state 0x0, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyRelease event, serial 35, synthetic NO, window 0x600001,
    root 0x390, subw 0x0, time 28192, (154,32), root:(553,560),
    state 0x1, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

[akidon30]

I am encountering the same issue. I installed Ubuntu 20.04.5 on Windows 10 Japanese.

wsl --version

WSL バージョン: 1.0.3.0
カーネル バージョン: 5.15.79.1
WSLg バージョン: 1.0.47
MSRDC バージョン: 1.2.3575
Direct3D バージョン: 1.606.4
DXCore バージョン: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windowsバージョン: 10.0.19045.2364

Following is an output from /mnt/wslg/weston.log

[23:41:14.963] kbd_layout:0xe0010411 kbd_type:0x4 kbd_subType:0x0 kbd_functionKeys:0xc
[23:41:14.963] convert_rdp_keyboard_to_xkb_rule_names: matching model=pc105 layout=us variant=(null) options=(null)

When I run xev -event keyboard with the right shift key, KeyPress is output when I press the key, but KeyRelease is not outputted when I release the key. Further more, When I press the right shift key again, there is no output in the console. Neither for releasing the key.

$ xev -event keyboard

Outer window is 0x600001, inner window is 0x600002

KeymapNotify event, serial 24, synthetic NO, window 0x0,
    keys:  4294967234 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

KeyPress event, serial 25, synthetic NO, window 0x600001,
    root 0x390, subw 0x0, time 836845, (-399,-338), root:(0,0),
    state 0x10, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

[asada-n]

I've encoutered the same problem. WSLg apps won't detect the right shift key. I don't find any problem with other keys.

My WSL version:

$ wsl.exe --version
WSL version: 1.0.3.0
Kernel version: 5.15.79.1
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2486

The kbd_layout part of wetson.log - tell me if you want to see other parts. It looks same to the output of @hideyukn88, so this might not cause this issue.

[20:56:46.345] kbd_layout:0x409 kbd_type:0x4 kbd_subType:0x0 kbd_functionKeys:0xc
[20:56:46.345] convert_rdp_keyboard_to_xkb_rule_names: matching model=pc105 layout=us variant=(null) options=(null)

Xev behaves the same to how @akidon30 reports.

The very first key push is detected, but releasing the key is not detected. Afterwards, even pushing the right shift key is not detected anymore.

$ xev -event keyboard
Outer window is 0x1000001, inner window is 0x1000002

KeymapNotify event, serial 24, synthetic NO, window 0x0,
    keys:  4294967234 0   0   0   0   0   0   0   0   0   0   0   0   0   0   0
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0

KeyPress event, serial 25, synthetic NO, window 0x1000001,
    root 0x390, subw 0x0, time 362658, (1275,521), root:(2004,593),
    state 0x0, keycode 62 (keysym 0xffe2, Shift_R), same_screen YES,
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

I do not have any modification to my key layout, nether in host nor in WSL.

Thanks

[hideyukn88]

@akidon30, @asada-n, thanks for sharing the information. I noticed you are on Windows 10 (not Windows 11), so just in case I tried it on Windows 10, but I'm not able to replicate the issue at my end, the right shift works as expected. Thus, I'm sure there is something still missing at my end. Have you installed some keyboard shortcuts software monitoring the key input or have changed any configuration of Windows? thanks!

[akidon30]

@hideyukn88, thank you for checking the information. I don't installed any software monitoring the key input, and don't change Windows configuration as far as I remember. To investigate the issue, I made a local build of the WSLg to enable debug output that are commented out in the source code (xf_input_keyboard_event() in rdp.c of libweston), and got the following output in /mnt/wslg/weston.log.

I pressed a key twice after I launch the 'xev' command (I re-launch the 'xev' command before getting the log for each keys). I noticed a value of 'ext' is changed from 0 to 1 for Right Shift key, but it is consistent for Left Shift key, Right Alt key and Left Alt key. I guess this could be a reason why the issue is occurred with Right Shift key only, but I have no idea how to investigate further. Let me know if you need any further information on my PC. Thank you!

[Right Shift key]

[22:57:52.821] RDP backend: xf_input_synchronize_event ScrLk:0, NumLk:1, CapsLk:0, KanaLk:0
[22:57:52.821] code=36 ext=0 vk_code=a1 scan_code=3e
[22:57:52.822] RDP backend: xf_input_keyboard_event code=36 ext=0 vk_code=a1 scan_code=3e pressed=1, idle_inhibit=1
[22:57:52.822] code=36 ext=1 vk_code=1ff scan_code=0
[22:57:52.822] RDP backend: xf_input_keyboard_event code=36 ext=1 vk_code=1ff scan_code=0 pressed=1, idle_inhibit=2
[22:57:53.242] code=36 ext=1 vk_code=1ff scan_code=0
[22:57:53.242] RDP backend: xf_input_keyboard_event code=36 ext=1 vk_code=1ff scan_code=0 pressed=0, idle_inhibit=1
[22:57:54.731] code=36 ext=1 vk_code=1ff scan_code=0
[22:57:54.732] RDP backend: xf_input_keyboard_event code=36 ext=1 vk_code=1ff scan_code=0 pressed=1, idle_inhibit=2
[22:57:55.041] code=36 ext=1 vk_code=1ff scan_code=0
[22:57:55.042] RDP backend: xf_input_keyboard_event code=36 ext=1 vk_code=1ff scan_code=0 pressed=0, idle_inhibit=1

[Left Shift key]

[22:59:15.974] RDP backend: xf_input_synchronize_event ScrLk:0, NumLk:1, CapsLk:0, KanaLk:0
[22:59:15.975] code=2a ext=0 vk_code=a0 scan_code=32
[22:59:15.975] RDP backend: xf_input_keyboard_event code=2a ext=0 vk_code=a0 scan_code=32 pressed=1, idle_inhibit=1
[22:59:15.975] code=2a ext=0 vk_code=a0 scan_code=32
[22:59:15.975] RDP backend: xf_input_keyboard_event code=2a ext=0 vk_code=a0 scan_code=32 pressed=1, idle_inhibit=1
[22:59:16.304] code=2a ext=0 vk_code=a0 scan_code=32
[22:59:16.304] RDP backend: xf_input_keyboard_event code=2a ext=0 vk_code=a0 scan_code=32 pressed=0, idle_inhibit=0
[22:59:17.763] code=2a ext=0 vk_code=a0 scan_code=32
[22:59:17.763] RDP backend: xf_input_keyboard_event code=2a ext=0 vk_code=a0 scan_code=32 pressed=1, idle_inhibit=1
[22:59:18.052] code=2a ext=0 vk_code=a0 scan_code=32
[22:59:18.053] RDP backend: xf_input_keyboard_event code=2a ext=0 vk_code=a0 scan_code=32 pressed=0, idle_inhibit=0

[Right Alt key]

[23:00:20.544] RDP backend: xf_input_synchronize_event ScrLk:0, NumLk:1, CapsLk:0, KanaLk:0
[23:00:20.544] code=38 ext=1 vk_code=1a5 scan_code=6c
[23:00:20.544] RDP backend: xf_input_keyboard_event code=38 ext=1 vk_code=1a5 scan_code=6c pressed=1, idle_inhibit=1
[23:00:20.544] code=38 ext=1 vk_code=1a5 scan_code=6c
[23:00:20.544] RDP backend: xf_input_keyboard_event code=38 ext=1 vk_code=1a5 scan_code=6c pressed=1, idle_inhibit=1
[23:00:20.853] code=38 ext=1 vk_code=1a5 scan_code=6c
[23:00:20.853] RDP backend: xf_input_keyboard_event code=38 ext=1 vk_code=1a5 scan_code=6c pressed=0, idle_inhibit=0
[23:00:22.204] code=38 ext=1 vk_code=1a5 scan_code=6c
[23:00:22.204] RDP backend: xf_input_keyboard_event code=38 ext=1 vk_code=1a5 scan_code=6c pressed=1, idle_inhibit=1
[23:00:22.492] code=38 ext=1 vk_code=1a5 scan_code=6c
[23:00:22.492] RDP backend: xf_input_keyboard_event code=38 ext=1 vk_code=1a5 scan_code=6c pressed=0, idle_inhibit=0

[Left Alt key]

[23:01:22.720] RDP backend: xf_input_synchronize_event ScrLk:0, NumLk:1, CapsLk:0, KanaLk:0
[23:01:22.720] code=38 ext=0 vk_code=a4 scan_code=40
[23:01:22.720] RDP backend: xf_input_keyboard_event code=38 ext=0 vk_code=a4 scan_code=40 pressed=1, idle_inhibit=1
[23:01:22.720] code=38 ext=0 vk_code=a4 scan_code=40
[23:01:22.720] RDP backend: xf_input_keyboard_event code=38 ext=0 vk_code=a4 scan_code=40 pressed=1, idle_inhibit=1
[23:01:23.107] code=38 ext=0 vk_code=a4 scan_code=40
[23:01:23.107] RDP backend: xf_input_keyboard_event code=38 ext=0 vk_code=a4 scan_code=40 pressed=0, idle_inhibit=0
[23:01:24.364] code=38 ext=0 vk_code=a4 scan_code=40
[23:01:24.365] RDP backend: xf_input_keyboard_event code=38 ext=0 vk_code=a4 scan_code=40 pressed=1, idle_inhibit=1
[23:01:24.752] code=38 ext=0 vk_code=a4 scan_code=40
[23:01:24.752] RDP backend: xf_input_keyboard_event code=38 ext=0 vk_code=a4 scan_code=40 pressed=0, idle_inhibit=0

[hideyukn88]

@akidon30, the "ext" presents FASTPATH_INPUT_KBDFLAGS_EXTENDED flag in Remote desktop protocol, and if I understand correctly, it should not be set for right shift key (refer below link for remote desktop protocol specification). This is a bit confusing since at Windows keyboard driver level, right shift is extended key (see below link to Windows US English and Japanese keyboard layout driver)

From previous comments, it looks you are using Japanese 101 Keyboard Layout with IME (and you are not on OADG 106 Japanese keyboard which has "henkan" key next to space key). Just for sanity check, if you switch to US English layout (0x409), does it change anything? thanks!

Link to Windows keyboard layout driver for US English

https://github.com/microsoft/Windows-driver-samples/blob/07779ee84973f2f63a1f2ced6377463b1c01baaf/input/layout/kbdus/kbdus.c#L38

Link to Windows keyboard layout driver for Japanese 101 keyboard.

https://github.com/microsoft/Windows-driver-samples/blob/07779ee84973f2f63a1f2ced6377463b1c01baaf/input/layout/fe_kbds/jpn/101/kbd101.c#L42

Link to Remote Desktop Protocol Specification for TS_FP_KEYBOARD_EVENT

https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpbcgr/089d362b-31eb-4a1a-b6fa-92fe61bb5dbf

FASTPATH_INPUT_KBDFLAGS_EXTENDED

Indicates that the keystroke message contains an extended scancode. For enhanced 101-key and 102-key keyboards, extended keys include the right ALT and right CTRL keys on the main section of the keyboard; the INS, DEL, HOME, END, PAGE UP, PAGE DOWN and ARROW keys in the clusters to the left of the numeric keypad; and the Divide ("/") and ENTER keys in the numeric keypad.

[hideyukn88]

@akidon30, if you don't mind, would you please try "spy++"? If you have installed any version of Visual Studio (not Visual Studio Code), it's installed under, for example my case, it's enterprise edition, "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\Tools\spyxx_amd64.exe". And by monitoring window message to the Linux GUI application window, what key inputs are delivered to application.

Below is on my machine with press/release right shift key, which shows it doesn't have "fExtended" property.

[asada-n]

@hideyukn88 Hello, thank you for all your researches.

Just a quick report, I found the right shift key works as expected when I switch my input method from Japanese (Microsoft IME) to English (US).

[asada-n]

This is an output of spy++, right shift working as expected.

And this is an output of spy++, right shift not working as IME is being enabled.

[akidon30]

@hideyukn88, the right shift key works fine after I switch the input method to English(US) as well as @asada-n reports. A result of spy++ in my PC is as follows:

input method is Japanese: (fExtended is set)

input method is English(US): (fExtended is not set)

I guess I am using 106 keyboard as the "henkan" key is placed next to the space key, but I am not sure because I am using a laptop PC (Surface Book 1).

[hideyukn88]

@akidon30, @asada-n, now I'm able to reproduce the issue using Japanese keyboard layout on Windows 10, and @BrianShTsoi, using Chinese Pinyin layout as well on Windows 10, but it doesn't repro with English US layout even on Windows 10. And it does not reproduce on Windows 11 with any of those keyboard layouts. Given this is OS behavior difference, I will consider have some additional patch to address this in WSLg, thanks for helping us!

[khtan]

I would like to add some more information because it seems that the right shift and right control keys are not detected by Gui apps and not some terminal/console apps. I am using a standard Microsoft keyboard.

| shell/app      | right shift key | right control key | comments                                                 |
|----------------+-----------------+-------------------+----------------------------------------------------------|
| wsl shell      | OK              | OK                |                                                          |
| emacs -nw      | OK              | OK                | emacs without windows                                    |
| emacs          | Does not work   | Does not work     |                                                          |
| spacemacs      | Does not work   | Does not work     | spacemacs is a layer over emacs, so expect same behavior |
| xterm          | Does not work   | Does not work     |                                                          |
| gnome-terminal | Does not work   | Does not work     |                                                          |

All the above apps were invoked from the wsl shell.

Hope this sheds light on this problem.

Details of machine

Host: Win10 Version 22H2 (OS Build 19045.2486) WSL2 machine: Ubuntu 22.04.1 LTS

wsl --version WSL version: 1.0.3.0 Kernel version: 5.15.79.1 WSLg version: 1.0.47 MSRDC version: 1.2.3575 Direct3D version: 1.606.4 DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp Windows version: 10.0.19045.2486

[hideyukn88]

@khtan, thanks for info, but I can't not reproduce the issue with Right Control Key, it works for me on Window 10 with those East Asian keyboard has issue with Right Shift Key, are you using some other different keyboard layout, thanks!

[khtan]

I am using standard Microsoft keyboard for English language. When u say u cannot reproduce the problem, which app ( emacs, xterm, gnome-terminal ) did you use? Since it is working for you, I would like to know more about your configuration so that I can consider upgrading to them. Are you on Win 10 22H2? Is your Ubuntu 22.04? Thanks for your fast response,

On Thu, Feb 9, 2023 at 8:31 AM Hideyuki Nagase @.***> wrote:

@khtan https://github.com/khtan, thanks for info, but I can't not reproduce the issue with Right Control Key, it works for me on Window 10 with those East Asian keyboard has issue with Right Shift Key, are you using some other different keyboard layout, thanks!

— Reply to this email directly, view it on GitHub https://github.com/microsoft/wslg/issues/930#issuecomment-1424474213, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACBDX6TXUQB2XOEJATAZ4ZLWWULWJANCNFSM6AAAAAATAJFN3Y . You are receiving this because you were mentioned.Message ID: @.***>

[hideyukn88]

@khtan,

Are you on Win 10 22H2? Is your Ubuntu 22.04?

I have tried both Windows 10 and 11, and both has all updates, and both on Ubuntu 20.04 LTS and 22.04.

If you have a chance, would you please share your /mnt/wslg/weston.log? thanks!

[khtan]

Thanks for your reply. Turns out my problem was self inflicted. Somehow, my Win10 has sticky keys turned on. So I turned off Mouse keys, Sticky keys, Toggle keys and Filter keys -- one of them was causing the Shift to not register for WSL2.