[Gutsy] scim: input freezes in various applications under XIM mode

Bug #66104 reported by Wenzhuo Zhang on 2006-10-14
234
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Fedora
Fix Released
High
libx11 (Ubuntu)
High
Timo Aaltonen
Hardy
High
Timo Aaltonen
scim (Debian)
Fix Released
Unknown
scim (Ubuntu)
Medium
Unassigned
Hardy
Medium
Unassigned

Bug Description

In gutsy, the default mode of scim (detemined by im-switch's settings "scim") uses XIM mode. This may cause problems in some applications and make it impossible to input anything, even if you choose the English/Keyboard input method. This happens most often in nautilus, but is also seen in gedit, gnome-terminal, etc.

This bug has been around for a long time, it only became more visible because of the change in the default settings of scim and the Ubuntu package.

There are two work arounds for this problem:

1. If you do not use any programs linked to libstdc++5 (very few of the Ubuntu official packages do, one know exception is the fglrx video driver for ATi cards; but plenty of third-party programs do, such as firefox downloaded from www.mozilla.com, and Adobe's PDF reader), you can use the scim-immodule setting in im-switch. To change the im-switch setting, just run "im-switch -s scim-immodule" command.

2. If you do not use the deadkeys (often seen on European keyboards, and if you don't know what a deadkey is, you are not using it), you can change scim's "/FrontEnd/X11/Dynamic" setting. The procedure to change this setting is:
(a) Set scim not to start automatically (because it's useless to change the configuration file when scim is running) using the command "im-switch -s none". Log out and re-login.
(b) Edit your ~/.scim/config configuration file, change the /FrontEnd/X11/Dynamic option to true.
(c) Reset scim to start automatically with command "im-switch -s scim". Log out and re-login.

If you are using programs linked to libstdc++5 as well as deadkeys, there is no known workaround for you. You may try the scim-bridge settings (you need to install scim-bridge-* packages first), but it's not clear whether it works or not (and I don't even know if there is a written scim-bridge setting for im-switch of not).

Description of problem:
Sometimes a KDE app will not accept inputs anymore (even input method is not
activated). The only thing I can do to have input again is change to "Simple
Composing Input Method" which is a test input method module in Qt, or restart
the application.

How reproducible:
not everytime

Steps to Reproduce:
1. Use a KDE app long enough

Actual results:
No inputs were outputted

Expected results:
Output english letters

Yep, I think I saw this on KDE desktop while testing this morning.

Need to test with another IM to see if it is a kde/qt problem or
issue with scim. XIM seems to work fine with other apps.

Reproducible in FC6 devel using the following test case by Choe Hwanjin:

1. $ export XMODIFIERS=@im=SCIM
2. $ export GTK_IM_MODULE=xim
3. $ gedit/kedit
4. press ctrl-N
5. try to type something

See http://sourceforge.net/mailarchive/forum.php?thread_id=30112584&forum_id=43684
for more details. It seems like that this is a xorg-x11 regression according to
discussion there.

Reproduced on fc5 and fc6. RHEL4 and fc4 seem ok.

gedit loops with kinput2 and uim xim on rawhide.

Adding upstream bug from the thread referred to in comment #3 above for tracking:
  https://bugs.freedesktop.org/show_bug.cgi?id=7869

(Problem also occurs with gcin fwiw.)

I'm not easily able to reproduce the problem on kde apps.

A workaround for gtk xim at least seems to be to set "/FrontEnd/X11/Dynamic = true"
in .scim/config (but that breaks deadkey support under XIM direct input).

This can also easily be reproduced with kinput2 and gedit.

1. setup kinpu2 and restart desktop
2. run gedit
3. activate kinput2 with Shift-Space and press Ctrl-n

at this point gedit goes into a hard loop.

Also reproduced with libX11-0.99.3 fwiw.

Here is a backtrace of where gedit loops with kinput2:

#0 XIfEvent (dpy=0x6ca790, event=0x7fff84fd6000,
    predicate=0x2aaaaab427a0 <_CheckCMEvent>, arg=0x10b4000 " \220ݪ�*")
    at IfEvent.c:58
#1 0x00002aaaaab42cea in _XimXRead (im=0x10b4000, recv_buf=0x7fff84fd61f0 "",
    buf_len=2048, ret_len=0x7fff84fd6144) at imTrX.c:446
#2 0x00002aaaaab45f86 in _XimReadData (im=0x10b4000, len=0x7fff84fd61a6,
    buf=0x7fff84fd61f0 "", buf_size=2048) at imTransR.c:154
#3 0x00002aaaaab46323 in _XimRead (im=0x10b4000, len=0x7fff84fd71fe,
    buf=0x7fff84fd61f0 "", buf_size=2048,
    predicate=0x2aaaaab48c20 <_XimSyncCheck>, arg=0x10b8800 "\200\217ݪ�*")
    at imTransR.c:231
