On Wed Jan 28 16:04:35 2026 +0000, Marc-Aurel Zent wrote:
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... I have not seen much evidence so far that SendInput does a very different thing from real user input, and it's usually usable for testing.
Otherwise you can go for the heavy weaponry and use dinput tests to create an HID keyboard you can control in the tests. In any case I am still skeptical of the conclusion, and I would rather think that something else in our message processing is involved, and tests are going to be needed to decide. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9992#note_128289