On Sat Mar 16 12:41:20 2024 +0000, Marc-Aurel Zent wrote:
- 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. */
- 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!
Thanks for the info! And I didn't mean to explore that as an alternative to this MR, it's probably a lot of changes, but I believe it's ultimately the right way to implement keyboard layouts and I was looking for info on how to do that on the macOS side.
(Some applications expect to receive the Windows hardware scan codes, or expect the same mapping between scan codes and virtual keys as native keyboard layouts)