#4 0x00002aaaaab49d0e in _XimForwardEvent (ic=0x10b8800, ev=0x7fff84fd7290,
    sync=1) at imDefLkup.c:296
#5 0x00002aaaaab39c8b in _XimFilterKeypress (d=<value optimized out>,
    w=<value optimized out>, ev=0x7fff84fd7290,
    client_data=<value optimized out>) at imDefFlt.c:187
#6 0x00002aaaaaaf9104 in XFilterEvent (ev=0x7fff84fd7290,
    window=<value optimized out>) at FilterEv.c:99
#7 0x00002aaab4e7fecd in gtk_im_context_xim_register_type ()
   from /usr/lib64/gtk-2.0/2.10.0/immodules/im-xim.so

(In reply to comment #8)
> I'm not easily able to reproduce the problem on kde apps.

I can reproduce this fine now with "QT_IM_MODULE=xim kedit".

Hi Wenzhuo,

On Sat, Oct 14, 2006 at 01:22:25PM -0000, Wenzhuo Zhang wrote:
>
> I filed a bug (#65489) against gnome-terminal. But since I've seen input
> freezing in firefox and gaim as well, I am opening a new bug against
> scim.

Thanks for bringing this issue to my attention.

> I am using edgy, and scim under en_US.UTF-8 locale. Sometimes, I cannot
> type anything into applications, such as gnome-terminal, firefox and
> gaim.

Yes I have heard about this issue from Debian users for quite a long
time, however I can never reliably reproduce it. Now you are giving a
detailed procedure to reproduce, I'll look at it more carefully when I
have time.

I have also a few more questions for you:

> Steps to reproduce:
>
> 1. Make sure you are using scim. If you are not already, type "im-switch
> -s scim-pinyin" in a gnome terminal. Log out Gnome and then log back in.

As edgy's scim-pinyin package uses a peculiar way to set up input method
environment, this step won't give the same results on different systems.
Would you please show the results of the following commands in
gnome-terminal after you log back in?

$ dpkg -l scim-bridge
$ echo $GTK_IM_MODULE

Also, would you please also give the result of the following two
commands?

$ grep "X11/Dynamic" /etc/scim/config
$ grep "X11/Dynamic" ~/.scim/config

[snipped]
> For me, it's a show blocker, because it's very annoying and causes work
> loss.

I hope I can provide a workaround for you after you've given the
necessary information.

Thanks,
Ming
2006.10.15

Wenzhuo Zhang (wenzhuo) wrote :

Ming Hua wrote:
> As edgy's scim-pinyin package uses a peculiar way to set up input method
> environment, this step won't give the same results on different systems.
> Would you please show the results of the following commands in
> gnome-terminal after you log back in?
>
> $ dpkg -l scim-bridge
> $ echo $GTK_IM_MODULE

wenzhuo@thinkpad:~$ dpkg -l scim-bridge
No packages found matching scim-bridge.
wenzhuo@thinkpad:~$ echo $GTK_IM_MODULE
xim

> Also, would you please also give the result of the following two
> commands?
>
> $ grep "X11/Dynamic" /etc/scim/config
> $ grep "X11/Dynamic" ~/.scim/config

wenzhuo@thinkpad:~$ grep "X11/Dynamic" /etc/scim/config
/FrontEnd/X11/Dynamic = false
wenzhuo@thinkpad:~$ grep "X11/Dynamic" ~/.scim/config
/FrontEnd/X11/Dynamic = false

> I hope I can provide a workaround for you after you've given the
> necessary information.

Thanks,
Wenzhuo

I've seen input lockups in gaim and gnome-terminal for several times since the last post.

It is not reproduceable in my rawhide. (20061018)
(according to comment #2)

According to the procedures mentioned in comment #2; though it is not
reproduceable, the scim also could not able to be activated as well.

FYI, clone of this bug for RHEL5: bug #209285 could be reproduced instead.

On Mon, Oct 16, 2006 at 03:21:07AM -0000, Wenzhuo Zhang wrote:
>
> wenzhuo@thinkpad:~$ dpkg -l scim-bridge
> No packages found matching scim-bridge.
> wenzhuo@thinkpad:~$ echo $GTK_IM_MODULE
> xim
>
> wenzhuo@thinkpad:~$ grep "X11/Dynamic" /etc/scim/config
> /FrontEnd/X11/Dynamic = false
> wenzhuo@thinkpad:~$ grep "X11/Dynamic" ~/.scim/config
> /FrontEnd/X11/Dynamic = false

Good, good. Exactly the situation I know the workaround for. :-)

What you really need to do is only change the /FrontEnd/X11/Dynamic
option in your ~/.scim/config to true. However it's a little tricky as
scim always rewrite its configuration files on exit. So I give the
following complicated procedure for the workaround:

1. Set scim not to start automatically: run "im-switch -s none". Log
out and re-login.

2. Edit your ~/.scim/config configuration file, change the
/FrontEnd/X11/Dynamic option to true.

3. Reset scim to start automatically: run "im-switch -s scim-pinyin".
Log out and re-login.

Now there shouldn't be keyboard input lock-up anymore. However this
breaks deadkeys used in a lot of European keyboard layout. Although if
you only need to input Chinese and English, deadkeys should not be a
concern to you.

Please report back whether this workaround works for you or not.
Thanks.

Ming
2006.10.17

(In reply to comment #17)
> the scim also could not able to be activated as well.

The XIM client needs to be running in order to reproduce this.

Ming, thank you very much for the workaround. It works and I can no longer reproduce the input lockups in gnome-terminal.

But for the sake of Ubuntu, I believe a real fix needs to be found ASAP, preferrably before the official release of edgy.

Ming Hua (minghua) wrote :

Thanks for testing, Wenzhuo. I'll add a few comments in bug #65489.

Ming Hua (minghua) wrote :

Copy my comments from bug #65489 as that bug is marked as duplicate of this bug now:

What Wenzhuo experienced here is a probably a well known (at least among input method people) bug. This bug usually shows up when user uses XIM (therefore using other GTK or Qt IM module seems to make this bug disappear), and is not restricted in GNOME. The discussions on SCIM mailing list and Redhat bugzilla suggest it is a bug in Xorg.

The workaround I gave here only applys to SCIM. This problem is more visible in Ubuntu than in Debian because Ubuntu's scim package set the /FrontEnd/X11/Dynamic configuration to false by default to get better support for deadkeys. Both upstream tarball and Debian package set this to true by default, and this bug won't show up in the default configuration.

As far as I can see, this is what is going on:

- application gets normal keyboard event from X server
- application forwards event to IM server
- application unfocuses IM context
- application receives processed event from IM server, that requires a sync
  reply.
- xim never sees this event since it has unregistered the filter
  when it unfocused the ic. So no sync reply is sent.
- application focuses another IC, and sends events, which the IM server then
  ignores since it hasn't gotten the SYNC_REPLY.

However, there is another weird bug: Just pressing and releasing Ctrl on a gedit
window causes it to loop infinitely processing keypresses. I'm not sure what's
going on with that or whether it's related.

Some more information about the infinite loop: It looks like

- gtk+ receives a keypress (Ctrl)

- gedit sees the event, and propagates it to the TextView,
  which calls XFilterEvent()

- XFilterEvent() forwards the event to scim and returns FALSE.

- A fabricated event then arrives from scim

- gedit sends this to XFilterEvent()

- xim ignores this event, since it knows that it was fabricated

- gedit then sends the event once again to XFilterEvent()

- xim doesn't think this one is fabricated, so it forwards it to scim

- a fabricated event arrives, and gedit once again filters it twice.

So the root of the infinite loop bug is that gedit calls XFilterEvent() twice
for a single event. Or maybe the root cause is that XIM thinks generating events
behind the application's back is not stupid.

Created attachment 139010
Reproducer

So the infinite loop is GEdit understandably misunderstanding XIM. The getting
stuck bug is reproduced by this gtk+ program which just switches focus in
response to a keypress, before gtk+ gets a chance to deal with the fabricated
event.

I guess the fix is this:

When a fabricated event arrives for an unfocused input context, instead of
ignoring it, process it, and pass it on to the application, which should be
prepared for events appearing on unfocused ic's anyway, due to the asynchronous
nature of X.

Thanks, Soeren. Yup, your reproducer works just fine for me too.

By "works just fine for me", I assume you mean that it reproduces the bug.

I don't really see how this could be a regression though. Could you try if the
reproducer also reproduces on RHEL4?

(In reply to comment #24)
> By "works just fine for me", I assume you mean that it reproduces the bug.

Yes, that's right.

> I don't really see how this could be a regression though. Could you try if the
> reproducer also reproduces on RHEL4?

Yes it reproduces on rhel4 too, but gedit and kate don't exhibit the problem there.

Tested on rawhide, the problem has been fixed.

devel branch & FC6 branch are patched and built.

libX11-1.0.3-5.fc6 has been pushed for fc6, which should resolve this issue. If these problems are still present in this version, then please make note of it in this bug report.

Wenzhuo Zhang (wenzhuo) wrote :

Bug still seen in Gutsy Tribe-2, and Ming Hua's workaround still works.

Wenzhuo Zhang (wenzhuo) wrote :

Marking it confirmed as it has been confirmed by Ming Hua. With the default scim config (/FrontEnd/X11/Dynamic = false), keyboard input locks up much more often in Gutsy than in previous releases. Please raise the bug importance.

Changed in scim:
status: New → Confirmed
Wenzhuo Zhang (wenzhuo) on 2007-07-04
Changed in scim:
assignee: nobody → desktop-bugs
Ming Hua (minghua) wrote :

Ubuntu haven been using /FrontEnd/X11/Dynamic=false as default since feisty. So if lock-up happens more often in gutsy, it's not because of this setting.

Wenzhuo Zhang (wenzhuo) wrote :

But changing /FrontEnd/X11/Dynamic to "true" can still get rid of the more frequent and more easily reproducible lockups in Gutsy. If the option is "false", keyboard input locks up so frequently as to make the Gutsy desktop barely usable, and I have to resize/minimize windows in order to restore keyboard input whenever lockup occurs.

Ming Hua (minghua) wrote :

I seem to be experiencing more such keyboard input freeze in Debian's 1.4.6-1 (compared with previous 1.4.4 releases) as well. The new upstream release 1.4.7 claims to have fixed such issues with firefox (I don't know the details), and in my own testing, 1.4.7 indeed freeze much less often than 1.4.6.

The 1.4.7-1 package was just uploaded to Debian unstable today. But there are some significant changes in Ubuntu's package, so some developer needs to do the merge work to bring 1.4.7 into gutsy.

Ming Hua (minghua) wrote :

Set importance to medium, as it seems to affect quite a few people and already has several duplicates.

Changed in scim:
importance: Undecided → Medium
Ming Hua (minghua) wrote :

Scim 1.4.7-1ubuntu1 is now merged in gutsy. Users with "FrontEnd/X11/Dynamic = true" setting shouldn't see keyboard lockups anymore. If that's not the case, please let me know.

Wenzhuo Zhang (wenzhuo) wrote :

No, 1.4.7-1ubuntu1 didn't fix the problem.

Steps to reproduce: Open gnome-terminal, press Ctrl-Shift-T consecutively for 5 times, without pausing between keystrokes.

Changed in scim:
status: Unknown → New
Ming Hua (minghua) wrote :

Mutiple users have confirmed that with scim 1.4.7, "FrontEnd/X11/Dynamic = true" completely fixes (works around) the lock-up issue.

So Wenzhuo, if you are still experiencing lock-up with "FrontEnd/X11/Dynamic = true" setting in up-to-date gutsy, please provide more information, such as which scim modules you have installed, how you started scim, etc.

Wenzhuo Zhang (wenzhuo) wrote :

It seems that I cannot reproduce the lockups with scim-1.4.7-1ubuntu1 now.

But I am sure it was still reproducible when I was writing my previous post. I didn't do anything special w.r.t. scim setup. I just installed from the latest tribe desktop CD, and installed Chinese language support, and typed "im-switch -s scim-pinyin" under English locale. Perhaps I forgot to change "FrontEnd/X11/Dynamic" or a recent Xorg update fixed the issue?

On Fri, Sep 14, 2007 at 01:21:44AM -0000, Wenzhuo Zhang wrote:
> It seems that I cannot reproduce the lockups with scim-1.4.7-1ubuntu1
> now.

Good.

> But I am sure it was still reproducible when I was writing my previous
> post. I didn't do anything special w.r.t. scim setup. I just installed
> from the latest tribe desktop CD, and installed Chinese language
> support, and typed "im-switch -s scim-pinyin" under English locale.

That seems quite normal. However "FrontEnd/X11/Dynamic" has been false
by default for gutsy since quite some time ago, so maybe you forgot to
change it to true.

> Perhaps I forgot to change "FrontEnd/X11/Dynamic" or a recent Xorg
> update fixed the issue?

The (alleged) X.org bug is not fixed AFAIK.

Ming
2007.09.15

I'm using scim 1.4.7-1ubuntu2 and X11/Dynamic set to true, but input for firefox still freezes sometimes. After some experimentation I came up with the following procedure to reproduce this:

* Open firefox and any other window
* In firefox press ctrl-n immediately followed by alt-tab, focusing the other window
* A new firefox window apears and the input is frozen.

If scim is not active input is not frozen.

On Thu, Sep 27, 2007 at 07:54:56PM -0000, Markus wrote:
> I'm using scim 1.4.7-1ubuntu2 and X11/Dynamic set to true, but input for
> firefox still freezes sometimes.

If the FrontEnd/X11/Dynamic setting doesn't workaround the problem, it's
a different bug, and please file a separate bug report.

> After some experimentation I came up
> with the following procedure to reproduce this:
>
> * Open firefox and any other window
> * In firefox press ctrl-n immediately followed by alt-tab, focusing
> the other window
> * A new firefox window apears and the input is frozen.
>
> If scim is not active input is not frozen.

And please give more information. Such as what scim-related package
you've installed, how do you start scim, etc.

Thanks,
Ming
2007.09.29

Arne Goetje (arnegoetje) wrote :

According to Debian bug #434180 the fedora patch for libx11 from https://bugs.freedesktop.org/show_bug.cgi?id=7869 fixes the issue.

Changed in libx11:
assignee: nobody → ubuntu-x-swat
Ming Hua (minghua) on 2007-10-11
description: updated

OK, I have put a patched libx11 package on my PPA.

in /etc/apt/sources.list add:

deb http://ppa.launchpad.net/arnegoetje/ubuntu gutsy main restricted universe multiverse
deb-src http://ppa.launchpad.net/arnegoetje/ubuntu gutsy main restricted universe multiverse

Alternatively browse the PPA:
http://ppa.launchpad.net/arnegoetje/

Please test the package and report back if it solves the problem or not, or creates new ones.

Changed in libx11:
assignee: ubuntu-x-swat → arnegoetje
status: New → In Progress
Changed in scim:
status: Confirmed → In Progress
Ming Hua (minghua) on 2007-10-12
description: updated
AkiraYB (brunoyb) wrote :

I was having problems with kdesktop_lock (not letting me to unlock) and sometimes in kopete (in password input)...

I tested this package in Kubuntu Gutsy and solved my problem... Thanks!

Don Cristóbal (doncristobal) wrote :

Two questions concerning the dynamic workaround.

Background: I use scim to input
* korean (hangul)
* modern greek (from the m17n package)
* latin text (german, french, spanish, english) from a swiss (german) keyboard (de/CH)

It basically works, but I suffer from the same irregular keyboard freezes that many people have reported above.

On the swiss keyboard i definitely need the dead keys for ~, ^ ï, ó, è, ñ and this sort of combinations.

1. Do I understand well that in my case the dynamic workaround does _not_ work?

2. What about Arne Goetjes patch? Can/should I use something like that as a beginner?

Thank you very much for taking care of this nasty problem!
Christoph

I can reproduce the error by opening a bash terminal and hitting ctrl+shift+t many times without pausing. When I do this, not _all_ keyboard input is blocked:
* ctrl-shift-t and ctrl-shift-w work (open and close tabs)
* I can copy text with ctrl-shift-c
* alt-F4 works, to close the window

Another weird behaviour:
What I do, variant A:
* I open one terminal
* I type some special character (ä, ü, à, etc.)
* I open a new terminal with ctrl-shift-n (sometimes it also happens when i switch to an existing terminal window)

What I do, variant B:
* I open one terminal (this works also with thunderbird)
* I open a new terminal with ctrl-shift-n
* Before the new terminal is ready, i type anything.

What i get:
* Both windows are basically keyboard blocked.
* But not really, I give some examples:
- close all terminals (works the same with thunderbird)
- open new terminal (I call it window1)
- ctrl-shift-n and without delay n (or any other letter). window2 appears.
- input (window2): hello. no reaction.
- alt-tab (works fine, focus changes to window1.)
- input: gugus (and here, at the first key stroke, the n appears in window2, along with the first g in window1!)
- alt-tab (focus on window2 again, nothing else happens.)
- alt-tab (focus on window1, nothing else)
- input: x (xugus appears, making sxugus).

It's not always exactly the same, but there seems to be something wrong with the assigning of input to a certain window if one does not wait for the window to completely build before one types. With Thunderbird, it's much worse because the same thing happens and there, the windows take more time to load.

I don't know it that's the same bug as the one above, but it seems to me.

Thanks to anyone who tries to find a solution to this!
Christoph

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christoph Bloch wrote:
> 2. What about Arne Goetjes patch? Can/should I use something like that
> as a beginner?

Christoph,

I know that the patch for libx11 is 'not the right patch' as upstream
put it. But it lowers the impact for me in the meantime until we have a
proper fix for this problem.
You can use it, but please report back if anything breaks because of this.
I hope I will have more information about this bug after next weekend. I
will try to grab some Xorg hackers at FOSSCAMP in Boston, MA.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHG/EEbp/QbmhdHowRAhx9AJ0bHUadYvlXNaeRATJ9xRJ+hpVIZgCdHnZ5
lWxYmlpkSFgetWUGkySx/Tk=
=W7Ux
-----END PGP SIGNATURE-----

On Sun, Oct 21, 2007 at 03:16:12PM -0000, Christoph Bloch wrote:
>
> On the swiss keyboard i definitely need the dead keys for ~, ^ ï, ó, è,
> ñ and this sort of combinations.
>
> 1. Do I understand well that in my case the dynamic workaround does
> _not_ work?

Yes. The workaround #2 mentioned here will break the deadkeys, so it
isn't for you.

You can still try workaround #1.

Ming
2007.10.21

On Sun, Oct 21, 2007 at 04:41:23PM -0000, Christoph Bloch wrote:
> I can reproduce the error by opening a bash terminal and hitting
> ctrl+shift+t many times without pausing. When I do this, not _all_
> keyboard input is blocked:
> * ctrl-shift-t and ctrl-shift-w work (open and close tabs)
> * I can copy text with ctrl-shift-c
> * alt-F4 works, to close the window

Doesn't surprise me. It's likely gnome-terminal or metacity intercepted
that key event, and it never got into the text input area, so scim
doesn't have a chance to mess things up.

> It's not always exactly the same, but there seems to be something wrong
> with the assigning of input to a certain window if one does not wait for
> the window to completely build before one types. With Thunderbird, it's
> much worse because the same thing happens and there, the windows take
> more time to load.
>
> I don't know it that's the same bug as the one above, but it seems to
> me.

It looks the same bug to me. If you read the Fedora bug you'll see the
bug is related to focus change.

Ming
2007.10.21

Ming and Arne: Thank your for the quick answers.

Arne: OK, I installed the patch (or, more precisely: I added your two lines to my apt sources and then the automatic updater proposed to install new versions of libx11-6 and libx11-data, which I accepted)

Some quick testing shows that I can probably use my linux (xubuntu 7.10) with scim now! Thunderbird does not get blocked every 2 minutes any more. Thanks!
I'll tell you if old or new problems occur.

Just a strange thing: Unlike other updates, the ppa versions keep showing in the automatic updater: "Other updates", 2 entries, both wanting to "upgrade" to the now installed version:
- "libx11-6, X11 client-side library, from version 2:1.1.1-1ubuntu5~ppa1 to 2:1.1.1-1ubuntu5~ppa1 (Size: 592 KB)"
- "libx11-data, X11 client-side library, from version 2:1.1.1-1ubuntu5~ppa1 to 2:1.1.1-1ubuntu5~ppa1 (Size: 201 KB)"

Is this something to worry about? Should I just delete the two entries from the apt sources list? Forgive me my beginner questions, and tell me to go somewhere else if this is not the right place to ask them :-)

Have a good day
Christoph

LogicalDash (logicaldash) wrote :

I've found another workaround for those who need to both use SCIM and enter weird European characters.

0. follow workaround 2 in the top post of this thread
1. install scim-uim and uim-latin
2. assign a Compose key if you don't already have one (in KDE this is done through System Settings -> Regional and Language -> Keyboard Layout -> Xkb Options -> Compose key position, there's something equivalent in GNOME)
3. restart X
4. turn on SCIM, switch to the input method Other -> UIM-Latin
5. press Compose, the character that looks closest to the accent mark you want, then the character you want the mark on top of
6. Pròfït!

I poked around the keymap file that UIM-latin uses, and it seems to be in the same format as regular xkbmap keyboard descriptions, so it seems like it should be fairly easy to swap in whatever keymap you want using scim-uim. However, it's 2:30am and I'm not going to try it right now.

Hope this helps someone.

LogicalDash (logicaldash) wrote :

Ah, yes! When I'm typing through UIM-latin, all dead keys work.

Gazrang (gazrang) wrote :

I also have this problem in Gusty Gibbon(Stable). Is there any progress on this bug?

404 (pnf) wrote :

I have this problem in 7.10 with Smart Common Input Method 1.4.7

Input freezes in epiphany, firefox, thunderbird, and sometimes even the gnome DEFAULT WINDOW MANAGEER (when create a new folder, i can't change the folder name).

This comes up only after i upgraded from 7.04 to 7.10.

Plareplane (plareplane) wrote :

Is the /FrontEnd/X11/Dynamic = true workaround supposed to stop this problem from happening at all? For me, it greatly reduces the occurences, but it still happens somewhat infrequently (which then requires changing input mode xim->scim or restarting the application, etc).

David Nemeskey (nemeskeyd) wrote :

Not to mention that the /FrontEnd/X11/Dynamic for me sometimes reverts to false in ~/.scim/config! I am using Kubuntu, but with the GTK panel (I can't even set it back to the KDE one, skim does not start :-) ). I don't know what causes the phenomenon, I used to think it changed when I changed the configuration, but apparently it doesn't hold. So maybe on new package installs? But it was definitely annoying.

Ming Hua (minghua) wrote :

Plareplane wrote on 2007-12-11:
> Is the /FrontEnd/X11/Dynamic = true workaround supposed to stop this problem from happening at all?

As far as I know, "/FrontEnd/X11/Dynamic=true" should completely work around the freezing input problem. If you are encountering freezes with this setting (or better, find a way to reproduce it), please file a separate bug.

On Tue, Dec 11, 2007 at 10:43:29PM -0000, David Nemeskey wrote:
>
> Not to mention that the /FrontEnd/X11/Dynamic for me sometimes reverts
> to false in ~/.scim/config! I am using Kubuntu, but with the GTK panel
> (I can't even set it back to the KDE one, skim does not start :-) ). I
> don't know what causes the phenomenon, I used to think it changed when I
> changed the configuration, but apparently it doesn't hold. So maybe on
> new package installs? But it was definitely annoying.

I have never heard of this problem before. Please file a separate bug
if you can reliably reproduce it.

Ming
2007.12.15

David Nemeskey (nemeskeyd) wrote :

Sorry, it haven't shown up for some time, so it may have been solved. Anyway, if I see it, I will try to provide some info here.

Juerd (ubuntu-juerd) wrote :

I had this problem with Inkscape. It often happened within a few minutes from starting Inkscape. Thanks for the workaround!

Here's a slightly simpler procedure for the same workaround:

1. Edit ~/.scim/config and set /FrontEnd/X11/Dynamic = true
2. Make the file immutable: sudo chattr +i ~/.scim/config
3. Logout, login.
4. Make the file mutable again: sude chattr -i ~/.scim/config

I personally choose to skip step 4, so I'm sure it won't be changed without my permission. Be careful with this, because that may become a problem if you forget about the +i or if a future version cannot cope with the current config format.

I don't understand why this bug is labelled only medium importance. It should be critical or important, at least. The workarounds don't really solve the problem.

This bug seriously threatens to scare off users who need multiple input methods - they may not be the majority, but they are an important segment of the linux population. On windows, input methods always work flawlessly for me.
If I look at the "critical" bugs, there are things like "synaptics touch pad(laptop) clicks too easily", and if I look at the "high" importance section, there are shocking problems like "Cannot create a user "håkan"".

Please don't get me wrong, I don't want to offend anyone. But I seriously believe that the standard, pre-installed input method changer in Ubuntu absolutely needs to work properly if Ubuntu wants to be what it wants to be.

I'm looking forward to downloading the solution to this problem, and thank you to anyone who helps to solve it!

Christoph

P.S. If there is anything dumb users like me can do to help, please tell us what to do!

Don Cristóbal (doncristobal) wrote :

I forgot to say: Someone might have found a solution to the problem, see http://bugs.freedesktop.org/show_bug.cgi?id=7869

Choe Hwanjin (choe-hwanjin) wrote :

I made patch for this problem also.
The patch will solve this problem in XIM server side.
You can read it on scim-devel mailing list:

http://sourceforge.net/mailarchive/message.php?msg_name=604f48110712260753o15834321ta3c62d7e8c65f91e%40mail.gmail.com

Oh, but unfortunately, the attachment link was broken.
I add the patch as an attachment here.

Changed in scim:
status: New → Confirmed
arekkusu (arekkusu-r) wrote :

I can confirm this on Gusty.

Installation from live cd with Japanese as langauge.
I nearly immediately found the bug while editing some folder's name in nautilus. (impossible to input test / have the close the application for it to work again)

I used the "set /FrontEnd/X11/Dynamic option to true" hack and haven't experience this problem since.

I just can't help to think something is really wrong when there is such a obvious problem (which for me pop up directly after installing) and nothing is being done about it... there has to be some real lack of support for that input system / japanese version of Ubuntu.

And I don't know what the exact criteria are for the importance of Ubuntu's bug but " Medium" seems completely inappropriate IMO

Yuanle Song (sylecn) wrote :

This has been very annoying. I can confirm this on gusty. It has not been fixed in official updates yet.

I have no deadkey and the second work around fix the problem.

try to modify ~/.scim/config,set
* */FrontEnd/X11/Dynamic = true

2008/2/22, 宋远乐 <email address hidden>:
>
> This has been very annoying. I can confirm this on gusty. It has not
> been fixed in official updates yet.
>
> I have no deadkey and the second work around fix the problem.
>
>
> --
> [Gutsy] scim: input freezes in various applications under XIM mode
> https://bugs.launchpad.net/bugs/66104
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
闲云孤鹤 - 清冷香中抱膝吟

Timo Aaltonen (tjaalton) wrote :

The patch from Fedora has been applied upstream, and is included in libX11 1.1.4. I'll add it on our package before Hardy beta.

Changed in libx11:
assignee: arnegoetje → tjaalton
importance: Undecided → High
milestone: none → ubuntu-8.04-beta
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libx11 - 2:1.1.3-1ubuntu2

---------------
libx11 (2:1.1.3-1ubuntu2) hardy; urgency=low

  * Add 100_dont_lock_recursively.diff from upstream to fix an xcb induced
    assert with apps like synergy.
  * Add 101_fix_xim_crash.diff to fix a crash when switching input
    context. (LP: #66104)

 -- Timo Aaltonen <email address hidden> Tue, 11 Mar 2008 21:37:01 +0200

Changed in libx11:
status: In Progress → Fix Released
Don Cristóbal (doncristobal) wrote :

Arne Goetje wrote on 2007-10-22:
> I know that the [fedora] patch for libx11 is 'not the right patch' as upstream
> put it. But it lowers the impact for me in the meantime until we have a
> proper fix for this problem.

Choe Hwanjin wrote on 2008-01-29:
> * a patch for XIM blocking problem. (2.7 KiB, text/plain)
> I made patch for this problem also.
> The patch will solve this problem in XIM server side.

Timo Aaltonen wrote on 2008-03-07: (permalink)
> The patch from Fedora has been applied upstream, and is included in libX11 1.1.4. I'll add it on our package before Hardy beta.

So have we picked the best patch available? Considering that people say the fedora patch is 'not the right patch'?

tknieper (tobias-knieper) wrote :

I upgraded my gutsy machine to the release candidate of hardy today. Thereby a few scim-* packages got installed which brought the described behaviour to my system. Most applications became nearly unusable, e.g. konsole. Also various dialogs in the mythtv application showed the mentioned behaviour. I fixed the issue for me by purging all scim-* packages that got installed due to the upgrade.

As the release candidate already contains libx11 (2:1.1.3-1ubuntu2) I doubt that the issue is already completely fixed. In fact my machine was still affected.

Arne Goetje (arnegoetje) wrote :

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

tknieper wrote:
> I upgraded my gutsy machine to the release candidate of hardy today.
> Thereby a few scim-* packages got installed which brought the described
> behaviour to my system. Most applications became nearly unusable, e.g.
> konsole. Also various dialogs in the mythtv application showed the
> mentioned behaviour. I fixed the issue for me by purging all scim-*
> packages that got installed due to the upgrade.
>
> As the release candidate already contains libx11 (2:1.1.3-1ubuntu2) I
> doubt that the issue is already completely fixed. In fact my machine was
> still affected.
>

if you do 'im-switch -l' in a terminal with all the scim packages
installed, what does it show?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIDCxCbp/QbmhdHowRAqhxAJ4lv/hX4SJ/HBS8duX062ns2bX3LQCcCIMn
+jPPBLBbscmkuYeNNbLFxjk=
=pAna
-----END PGP SIGNATURE-----

silencer (silencer-free-4ever) wrote :

Hi,

I'm running Ubuntu 8.04rc since today after an upgrade from 7.10 and I also have the same problme as explain !

Purging all scim packges does not fix the problem for me...

Any clues ?

Regards

silencer (silencer-free-4ever) wrote :

Hi again,

I made a mistake.

Problem does not come from Scim !

It come from another known issue with synergy when running the client on a linux with kernel >= 2.6.24-7 !

Sorry the noise.

Changed in scim:
assignee: desktop-bugs → nobody
assignee: desktop-bugs → nobody
Changed in scim:
status: Confirmed → Fix Released
Aaron Lu (aaron-aalu) wrote :

fedora 9(fully updated) now has this problem...
I can very reliably reproduce with gnome-terminal and gedit
I even filed a bug report against gnome-terminal some time ago but now find that it's scim that caused this keyboard lock up problem.

Arne Goetje (arnegoetje) wrote :

According to debbugs #434180 the bug was really in libx11, which has been fixed already. Therefor closing this bug.

Changed in scim:
status: In Progress → Fix Released
status: In Progress → Fix Released
epictetus (scottlsteele) wrote :

Does saying the bug is fixed mean that in the next release of Ubuntu, no one will have to use this work-around?

I experienced this problem in Opera (until I changed the Keyboard Setup to ``Opera 9.x Compatible'') and in Qt Creator.

-----
Ubuntu 8.10

Necrolin (spyb4573) wrote :

Well, if this bug was fixed then there's one just like it in the latest version of Ubuntu and in Fedora 10. Seems to mostly effect QT applications... KDE 4.2, VirtualBox, Opera, etc. It's annoying. The application starts and you can't write squat or you can write and then splat keyboard input disappears.

Walter Huf (hufman) wrote :

Hmmm, I agree about a similar bug existing. I was not able to use quickfind in Nautilus or Pidgin until I did workaround #2 and restarted my session.

donno (donno-speakeasy) wrote :

Similar bug here. I cannot type a lower-case "t" in Nautilus when logged in as a regular user, and the input language is English. Lower-case "t" works when Nautilus is invoked with sudo. Capital "T" works fine for all users. Oddly enough, lower-case "t" works if I switch to Anthy input.

I have no problems with "t" or any other character in other applications. Editing "/FrontEnd/X11/Dynamic = true" had no effect. Any input would be appreciated.

Ubuntu 9.04 Jaunty
SCIM 1.4.7
SCIM-bridge-Agent 0.4.14-2ubuntu5

phsamuel (phsamuel) wrote :

bug confirms and still exists in Jaunty. affecting python idle, kile, matlab... I get very tired of clicking back and forth another windows whenever I need to save in Kile. I ended up uninstalling scim and now only type chinese in virtualbox. I agree with Christopher (#41) that this bug should be critical or at least high importance.

Sam Grönblom (sgronblo-gmail) wrote :

I've been annoyed by this for quite a while. I'm running ubuntu 9.04 and have scim installed and have the x input method selected and the input keeps locking up very often. Right now I'm only running firefox, gnome-terminal and audacious. The input seems to lock up simply by alt-tabbing too quickly. I can enable input again by for example pressing my shortcut (shift+right) for next tab in gnome-terminal and then switching back to the previous one. I agree that this bug makes ubuntu look pretty bad for anyone who wants to type multiple languages.

Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/66104

tags: added: iso-testing
Changed in fedora:
importance: Unknown → High
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.