GNOME Bugzilla – Bug 645993
Improve handling of XIM/XI2
Last modified: 2017-08-25 10:57:49 UTC
I've just tested several Chinese input methods using XIM backend including fcitx, yong and ibus. The common problem is when the input method is on, arrow keys, backspace and enter are not working for GTK 3 applications (like empathy and gnome-terminal). For yong and ibus, Ctrl-Space (which is used to call and close the input method) doesn't work either. But ibus works well with its own module. This problem can be reproduced by: * install and configure fcitx (https://wiki.archlinux.org/index.php/Fcitx) * logout and login * try in a gnome-terminal. use Ctrl-Space to call the input method, and try arrow keys, etc. Also, this can be reproduced by these steps using ibus: * Instead of having GTK_IM_MODULE=ibus, we change it to: export GTK_IM_MODULE=xim export QT_IM_MODULE=xim export XMODIFIERS="@im=ibus" * on executing, we run ibus-daemon --xim -d & * try in a gnome-terminal. use Ctrl-Space to call the input method, and try arrow keys, etc. In both cases, GTK 2 programs work well. This is a critical problem to Chinese users (and probably other users need an IM) as all the XIM based input methods are not usable. As all are affected, I guess it's GTK+ XIM problem.
I don't think your issue is GTK3. I can use IBus without any problems. We implement almost the build issue in ibus 1.4 for GTK3. Probably it won't work if you use ibus 1.3.
(In reply to comment #1) > I can use IBus without any problems. > > We implement almost the build issue in ibus 1.4 for GTK3. > Probably it won't work if you use ibus 1.3. Are you using the XIM daemon of ibus, or ibus's gtk3 module? The GTK-3 support in ibus is fine (typically using /usr/lib/gtk-3.0/3.0.0/immodules/im-ibus.so), but GTK-3's support for XIM seems bad (using /usr/lib/gtk-3.0/3.0.0/immodules/im-xim.so) I think you need to change GTK_IM_MODULE to xim instead of ibus to reproduce the problem with IBus.
(In reply to comment #2) > (In reply to comment #1) > > I can use IBus without any problems. > > > > We implement almost the build issue in ibus 1.4 for GTK3. > > Probably it won't work if you use ibus 1.3. > > Are you using the XIM daemon of ibus, or ibus's gtk3 module? The GTK-3 support > in ibus is fine (typically using /usr/lib/gtk-3.0/3.0.0/immodules/im-ibus.so), > but GTK-3's support for XIM seems bad (using > /usr/lib/gtk-3.0/3.0.0/immodules/im-xim.so) > > I think you need to change GTK_IM_MODULE to xim instead of ibus to reproduce > the problem with IBus. Sorry, you're right. My GTK_IM_MODULE was ibus. Do you need to set GTK_IM_MODULE=xim with ibus + gtk applications? It's a bit complicated if GTK_IM_MODULE=xim. If the im client is gtk-xim, the gtk_im_context_xim_filter_keypress() calls XFilterEvent() and XFilterEvent() calls XSendEvent() internally. ibus-x11 receives the key event from XFilterEvent() -> WaitXIMProtocol() -> xim_forward_event(). ibus-x11 doesn't receive KeyPress events because KeyRelease events are buffered in X11.
(In reply to comment #3) > Do you need to set GTK_IM_MODULE=xim with ibus + gtk applications? No, it's just an experiment. I hope it is an easier way for developers to reproduce the problem. But for many other popular Chinese input methods like fcitx, they totally rely on xim. And I guess many other IMs may rely on XIM. > It's a bit complicated if GTK_IM_MODULE=xim. > If the im client is gtk-xim, the gtk_im_context_xim_filter_keypress() calls > XFilterEvent() and XFilterEvent() calls XSendEvent() internally. > ibus-x11 receives the key event from XFilterEvent() -> WaitXIMProtocol() -> > xim_forward_event(). > ibus-x11 doesn't receive KeyPress events because KeyRelease > events are buffered in X11. Sorry but I know little about the mechanism. However, as a phenomenon gtk-2 programs do work pretty well even when GTK_IM_MODULE=xim. So I'm wondering if there are any differences between the implementation of XIM in gtk-2 and gtk-3 causing the problem. Thanks a lot for paying attention and time to this problem.
Created attachment 184934 [details] [review] patch Thanks for the bug report, this patch seems to fix the issue here, these XIM modules seem to like replacing every key event with their own ones, which fools the legacy keyboard events handling in the XI2 code in GTK+.
(In reply to comment #5) > Created an attachment (id=184934) [details] [review] > patch Thanks for the patch. In my test, it seems KeyRelease also needs to be handled there. - if (xevent->type == KeyPress && xevent->xkey.keycode == 0) + if ((xevent->type == KeyPress || xevent->type == KeyRelease) && + (xevent->xkey.keycode == 0 || xevent->xkey.serial == 0))
I'm the maintainer of xsunpinyin and I confirm this bug on gtk+3 platform. (In reply to comment #6) > (In reply to comment #5) > > Created an attachment (id=184934) [details] [review] [details] [review] > > patch > > Thanks for the patch. > In my test, it seems KeyRelease also needs to be handled there. > > - if (xevent->type == KeyPress && xevent->xkey.keycode == 0) > + if ((xevent->type == KeyPress || xevent->type == KeyRelease) && > + (xevent->xkey.keycode == 0 || xevent->xkey.serial == 0)) Agree. Ignoring KeyRelease might cause problems when triggering the input method. As far as I tested, the latter solution works fine. :) Thanks
Any news? Will the fix be commited?
Created attachment 186334 [details] [review] patch I updated the attachment (id=184934)
The updated patch (id=186334) solved the problem, thanks!
Archlinux i686 gtk 3.0.9 fcitx 4.0.1 #9's patch seems works well.
Any updates for this bug?
Carlos, did you have any further thoughts on this ?
Is this really input method's fault? I explore a little, test with X & Qt & GTK Program. In XFilterEvent, Qt and Simple X program can give xim input method with non-zero serial, but in all gtk program(gtk2 & gtk3), serial number is zero. Seems it makes no sense that input method should pass the "correct" KeyEvent, they can't get the right one from gtk. Check the function gtk_im_context_xim_filter_keypress, it seems that's where the original zero serial number comes from.
(In reply to comment #14) > Is this really input method's fault? > > Check the function gtk_im_context_xim_filter_keypress, it seems that's where > the original zero serial number comes from. Oh, yes, indeed... so we'd control both the check and the value being set, sounds even better to me (In reply to comment #13) > Carlos, did you have any further thoughts on this ? I fear not right now, the long term ideal solution involves keeping a pointer to the original XEvent around (or the hability to compose both core/xi2 key events), XSendEvent being fixed (and the merge window for Xorg 1.11 is closed now :( ), and input methods understanding XI2. Until then, this is the better thing I can come up with, and in the end we'd very likely have to cater for input methods that don't do XI2 yet...
To help end users, I created a AUR package for Archlinux with Takao Fujiwara's patch: http://aur.archlinux.org/packages.php?ID=49763 At least we can use the XIM based IMs with that.
I've committed the patch now. Leaving this bug open to deal with the better solution outlined in comment 15
fixing title / downgrading severity to match
Personally, I think this bug can be closed. We strongly support IBus as the input method architecture for Linux, as XIM is heavily tied to X11. I honestly doubt we'll see the solution of comment 15 implemented any time soon — and none appeared in the last 6 years. If somebody wants to pick this up, they can ask for this bug to be re-opened.