@rbernon I saw that testbot is complaining about new failures with this MR and started investigating: https://testbot.winehq.org/JobDetails.pl?Key=145490. The TL;DR is that I suspect there is something wrong with the keyboard layout selection in the Windows testbot setups (see below).
I assume we need to delay this MR until the testbot failures are resolved (not sure what the policy is)?
Here are my current findings for the test failures:
w10pro64_ja (64 bit input) --------------------------
https://testbot.winehq.org/JobDetails.pl?Key=145490&f310=exe64.report#k3...
This setup maps the RightControl scancode (0xe01d) to vkey 0x19 VK_HANJA/VK_KANJI instead of the expect VK_RCONTROL. From online investigations I couldn't find a Japanese keyboard layout that does this. This is behavior is only documented for Korean layouts, and looking in the testbot report I see that although the language id is 0411 (ja-JP) the reported keyboard driver is in fact the Korean "KBDKOR.dll":
input.c:5703: hkl 0000000004110411 input.c:694: L"KBDKOR.DLL" flags 0
Debian 11 32-bit zh_CN ----------------------
https://testbot.winehq.org/JobDetails.pl?Key=145490&f401=win32_zh_CN.rep...
The new test failure here complains that RightShift (scan) + vkey F maps to char capital 'F'. The actual wch/wch_shift values are not reported, but since language id is 0x0804 I assume the following snippet applies
``` static void get_test_scan( WORD vkey, WORD *scan, WCHAR *wch, WCHAR *wch_shift ) { ... /* zh_CN returns a different WM_(SYS)CHAR, possibly coming from IME */ if (HIWORD(hkl) == 0x0804) { *wch = 0x430; *wch_shift = 0x410; } } ```
This workaround and the justification seems suspicious since U+0410/U+0430 are Cyrillic capital/small 'a'. The w10pro64_zh_CN log https://testbot.winehq.org/JobDetails.pl?Key=145490&f311=exe64.report#k3... provides another explanation:
input.c:5703: hkl 0000000008040804 input.c:694: L"KBDRU.DLL" flags 0x10001
Although 0x0804 (zh-CN) is requested we end up using Russian "KBDRU.DLL". This layout indeed maps scancode 0x21 (key F on US layouts) to Cyrillic A. It seems that the zh_CN workaround is actually masking another problem with layout selection.