@rbernon I have a WIP prototype at https://gitlab.winehq.org/afrantzis/wine/-/commits/wayland-numlock-win32u which partially moves in the direction you suggested. It still performs the scan -> vkey mapping on the sending side, but at least it's now done internally in win32u so will benefit all drivers that use KBDTABLES.
The prototype currently doesn't handle 0xE1 extended scancode since I am not sure what's the best way to pass the info. 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.
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.
Actually I had something related in rbernon/wine@0d119e5f, could it help your case?
Thanks, in the prototype I incorporated this but removed the check for numlock, since it doesn't seem to be relevant for the conversion from vkey -> WCHAR (I verified on win10).
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.