Red Hat Bugzilla – Bug 194537
forwarding keycode 0 causing not working on XIM
Last modified: 2014-06-18 05:08:24 EDT
scim-hangul does not work correctly.
If preedit string is available and input focus is moved to
another window, preedit string is committed.
After that, when input focus is moved back to the window,
XIM cannot handle first key input.
Test instruction is as follows:
(It requires Korean locale and Korean fonts)
1. Login with Korean locale
2. Open gnome-terminal
3. Check XMODIFIERS and LANG environment variables
$ echo $XMODIFIERS
$ echo $LANG
4. Start gtk-demo with XIM
$ GTK_IM_MODULE=xim gtk-demo
5. Double click "Application main window" on left-side list.
"Application main window" will be displayed
6. Move input focus to text widget
7. Turn on SCIM with Ctrl+Space
5. Type "dlf", Korean character is displayed
6. Click desktop window to move window focus
7. Click "Application main window" window to move back window
8. Type "d", then "d" is displayed <== PROBLEM
$ uname -a
Linux host207 2.6.16-1.2122_FC5 #1 Sun May 21 15:01:01
EDT 2006 i686 i686 i386 GNU/Linux
$ cat /etc/issue
Fedora Core release 5 (Bordeaux)
Kernel \r on an \m
$ cat /etc/fedora-release
Fedora Core release 5 (Bordeaux)
Our test machine has following RPM packages:
Pardon me for living, but please explain to me why this bug in scim-*/scim-
hangul is filed against 'xorg-x11' and not scim-hangul? You have to scroll past
a lot of entries on the web form to get to the "x"'s, and "s" is surely on the
way there, no?
correcting component. unsure why there is such a dramatic reaction to a mistake
Heh no no, that there reaction, above, wasn't dramatic.. that was the '
admirable restraint' reaction. I deleted my post three times before I had it
toned down enough to be marginally diplomatic.
And the reason behind it is mostly because of wasted time - if you want your
bug to get fixed, file it against the component having the problem. If my car
breaks down I don't tell Triple-A that I need a new tire when the problem is
that the axle fell off. I mean, I'm quite certain you want your time wasted as
little as do the rest of us, so likewise when we come to help it's more
rewarding for us to be able to get right to it. :-)
------- Additional Comments From firstname.lastname@example.org 2006-06-12 14:20 EST -------
Right component, but assigned to wrong owner now... Be sure to click
"reassign bug to owner and QA contact of selected component" when changing
components to ensure the maintainers of the right component get the bug
emails, and it shows up in their bug queries.
Hope this helps.
Created attachment 131030 [details]
----- Additional Comments From email@example.com 2006-06-16 06:08 EDT -------
1st proposed patch.
Please find the first proposed patch.
This is the same IM "commit" issue as LTC bug #24055.
Sorry, is this issue also happened on another IMEs?
------- Additional Comments From firstname.lastname@example.org 2006-06-16 11:04 EDT -------
(In reply to comment #14)
> Sorry, is this issue also happened on another IMEs?
In case of FC5, I saw this problem with scim-hangul IME only.
I tried scim-anthy, scim-tables..., these were OK.
how about another IMs? if this issue happens on scim-hangul only, it may be able
to be fixed in scim-hangul. even if not, your patch may affects other IMs I'm
afraid. I've confirmed that this issue happens on my machine, so I'll let me
look into scim-hangul first and will figure this out.
----- Additional Comments From email@example.com 2006-06-19 01:26 EDT -------
> In case of FC5, I saw this problem with scim-hangul IME only.
This comment is fact. But other IMEs just do not return a preediting string
when an associated IC unset the focus.
The same problem was occured with SCIM-Anthy-0.8.
SCIM-Anthy-1.0 stopped to return a preediting string as committed string when
IC focus is out. Therefore, the problem was not occured.
Please refer AnthyInstance::focus_out() method in src/scim_anthy_imengine.cpp
file for both 0.8 and 1.0 releases.
In 0.8 code, action_commit() is called to return the preedit string as a
committed string. But in 1.0 code, it no longer calls action_commit().
This problem is occured when an IM server try to return a preediting string
when the current IC is focus out.
Please find the following sequence between SCIM and Client (include Xlib).
1. <Client> User hit some keys for preediting.
2. <Client> User operates to focus out from the client application.
3. <Client Xlib> Unregister all KeyPress/KeyRelease filter.
4. <SCIM> Receive IC focus out.
5. <SCIM> Send the current preediting string to <Client>
6. <Client Xlib> Recieve the preediting string as
Commited string (CommitRecv).
7. <Client Xlib> PutBack dummy (fabricated) key press event with
keycode=0. The current IC is marked FABRICATED.
8. <Client Xlib> _XimProtoMb/WcLookupString is called and obtain
the preediting (commited) string.
9. <Client> User operates to focus in to the client application.
10. <Client> User hit a key (KeyPress event).
11. <Client Xlib> The KeyPress event passed to _XimProtoKeyPressFilter.
But the IC is still marked FABRICATED, then the filter returns
12. <Clinet Xlib> The KeyPress event is processed as normal
(non IM related) key event, then the client displays alphabet
The fundamental issue is when we should turne off the FABRICATED flag of
the IC, if IC unset the focus.
Usually, _XimProtoKeypress/KeyreleaseFilter turns off the FABRICATED flag.
It works fine when IC has the focus and those filters are registered.
But when unset the IC focus, then those filters are unregistered and no
longer called until the IC has the focus again.
So, the IC still has FABLICATED flag when the next key press is occured.
My idea is that the FABLICATED flag is used for handling committed string.
So, the flag must be turned off when the committed string handle is over.
The original code calls _XimUnregCommitInfo() when the handling is over.
Therefore, I added to turn off the FABLICATED flag in there
If you have any other sophisticated solutions, it would be welcome.
What |Removed |Added
------- Additional Comments From firstname.lastname@example.org 2006-06-19 01:32 EDT -------
I tested Sugiyama-san's patch on FC5(i386), it worked fine.
ok, reassigning back to libX11.
btw I meant to say, have you tried another IMs (but not IM Engines) other than
scim? such as kinput2/skk/uim/nabi/xcin etc etc. you will have to make sure if
your patch won't breaks any IMs working. actually XIM specification was little
vague and each IMs had a habit. your explanation sounds good though, modifying
the low layer code must be carefully applied since this issue isn't necessarly
happened on every IMs.
----- Additional Comments From email@example.com 2006-06-20 19:46 EDT -------
I checked the fix with the following other IMs through XIM protocol.
o kinput2 + canna
I used "xterm" and "gtk-demo" for the test.
I checked regualar text input with IM and set/unset IC operation during
preediting. All of them works OK.
None of them returns "preediting" string when IC unset focus. So, regular text
input is a primary checkpoint.
Patches should be submitted to X.Org upstream at http://bugs.freedesktop.org
in the 'xorg' component, so that the proper subsystem maintainers can review
and scrutinize them. Once a patch has been accepted by X.Org and committed
to CVS, we'll update to the new upstream release.
Thanks in advance.
Setting status to "NEEDINFO_REPORTER" and awaiting X.Org bug URL for tracking.
Please let us know the upstream X.Org bug report for this issue so we
can track the progress occuring with this being accepted into the
Once it has been reviewed by the upstream maintainers and accepted
into the X.Org repository, we will include it in the next Fedora
build of the package. Hopefully this can happen prior to the
Fedora Core 6 test2 release to ensure maximum test coverage.
Thanks in advance.
This looks similar to RH bug 201284, which has been upstream as
The above patch does not seem to affect bug 201284 though,
so I guess they are separate issues.
Glen, do you know if a bug has been filed yet for this upstream
at FreeDesktop bugzilla under libX11?
I confirmed the above patch also fixes the same problem with
Japanese input when using scim-anthy.
I reported it upstream at freedesktop now.
Please confirm if the bug is "devel" related because the OS details Glen Johnson
got in the first comment was Fedora Core release 5 (Bordeaux).
------- Additional Comments From firstname.lastname@example.org 2006-08-29 23:22 EDT -------
(In reply to comment #29)
> ----- Additional Comments From email@example.com 2006-08-29 22:13 EST ------
> Please confirm if the bug is "devel" related because the OS details Glen
> got in the first comment was Fedora Core release 5 (Bordeaux).
This problem is happened on FC5 and FC6 test2.
Please provide URL of submitted bug at upstream which referred.
Caius, it is below in External Bugzilla References.
What |Removed |Added
------- Additional Comments From firstname.lastname@example.org (prefers email at email@example.com) 2006-09-05 17:11 EDT -------
https://bugs.freedesktop.org/show_bug.cgi?id=8059 worked for me
I have added the patch now, but to be honest I don't really understand this
code, so basically I am trusting that this patch was tested with various input
methods and found not to break.
Fixed in rawhide, if/when releng moves the new package.