On Thu Feb 12 12:44:51 2026 +0000, Byeongsik Jeon wrote:
The following self-contained [ime_test.c](https://gitlab.winehq.org/-/project/5/uploads/d54834a54cea2796f930d8be92eb37...) should show the desired behavior (Windows completely ignoring the IME processing for keys that are backtracked on) well. If the application restores msg.wParam == VK_PROCESS back to msg.wParam = ImmGetVirtualKey(hwnd), then in NtUserTranslateMessage it no longer goes through the IMM/IME-related code path. Instead, it follows the NtUserToUnicodeEx route—that is, the normal keyboard driver WM_KEYDOWN processing path. So I’m wondering why the patch is being made in the IME code. But I may be misunderstanding the exact scenario in which this becomes a problem. By any chance, are you testing this with the "Japanese – Kana" or "2-Set Korean" keyboard input source? In the test program you provided, "Japanese - Kana":
IME detected VK_PROCESSKEY, Replacing with original VK: 0x0041 (A) WM_KEYDOWN: wParam = 0x0041 (A) scan=0x1E WM_CHAR / WM_IME_CHAR: char = 0x3061 (?) WM_KEYUP: wParam = 0x0041 (A)Is this what you would like it to look like? ``` IME detected VK_PROCESSKEY, Replacing with original VK: 0x0041 (A) WM_KEYDOWN: wParam = 0x0041 (A) scan=0x1E WM_CHAR / WM_IME_CHAR: char = 0x0061 (a) WM_KEYUP: wParam = 0x0041 (A) ``` Then, this appears to be an issue within macdrv_ToUnicodeEx. With “Japanese – Kana,” the keycode-to-Hiragana mapping is also handled at the keyboard driver level. It might be easier to understand this by comparing it with "Japanese – Romanji". As far as I know, the IME input sources provided by macOS do not have an IME on/off mode, and we need to switch the input source in order to type A–Z characters. In other words, under normal IME input source conditions, macdrv_ToUnicodeEx is not usually called. In my opinion, it might be possible to handle this in macdrv_ToUnicodeEx by checking the result of macdrv_using_input_method(), although that could make the code a bit more complicated. Anyway, this is my analysis so far, and I hope this is useful, but I’m not certain. ---- Update: Although I haven't tested it myself, TISCopyCurrentASCIICapableInputSource should allow UCKeyTranslate to behave as intended. Fwiw regarding IME detection I think a solution (which also applies to other platforms where it might be hard as well) would be to have a mapping of well known non-IME host keyboard layouts, as a hardcoded name list if we can't do better, mapped to their corresponding well-known Windows HKL values, and every unknown host layout exposed as a generic Wine IME HKL, with the IME HKL bit set, as any other native IMEs.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9992#note_129602