On Thu Apr 30 10:30:23 2026 +0000, Matteo Bruni wrote:
It's not entirely orthogonal because of those interactions with `ActivateKeyboardLayout` and `GetKeyboardLayoutName`, especially the latter has to figure out the keyboard layout from the HKL alone if there is no registry data to help, and something like this patch is needed. Although, one thing I should mention is that "Layout Id" is only present in the registry for variant layouts[*], so this kind of change will need to stay around even after the registry data is in place. I'll tweak the patch to make that more clear. Yes, the idea was to put all the data in wine.inf. And yes, the full DB is huge, but I guess it can be brought in in steps... [*]: e.g. KLID 00000409 (US) has no "Layout Id" entry and HKL 0x0409{locale id}, KLID 00010409 (United States-Dvorak) has "Layout Id" 0002 and thus HKL 0xf002{locale id} Yes, when "Layout Id" isn't set a registry key is meant for the HKL which high word matches the registry key name. When "Layout Id" is set, the registry key is meant for the HKL which high word matches the ("Layout Id" | 0xf000). Isn't this what `NtUserGetKeyboardLayoutName` does already? The KLID, returned by `GetKeyboardLayoutName` is the name of the registry key itself, which is the same as the HKL high word for base layouts, or something different for variants.
It seems to me that the line that changed here has nothing to do with this I believe and is only meant as a workaround for when registry entries are not present? We should simply add the proper registry keys if they are necessary. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10779#note_138357