Since !9128, macdrv ime processing has been broken. In my opinion, this seems to be an issue with the macdrv ime code rather than a problem with !9128.
In macdrv_ImeProcessKey: ``` macdrv_send_keydown_to_input_source(flags, repeat, keyc, himc, &done); while (!done) NtUserMsgWaitForMultipleObjectsEx(0, NULL, INFINITE, QS_POSTMESSAGE | QS_SENDMESSAGE, 0); ```
Within the macdrv WINE_IME_POST_UPDATE code path, there are no message post/send operations, causing it to wait infinitely here. I haven't analyzed in detail why it worked before, but I guess it escaped the wait due to unrelated messages. This code likely represents a remnant of the old macdrv ime code. I recall the old macdrv ime code used SendMessage().
In ime processing, some key inputs reach macdrv_sent_text_input without calling macdrv_ime_set_text. Therefore, I modified the code to clearly detect when macdrv_sent_text_input is reached.
I left a working fallback code in case NtCreateEvent() fails. But that might be superfluous.
-- v3: win32u: Fix typo. winemac: Use event handle to detect macdrv ime processing done.