Keycode 121 and 122 (for Korean) are not recognized in xev

[letrhee]

Environment

Windows build number: 10.0.21364.1000
Your Distribution version: Ubuntu 20.04
Your WSLg version: 1.0.17.1

Steps to reproduce

• Prepare a 106-key keyboard for Koreans
• xev &
• Enter 한/영키(Korean<->English shift, Keycode 122) and 한자키(Convert Chinese character, Keycode 121)

Unlike other keys, not recognized (FYI, media keys also do not work)

If you plan to integrate the Windows IME in WSLg, you may not need to pass these keys (except maybe some media keys). If not, I think it's a good idea to send the keystrokes to the Linux app.

WSL logs:

• versions.txt
• weston.log
• pulseaudio.log

Expected behavior

Keycode appears normally in xev

This screenshot was taken using Ubuntu 20.04 running on Hyper-V (https://github.com/microsoft/linux-vm-tools/pull/106 applied).

Actual behavior

Not recognized in xev

[hideyukn88]

@letrhee , thanks for reporting, from weston.log, Korean keyboard is correctly reported but as you pointed in xev, it's not working properly. Would you please try the workaround described at https://github.com/microsoft/wslg/issues/27 and see if this also helps for Korean, thanks!

[20:29:49.003] kbd_layout:0xe0010412 kbd_type:0x8 kbd_subType:0x5 kbd_functionKeys:0xc [20:29:49.003] convert_rdp_keyboard_to_xkb_rule_names: matching layout=kr variant=kr104

[letrhee]

@hideyukn88 Thanks for the advice. I've tried the following:

• Create locale using ko_KR.UTF8
  • Already ko_KR.UTF8. Same with locale regeneration.
• Use setxkbmap kr
  • No change
• Use sudo dpkg-reconfigure keyboard-configuration
  • Of course, there is no correct setting (described below)

The root of the problem is that the Korean 106-key keyboard is not a normal keyboard layout. As far as I know, This keyboard is a variant of the international 104-key layout with two special keys added with odd behavior. Of course, Linux's keyboard layout doesn't have this configuration. Depending on the kernel, distribution, and keyboard driver, these two keys sometimes work differently, so many Koreans used xev to find out what keycodes the two keys have, and then map them correctly. (Or even give up using these two keys on Linux)

The 104-key Korean variant, kr104, basically maps Right Alt to Hanyoung key (108, Hangul, instead of 121) and Right Ctrl to Hanja key (105, Hanja. instead of 122). I can use these keys to type Korean with fcitx. However, the problem is that the original intended special key input is not recognized. I think this is in the symptom of not passing special keystrokes like media keys.

There is a similar case in the Virtual box, but since this virtual machine does not pass these two keys, I use Right Alt and Right Ctrl to input Korean. On the other hand, VMWare has the problem of misrecognizing these keys as those of a Japanese keyboard, and workarounds can be used.

[tomykaira]

Jp106 keyboard has a similar problem. Jp106 has ¥ (Yen sign) key (PS2 scan code 7D) at the right top of a keyboard, between ^ and Backspace. xmodmap -pke reports

keycode 132 = backslash bar backslash bar

but xev does not respond to the key.

Windows build number: Microsoft Windows [Version 10.0.21370.1]
Your Distribution version: Ubuntu Release:        20.04
Your WSLg version: 1.0.19

[hideyukn88]

Regarding to Japanese Yen/Vertical bar sign key between ^ and backspace key on Japanese OADG 106 physical hardware keyboard, the hardware scan code for that key is 0x7D (http://kbdlayout.info/kbd106/scancodes) but 0x7D is mapped to VK_NONE by WinPR (https://pub.freerdp.com/api/winpr_2include_2winpr_2input_8h.html)

#define KBD4_T7D VK_NONE

Thus, WinPR's GetVirtualKeyCodeFromVirtualScanCode(0x7D, 4) returns VK_NONE, and this ends up scan code 0 in evdev from GetKeycodeFromVirtualKeyCode().

xf_input_keyboard_event hw_code=7d ext=0 vk_code=ff scan_code=0

Eventually it needs to support RDP's Unicode input, so no more these conversions and it also allows IME on Windows side to be used to input CJK range characters.

[noriakia]

Jp106 keyboard with even more similar problems. When entering Japanese, the conversion key used for kanji conversion and the no conversion key do not work.

The input method framework uses ibus, and the Japanese Input Method Editor uses mozc.

scan code = 79 Henkan, 7b Muhenkan

keycode 100 = Henkan_Mode NoSymbol Henkan_Mode
keycode 102 = Muhenkan NoSymbol Muhenkan

but xev does not respond to the key.

Windows build number: Microsoft Windows [Version 10.0.21376.1]
Your Distribution version: Ubuntu Release:        20.04.2
Your WSLg version: 1.0.19

[hideyukn88]

@tomykaira, I have a fix for "Jp106 has ¥ (Yen sign) key at left side of backspace key" issue.

@noriakia, I also have a fix for "Jp106 Henkan and Muhenkan" key, it was same root cause as Yen sign.

@letrhee, regarding to Korean keyboard, thanks for your detail explanation of kr104 layout, I'm reaching out the engineer who familiar with Korean input system inside Microsoft. and will discuss for possible solution.

Thanks all for trying out WSLg and reporting the issue!

[hideyukn88]

Fixed in 1.0.24

[letrhee]

Uh... Probably 1.0.25 or later. Anyway, thanks!

[hideyukn88]

@letrhee, right, sorry for confusion, https://github.com/microsoft/weston-mirror/pull/25 is not in 1.0.24.

[letrhee]

It's not a big problem for me because the two keys are recognized, but it seems that the Hangul key and the Hanja key are swapped.

[kim3321]

Is this problem solved? In my case, I used hangul/hanja key in an environment where I ran x11 on Windows 10, but But the keys are not responding at all. Is this problem applied to the latest wsl kernel? Currently, I am using ubuntu 22.04 in wsl2 on Windows 10.

[hideyukn88]

@kim3321, what do you see with xev ? thanks!

[letrhee]

It works fine on Windows 11. I don't know about Windows 10.

[kim3321]

@kim3321, what do you see with xev ? thanks!

@hideyukn88 I used mobaXterm and execute xev. It was confirmed that all keys operate well except for hangul and hanja keys in Xserver provided by mobaXterm.