March 16, 2024
7:41 a.m.
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: > 1) 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! -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5319#note_64993