From what I see, wineserver is extensively based on vkeys (internal state, requests, messages), so a potential transition to scan codes would indeed be non-trivial.
That's what I meant. Some logic could perhaps be moved to win32u but I haven't really looked at it so I'm not sure how hard it would be.
Perhaps we can just pass the full scancode directly in KEYBDINPUT.wScan, for the scan->vkey purposes of `NtUserSendHardwareInput` at least, and the internals can mask it after we perform the mapping.
Yeah, something like that would work. Instead of a new `map_scan_to_vkey` helper, I would rather use the existing `kbd_tables_init_vsc2vk` and make it return a UINT16 array which would include the vkey flags. Then the vkey replacement could be done on wineserver side (with the other replacements) where you have the keystate handy.
The trade-off of moving this to win32u is that we are effectively hardcoding the conversion and any user customizations will not be applied (e.g, if a user has an XKB mapping of <numlock + numpad 5> to another symbol). Not sure how important this is, and whether the policy is to remain closer to the windows layouts rather than allowing such customizations.
The `kbd_tables_vkey_to_wchar` hardcoding was mostly an experiment, although I think it matches `ToUnicodeEx` behavior. We can probably drop it if it doesn't end up being useful.