On Wed Jun 10 20:29:04 2026 +0000, Matteo Bruni wrote:
changed this line in [version 9 of the diff](/wine/wine/-/merge_requests/10963/diffs?diff_id=274152&start_sha=c751a8ac2af27f1e22ec95a80038126312b31b93#ff16e096ba3fdb3e28a6cc2560a364b95deee87a_1539_1550) This is a bit tricky... In kbdus.dll the `tables->pKeyNames` entry for vsc 0x45 is "Pause", the one in `pKeyNamesExt` (so for 0x145) is "Num Lock" (i.e. they're already swapped in there). We don't have to replicate this in our driver-generated `KBDTABLES`, I guess, but adding some difference that will get in the way if we ever want to support custom keyboard layouts seems not ideal. [*]
Similarly, `VK_PAUSE` should map to scancode 0xe11d, which means that the KEY_PAUSE -> 0x021d mapping in the new setup probably needs to stay (or, if we e.g. go for KEY_PAUSE -> 0x45, we'll need to override the scancode for `MapVirtualKeyEx()` and such - exchanging one set of places needing special casing with a different one). Another thing is that `keyc2scan()` is often used when there is no reasonable state to pass in. That's currently happening in `X11DRV_MapVirtualKeyEx()`, `X11DRV_GetKeyNameText()`, which will go away soon but those uses will be replaced by equivalent ones to fill a number of tables in the `KBDTABLES` struct. No real problem, but it doesn't look super nice. FWIW, this is only useful for Pause vs Break (both scancode and VK) and potentially PrtSc vs ALT + PrtSc (scancode only).
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`.
That's basically right. There's an additional weirdness in that there is no WM_[SYS]KEYDOWN message for any PrtSc keypress, just the WM_[SYS]KEYUP. I know I read about it somewhere but I can't find it again... Anyway, that's a bit of a hassle for the tests so I'm going to take care of that later on. [*]: I agree that it would be nice to handle this for both winex11 and winewayland from common code. I don't know where the common code would live and how to structure it, though :/ -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10963#note_142719