On Sat Mar 16 12:41:20 2024 +0000, Rémi Bernon wrote:
This looks like simple fixes but I'm curious, do you know if it would be possible to build some KBDTABLES similarly to how it's done in winewayland? Like:
- is macOS providing key scancodes that could be mapped back to
hardware scancodes, and 2) ways to inspect the host layout mapping for things like dead key combinations and such? Though 2) / dead key support isn't implemented yet in winewayland / win32u, but libxkbcommon recently introduced functions to inspect the mapping without having to try every combination.
1. I do not believe so, the `UC*` class of functions is already an abstraction over the actual hardware scan codes in IOKit, but they still represent hardware keys:
``` /* * Summary: * Virtual keycodes * * Discussion: * These constants are the virtual keycodes defined originally in * Inside Mac Volume V, pg. V-191. They identify physical keys on a * keyboard. Those constants with "ANSI" in the name are labeled * according to the key position on an ANSI-standard US keyboard. * For example, kVK_ANSI_A indicates the virtual keycode for the key * with the letter 'A' in the US keyboard layout. Other keyboard * layouts may have the 'A' key label on a different physical key; * in this case, pressing 'A' will generate a different virtual * keycode. */ ```
2. Theoretically this is possible, one would have to dig into the `struct UCKeyboardLayout`, which has multiple sub-tables for mappings, and in conjunction with `struct UCKeyModifiersToTableNum`, which it also holds this can be done. What it does though is convert a Mac virtual key code only directly to a utf-16 char.
Will take a look at the winewayland implementation to see if something can be improved here, thanks for the hint!