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

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

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.

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

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.

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

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.

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

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.

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.

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.

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.

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

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.

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.

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.

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

I filed a separate bug report (Bug #147689).

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

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.

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!

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

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.

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

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

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.

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).

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.

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

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.

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!

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

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.

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

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.
>

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

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.

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

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'?

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.

-----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-----

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

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.

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.

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

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

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.

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.

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

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.

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.

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