On Fri Jan 2 22:23:05 2026 +0000, Sven Baars wrote:
Thanks for looking into this. Did you also confirm that the workaround was necessary for you with older versions of SCIM? When looking into that bug I was unfortunately not able to do that. Also, it would probably be better to use `git revert` to revert the original commit that implemented the workaround. And then mention in the commit message that this has been fixed in SCIM (and include the bug link like you already did of course). Thanks! Thanks for the comment!
I couldn't find a proper bugfix log in the SCIM git log, so I did some additional testing. In my previous tests, I had only tested with scim-hangul. I tested again with scim-pinyin and SCIM built-in rawcode_imengine. In conclusion, the issue seems to be a bug in the process_key_event of each imengine. The `process_key_event` function of the problematic SCIM imengines are implemented as follows: ``` if (key.is_key_release()) return true; ``` In the non-problematic scim-hangul, it returns false. By returning `false` in this situation, SCIM can call IMdkit::IMForwardEvent and the X client can process the key release event. This is the same for the ibus and fcitx imengines as well. At the time of a4a5a2e, SCIM was the mainstream xim server, but today SCIM is not being developed anymore, it has been replaced by ibus and fcitx, so it doesn't seem necessary for Wine to continue this workaround. It also creates additional issues for xim servers that work correctly, as in #55849. And, I didn't use git revert because of the changes in handle_wm_protocols() since a4a5a2e. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9847#note_126369