Bug 1580 - Let libX11 forward XNSpotLocation event to XIM server in OnTheSpot mode
Summary: Let libX11 forward XNSpotLocation event to XIM server in OnTheSpot mode
Alias: None
Product: xorg
Classification: Unclassified
Component: Lib/Xlib (show other bugs)
Version: git
Hardware: Other Linux (All)
: high normal
Assignee: Egbert Eich
QA Contact: Xorg Project Team
Depends on:
Reported: 2004-10-10 08:19 UTC by Stefan Dirsch
Modified: 2016-02-28 00:50 UTC (History)
8 users (show)

See Also:
i915 platform:
i915 features:

p_xim_spot.diff (421 bytes, patch)
2004-10-10 08:19 UTC, Stefan Dirsch
no flags Details | Splinter Review
process pended callback events before processing seticvalues (1.70 KB, patch)
2005-02-04 13:41 UTC, Hidetoshi Tajima
no flags Details | Splinter Review

Description Stefan Dirsch 2004-10-10 08:19:36 UTC
I'll attach a patch for this.
Comment 1 Stefan Dirsch 2004-10-10 08:19:58 UTC
Created attachment 1063 [details] [review]
Comment 2 Stefan Dirsch 2004-10-11 02:35:56 UTC
Needs to be discussed outside of Bugzilla first.  
Comment 3 Stefan Dirsch 2004-10-12 08:32:45 UTC
reopen for discussion. 
Comment 4 Stefan Dirsch 2004-10-12 08:33:50 UTC
Needs to be discussed with Mike and James Su. 
Comment 5 Alan Coopersmith 2004-10-16 08:49:39 UTC
I asked Sun's Xi18n experts about this patch, and got this answer:
   The patch is good. Solaris already has this in the xi18n layer.
