On Wed Jan 28 16:04:35 2026 +0000, Rémi Bernon wrote:
The split of ImeToAsciiEx from ImeProcessKey doesn't seem right to me. ImeProcessKey should return whether the key has been consumed or not, there's no good way to backtrack on an decision to consume a key. It needs to be this way, I think, and I have been contemplating how to write a test for this, but it is not trivially possible to show this on native Windows at least without physically pressing keys, since `NtUserSendInput` and friends do not seem to be passing through the native IME subsystem in the same way as it does for Wine.
In any case, FFXIV specifically always has an active IME context while the game is running and then in its window message loop, decides to discard IME input when no text field is active in-engine (like for normal WASD movement), by calling `ImmGetVirtualKey()` and indeed backtracking on the decision to consume a key by replacing `VK_PROCESSKEY` again with the original key. This works fine on native Windows and Wine versions pre-IME unification (somewhere around Wine 7.7 on macOS at least), where pretty much IME was handled similarly to how it is done in this MR conceptually. Here I chose to backtrack with the already existing and fairly recently added `key_consumed` parameter (which seems to work fine here, but maybe there are some side effects, I am not seeing here at the moment), however in the original implementation it was all handled in the `ImeToAsciiEx` implementation of the user driver like so: ``` /* KeyStroke not processed by the IME * so we need to rebuild the KeyDown message and pass it on to WINE */ if (!GenerateMessageToTransKey(lpdwTransKey, &msgs, msg, vkey, MAKELONG(0x0001, uScanCode))) GenerateIMEMessage(hIMC, msg, vkey, MAKELONG(0x0001, uScanCode)); ``` If there is a more elegant solution to feeding IME input around the `ImeToAsciiEx` stage into the native Cocoa input context, then that would be preferable, but I don't currently see a way to make this happen... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9992#note_128286