On Fri Jun 5 09:17:51 2026 +0000, Matteo Bruni wrote:
Because, as per the test results, you have e.g.: ``` MapVirtualKeyExA(0x45, MAPVK_VSC_TO_VK_EX, ...); -> VK_NUMLOCK MapVirtualKeyExA(VK_NUMLOCK, MAPVK_VK_TO_VSC_EX, ...); -> 0x45 MapVirtualKeyExA(0xe11d, MAPVK_VSC_TO_VK_EX, ...); -> VK_PAUSE MapVirtualKeyExA(VK_PAUSE, MAPVK_VK_TO_VSC_EX, ...); -> 0xe11d GetKeyNameTextA(0x00450000, ...); -> "Pause" GetKeyNameTextA(0x01450000, ...); -> "Num Lock" GetKeyNameTextA(0xe11d0000, ...); -> "Right Ctrl" GetKeyNameTextA(0x011d0000, ...); -> "Right Ctrl" GetKeyNameTextA(0x001d0000, ...); -> "Ctrl" ``` i.e. the whole mapping is inconsistent for those particular keys and we don't want to break `MapVirtualKeyExA()`. FWIW, actually pressing the buttons on the keyboard matches with `GetKeyNameTextA()`; KBDTABLES from Windows' kbdus.dll confirm the `MapVirtualKeyExA()` mapping as per above i.e. the special casing isn't in the `MapVirtualKeyExA()` machinery. Well maybe there's some extra mapping to be done in `GetKeyNameText` then (although would be IMO better to do that special case in win32u), but the extra cases here should go into keyc2scan. If handling the `BREAK` scancode properly is also important, then it should go in keyc2scan as well, with extra modifier key state parameter, and ideally a similar change done on the winewayland side.
And probably then while we're fixing exotic scancodes, maybe worth adding the extra cases for PrtSc / SysRq while at it. According to https://kbdlayout.info/kbdus/scancodes, I expect it to be something like: `scan == 0x12a && mod & (Ctrl | Shift) => 0x137` and `scan == 0x12a && mod & (Alt) => 0x54`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10963#note_142289