Comment 6 Stefan Dirsch 2004-10-16 09:27:46 UTC
More details by James 
--> http://bugzilla.suse.de/show_bug.cgi?id=38203 
This enables xim input methods can get the input spot location in gtk2 apps. 
Gtk2 only uses OffTheSpot mode if the XIM server does not support OnTheSpot 
mode. In this situation, the XIM server can not receive the spot location 
event, so it can not locate the candidate window to its correct position. So 
many XIM servers will stick the candidate window to the lower left corner of 
the client window. If the client window is very large, then it will be very 
In fact, it's also true for OnTheSpot mode. But most of XIM servers will be 
mad, if I turn on the SpotLocation event for OnTheSpot mode. I don't know 
what's the matter with it. Theoretically it should also be ok to turn on this 
event for OnTheSpot mode, but there must be some bugs in Xlib to prevent us 
from doing this. 
And further more, many applications do not support OnTheSpot mode very well, 
for example OpenOffice, Evolution etc. It's better to turn off the OnTheSpot 
support by default for these apps. 
Comment 7 Egbert Eich 2004-10-17 01:42:24 UTC
I will take it and commit it.
Thanks Alan for verifying!
BTW: who is the original author?
Comment 8 Egbert Eich 2004-10-17 01:42:54 UTC
I'll take it.
Comment 9 Stefan Dirsch 2004-10-17 03:45:57 UTC
Author is James Su. 
Comment 10 Egbert Eich 2004-10-18 02:30:32 UTC
Prepared for commit. Will credit James as author.
Comment 11 Egbert Eich 2004-10-18 07:29:18 UTC
     * lib/X11/imRm.c:
        Turn on forwarding XNSpotLocation event to XIM server in
        OffTheSpot and Root mode (bugzilla #1580, James Su).
Comment 12 Hidetoshi Tajima 2004-12-03 10:51:14 UTC
Reading this and the patch again, I wonder why not using XNSpotLocation for
OnTheSpot as well. Reopeing the bug for this.

I assume XNSpotLocation is not open for OnTheSpot at current
for the two reasons, but I'm rather against both of the reasons.

  - If some XIM servers are known to be mad by getting XNSpotLocation in 
    OnTheSpot mode, it sounds like they are bugs of these XIM servers and 
    should be fixed in their end.
  - OnTheSpot is used in many modern apps, such as Gtk+2.0 apps, 
    OpenOffice.org, Java, hence I consider XNSpotLocation support is
    more important than any other styles.
Comment 13 Hidetoshi Tajima 2004-12-03 10:52:20 UTC
And change Summary according to my request for OnTheSpot mode.
Comment 14 James Su 2004-12-03 19:13:42 UTC
  Most client won't process the SpotLocation event when using OnTheSpot mode,
and some clients will got crasy if they receive such event.
  And there might be some bugs in Xlib or X Server which will cause the events
are sent to client with wrong order.
Comment 15 Hidetoshi Tajima 2004-12-03 19:39:31 UTC
I don't think any XIM clients are supposed to receive XNSpotLocation as 
events from XIM server. It's client's call to set or get XNSpotLocation, by calling
XSetICValues() and XGetICValues().
  What exactly do you see those clients misbehave by saying "they will get
crazy" with XNSpotLocation in OnTheSpot mode? Do they crash or hang? Wwill you name
what these clients are? I'd want to give a try.
Comment 16 James Su 2004-12-03 20:18:00 UTC
  Sorry, my mistake. I mean, many clients are not capable to send SpotLocation
event in OnTheSpot mode. At least I remembered that mozilla does not send it.
  And the clients will have strange behaviour when enable sending SpotLocation
event to XIM server because of wrong events order returned from XIM Server (it's
the bug of Xlib or X Server indeed. The order will get wrong even if XIM Server
send the events with correct order.)

James Su
Comment 17 Hidetoshi Tajima 2004-12-06 12:38:37 UTC
Thanks, we're getting closer. As for mozilla, the late version uses Gtk+-2.0's
GtkIMContext, and XIM backend(im-xim.so) sets XNSpotLocation in the OnTheSpot mode.
I confirmed this with the Mozilla version 1.7. With the modified ximcp.so.2
which enables XNSpotLocation in OnTheSpot, XIM lookup choice window displays
near the spot location, while it doesn't with the original xim.so.2.

About events disordering, do you means XIM protocols from the XIM server are
received by XIM clients in wrong order, and this happens by enabling
XNSpotLocation in the OnTheSpot? If yes, can you help me reproduce this? I'd
want to know the version of libX11, and XIMserver and type of linux distros, and
any relavent information to reproduce. And, most important thing, what type of
events are actually disordered, and what failure actually occurs by the disorder.
Comment 18 James Su 2004-12-06 22:49:09 UTC
Yes, that's what I mean. I encountered such issue on XFree86 4.3.0, kernel
2.6.0, SCIM and kinput2. But I forgot what kind of events were actually
disordered. I just remembered that kinput2 stopped to work after XNSpotLocation
was enabled for OnTheSpot mode.

I don't know if it has been fixed in recent libX11 version.

You may try as many XIM servers and clients as possible to see if they all works
Comment 19 Hidetoshi Tajima 2005-02-04 13:37:59 UTC
James. Finally, I could find an issue when XNSpotLocation is enabled
for XIMPreditCallbacks. I believe this is what you're seeing as well.

The issue is delay of preedit draw callback(s), isn't it? Sometimes preedit
draw callback are not called timlely at the present event, but are called
at next events. E.g, suppose 'abc' should make "ABC" in preedit, but
actually it only makes "AB". But, a next operation, say, next key event or so,
will make it "ABC". Kind of?

I've made up a fix so that preedit draw callbacks, which are pended in
a pending callback queue *before* XSetICValues(XNSpotLocation) is called, 
should be processed timely. I'm attaching the patch. Can you please read and
review, and see if this could resolve this issue? (If your issue is different
from this, please kindly teach me again...)
Comment 20 Hidetoshi Tajima 2005-02-04 13:41:46 UTC
Created attachment 1833 [details] [review]
process pended callback events before processing seticvalues
Comment 21 James Su 2005-02-04 18:21:32 UTC
  It should be the issue that I encountered. I'll try your patch as soon as
possible. But I'll on my vacation during Feb 6-20. I'll try to give you result
before Feb 25.
  Thank you very much.

James Su
Comment 22 James Su 2005-03-04 06:19:54 UTC
  Sorry for late. I tested the patch in comment #20. The events disorder issue
was disappeared after applying this patch.
  Thank you very much.
Comment 23 Egbert Eich 2005-04-11 01:33:07 UTC
Hidetoshi, I don't fully understand your patch in attachment #1833 [details] [review].
I understand the need to call _XimProcessPendingCallbacks() in
XimProtoSetICValues(). However I don't quite understand the 
if (ic->private.proto.process_pend_cb_que)
shield. It seems serve as a semaphore to protect the function from getting
called twice. I would assume that this can only happen in a multi threaded
Disregarding the fact that XIM is not fully thread save this semaphore is not
atomic and therefore racey. Although this may never become a real issue and may
well be on the same level as all the other issues of XIM.
I don't fully understand why we need to do 
ic->private.proto.process_pend_cb_que = False;
in _XimPutCbIntoQueue(). The only place where this semaphore is set to TRUE is
in _XimProcessPendingCallbacks(). It is set to TRUE when the function is entered
and reset to FALSE when exited. Since the patch adds this in the case of 
(pcbq == (XimPendingCallback)NULL) this can only make a difference between
ic->private.proto.pend_cb_que = pcbq->next; and the next iteration of while()
in _XimProcessPendingCallbacks(). 
It should not be required for initialization as the entire structure gets
bezeroed() at _XimProtoCreateIC() or _XimLocalCreateIC(). Maybe I'm missing
something here. Did you actually encounter a situation where this is needed?
Furthermore I'm concerned that adding another field to XicProtoPrivateRec will
change XIcRec which seems to be part of a public API. The change will destroy
the ABI compatibility of this interface. 
I don't think this fact should be overlooked.

Comment 24 Hidetoshi Tajima 2005-04-11 15:16:04 UTC
Egbert, I'd need to debug this again - two months since then, I forgot
the reason why I needed the process_pend_cb_que. I'll get back to you soon.
A quick question for now, I don't see what ABI compatibility will be break by
adding a memeber in XicProtoPrivateRec, which is private to a perticular XIM
implementation (XIMCP). Can you explain? 
Comment 25 Egbert Eich 2005-04-13 08:48:53 UTC
You may be right. The public part exposed thru a public ABI seems to be the XICRec.
The XicRec contains an additional private part which changes in size due to your
change - however this should not matter for functions that only access the
public part. I got confused from XICReg and XicRec.
Maybe we are save here after all.
Comment 26 Daniel Stone 2007-02-27 01:24:22 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 27 Stefan Dirsch 2007-11-04 08:34:57 UTC
Comment 28 Stefan Dirsch 2008-11-22 12:40:03 UTC
I don't see any of the proposed patches/hunks applied. Also SuSE/Novell never did. Let's close this one as WONTFIX.
Comment 29 Henry Hu 2016-02-28 00:50:47 UTC
This problem still presents in libX11 1.6.3
When using rxvt-unicode and fcitx with the OnTheSpot input style (enable OnTheSpot support in fcitx-xim, run urxvt with "urxvt -pt OnTheSpot"), the candidate list is displayed at the lower left corner of the window, instead of the current cursor position.

On the other hand, if I enable passing XNSpotLocation to the IM server (change line 1950 from
), then the position of the candidate list is correct.
I've tried it with recent fcitx and ibus and it works well.

Please reopen the bug and fix the problem.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.