Bug 488713

Well, this is definitely not kbd issue. Reassigning to libgxim, because it seems from your description that it should be related to it. If not, probably should be reassigned to fontconfig. I'll stay in CC.

Please give me more info like

1. what's your locale
2. what's your XKB settings? e.g. grep -i xkb_ /var/log/Xorg.0.log or cut and paste appropriate logs there
3. even better if you can give me a debug log. follow steps described in http://code.google.com/p/libgxim/wiki/HowToDebug and type the above thing you are facing issue.

I will do that debug thing when i have brushed my teeth... :-)

here is my locale (or what did u mean?)
and
those xkb_ lines from the log (is it bad that i use evdev? i tinkered my own keyboard by writing to the evdev of my PS/2 keyboard... *giggle*):
> locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
> grep -i xkb_ /var/log/Xorg.0.log
(**) Option "xkb_rules" "evdev"
(**) Option "xkb_model" "evdev"
(**) Option "xkb_layout" "de"
(**) Option "xkb_variant" "nodeadkeys"
> 

-Arne

ohoh...
the bug disappeared...
i can use the keyboard now in that java app, too... :-)

here is that debug file:
> cat /tmp/fc10.bug488713.log
[BUG][ 1236330144.590383] No real implementation of `XIM_RESET_IC' or any errors occurred.
[BUG][ 1236330145.926629] No real implementation of `XIM_RESET_IC' or any errors occurred.
[BUG][ 1236330146.000149] No real implementation of `XIM_RESET_IC' or any errors occurred.
[BUG][ 1236330147.174338] No real implementation of `XIM_RESET_IC' or any errors occurred.
[BUG][ 1236330148.069950] No real implementation of `XIM_RESET_IC' or any errors occurred.
E[ 1236330150.389397]:No implementation or an error occurred in XIM_DESTROY_IC [imid: 5, icid: 3]
E[ 1236330150.390406]:No implementation or an error occurred in XIM_DESTROY_IC [imid: 5, icid: 4]
[BUG][ 1236330212.025526] No real implementation of `XIM_RESET_IC' or any errors occurred.
[BUG][ 1236330214.871036] No real implementation of `XIM_RESET_IC' or any errors occurred.
[BUG][ 1236330241.686588] No real implementation of `XIM_RESET_IC' or any errors occurred.
E[ 1236330242.976135]:No implementation or an error occurred in XIM_DESTROY_IC [imid: 5, icid: 5]
E[ 1236330242.979060]:No implementation or an error occurred in XIM_DESTROY_IC [imid: 5, icid: 6]
E[ 1236330269.487816]:No implementation or an error occurred in XIM_DESTROY_IC [imid: 6, icid: 1]
E[ 1236330304.674816]:No implementation or an error occurred in XIM_DESTROY_IC [imid: 6, icid: 2]
[BUG][ 1236330331.400708] No real implementation of `XIM_RESET_IC' or any errors occurred.
[BUG][ 1236330338.140552] No real implementation of `XIM_RESET_IC' or any errors occurred.
E[ 1236330338.293058]:No implementation or an error occurred in XIM_DESTROY_IC [imid: 6, icid: 3]
E[ 1236330338.296877]:No implementation or an error occurred in XIM_DESTROY_IC [imid: 6, icid: 4]
> 

maybe libgxim needed multiple restarts?

this bug can be closed... :-)
sorry for the noise...

thx.

-Arne

Well, I'm afraid no. those logs probably means imsettings-applet may somehow failed to create a proxy instance that actually bridges events between applications and XIM server. there may be any clues in .xsession-errors. in this case you can't type anything that need any supports from IM. otherwise works because libgxim sends back appropriate error responses.

You'll see the same issue after restarting your desktop. to get the full debug log at the beginning, please try to put LIBGXIM_DEBUG=all before applet is bringing up from /etc/X11/xinit/xinitrc.d/50-xinput.sh.

Anyway, I can test this issue now with what you've provided.

(In reply to comment #3)
> I will do that debug thing when i have brushed my teeth... :-)
> 
> here is my locale (or what did u mean?)
> and
> those xkb_ lines from the log (is it bad that i use evdev? i tinkered my own
> keyboard by writing to the evdev of my PS/2 keyboard... *giggle*):
> > locale
> LANG=en_US.UTF-8
> LC_CTYPE="en_US.UTF-8"
> LC_NUMERIC="en_US.UTF-8"
> LC_TIME="en_US.UTF-8"
> LC_COLLATE="en_US.UTF-8"
> LC_MONETARY="en_US.UTF-8"
> LC_MESSAGES="en_US.UTF-8"
> LC_PAPER="en_US.UTF-8"
> LC_NAME="en_US.UTF-8"
> LC_ADDRESS="en_US.UTF-8"
> LC_TELEPHONE="en_US.UTF-8"
> LC_MEASUREMENT="en_US.UTF-8"
> LC_IDENTIFICATION="en_US.UTF-8"
> LC_ALL=
> > grep -i xkb_ /var/log/Xorg.0.log
> (**) Option "xkb_rules" "evdev"
> (**) Option "xkb_model" "evdev"
> (**) Option "xkb_layout" "de"
> (**) Option "xkb_variant" "nodeadkeys"
> > 
> 
> -Arne  

So you've chosen English (United States) for a language and Germany for a keyboard at gdm right?

yes: just the keyboard layout is german... 

ohoh

the bug is back...
but i dont know, what i did different now...
i tried it again and again, but it doesn't happen again...
i think, it is a bug in JAVA or that special java app...
i just don't use that app for text editing anymore... :-)

the .xsession-errors file contains these lines:
Acceleration key: disabled
Acceleration key: disabled
[BUG][ 1236337276.283831] No real implementation of `XIM_RESET_IC' or any errors occurred.
[BUG][ 1236337278.058820] No real implementation of `XIM_RESET_IC' or any errors occurred.
W[ 1236337807.607399]:No such tasks is waiting for: 62, 0 [xim_proxy_protocol_real_xim_sync_reply,XimProxyConnection]
E[ 1236338619.019750]:No implementation or an error occurred in XIM_DESTROY_IC [imid: 2, icid: 3]
E[ 1236338619.022703]:No implementation or an error occurred in XIM_DESTROY_IC [imid: 2, icid: 4]
W[ 1236338738.186608]:No such tasks is waiting for: 62, 0 [xim_proxy_protocol_real_xim_sync_reply,XimProxyConnection]
W[ 1236338738.187472]:No such tasks is waiting for: 62, 0 [xim_proxy_protocol_real_xim_sync_reply,XimProxyConnection]
[BUG][ 1236338746.936863] No real implementation of `XIM_RESET_IC' or any errors occurred.

-Arne

(In reply to comment #7)
> yes: just the keyboard layout is german... 

Thanks. I don't have a german keyboard so just tried by changing a layout from gnome-keyboard-properties. and I'm not sure if I could configure a keyboard but what I've got from xev is:
KeyPress event, serial 30, synthetic NO, window 0x4600001,
    root 0xbc, subw 0x0, time 1466533848, (386,8), root:(392,77),
    state 0x0, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen: YES,
    XKeysymToKeycode returns keycode: 92
    XLookupString gives 0 bytes:
    XmbLookupString gives 0 bytes:
    XFilterEvent returns: False

KeyPress event, serial 30, synthetic NO, window 0x4600001,
    root 0xbc, subw 0x0, time 1466533864, (386,8), root:(392,77),
    state 0x80, keycode 16 (keysym 0x7b, braceleft), same_screen YES,
    XLookupString gives 1 bytes: (7b) "{"
    XmbLookupString gives 1 bytes: (7b) "{"
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x4600001,
    root 0xbc, subw 0x0, time 1466533984, (386,8), root:(392,77),
    state 0x80, keycode 16 (keysym 0x7b, braceleft), same_screen YES,
    XLookupString gives 1 bytes: (7b) "{"
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x4600001,
    root 0xbc, subw 0x0, time 1466534200, (386,8), root:(392,77),
    state 0x80, keycode 108 (keysym 0xfe03, ISO_Level3_Shift), same_screen YES,
    XKeysymToKeycode returns keycode: 92
    XLookupString gives 0 bytes:
    XFilterEvent returns: False

Does this look good for you?

And one more question..
When you can see this issue on that java app, can you also reproduce this issue on xterm say?

yes, xev says the same here, when i press "{"...

the first time, i mentioned that, the second life client had the same keyboard malfunction... and then i restarted the X server... i do not remember if i tried to use the keyboard in another client...

once the java app got stuck so badly, that i had to press CTRL+F2 and kill that java process there, because i could not open a gnome-terminal... :-)

today that keyboard malfunction was limited to that single instance of that java app (arduino IDE), so that i did not need to restart the X server... i will try to find a way to reproduce that error with high probability...

-arne

it happened again, that the application got stuck in a dialog box so badly, that i had to use that CTRL+F2 trick again...

but:
i found no way to reproduce that...
indeed the java app worked for about 30 minutes now without a problem...

i think, it is no bug in libgxim, that causes this problem...
maybe there is some buffer overflow in the "java vm" sometimes or so?

-arne

"good" news everybody:
i found new symptoms of the bug:
1.
gnome-terminal & firefox:
no problem with typing... keys act as i expect them to act...

2.
second life client ( ELF 32-bit LSB executable):
in the first minutes i could type as usual (without problems)...
then a key-press was delayed until the next key was pressed...
example:
i press "a" - nothing shows up
i press "b" - just the "a" shows up
i press "c" - just the "b" shows up
...

this bug never happened before the update at 2009-03-03...
it is funny to type like that, but i prefer the other (normal) method... :-)

can u tell already what might cause this?
is there something in libgxim that can act as a buffer or so?

is it still advised that i try that changed "/etc/X11/xinit/xinitrc.d/50-xinput.sh" script? where would i find the debug messages then? in ~/.xsession-errors?

-Arne

a new symptom:
when i press the "?", it is repeated again and again until i press another key,
although i just pressed it a short moment...
same for "!", '"', "§", "$%&/()*>", "ABCD", ... (seems like all shift+XXX combinations get repeated)
but not "<", "abcd", ...

-Arne

now the behaviour changed:
every key gets repeated, when the bug happens...
e. g.: ESC, BACKSPACE, a, 9, o, t, ...

-Arne

Arne, please try to figure out this issue on xterm rather than gnome-terminal unless you bring it up with GTK_IM_MODULE=xim explicitly. it uses a different path for input by default. so it's pointless to say "it works on gnome-terminal but not on java app". if it works but not on other X apps, please mention that. I'm keen to fix it and improve a compatibility..

(In reply to comment #11)
> this bug never happened before the update at 2009-03-03...

Hmm, I don't think the update introduced this issue because if it worked, keyevents got stuck. there may be any reasons your input didn't passed through libgxim and it just looked like working perhaps. dunno.

> can u tell already what might cause this?
> is there something in libgxim that can act as a buffer or so?

I can't tell you by the off hand though, if it matches any key sequences in XKB, it's likely to not appear what you type.

> is it still advised that i try that changed
> "/etc/X11/xinit/xinitrc.d/50-xinput.sh" script? where would i find the debug
> messages then? in ~/.xsession-errors?

Yes, please. correctly any places where's before gnome-session is running would be good. and yes.
just do export LIBGXIM_DEBUG=all
please note that you'll see a lot of debugging message in .xsession-errors. I'd recommend you to turn off that after you finished to gather information.

it still just says this:
E[ 1236553355.707614]:No implementation or an error occurred in XIM_DESTROY_IC [imid: 1, icid: 1]
W[ 1236554620.327503]:No such tasks is waiting for: 62, 0 [xim_proxy_protocol_real_xim_sync_reply,XimProxyConnection]
E[ 1236554971.149827]:No implementation or an error occurred in XIM_DESTROY_IC [imid: 1, icid: 2]

possibly i should return to the previous kernel?
or is it unlikely that the new kernel causes this?

-Arne

oh
i didn't do an "export LIBGXIM_DEBUG=all"...
just "LIBGXIM_DEBUG=all"...
that is most likely a difference in bash?

-arne

Not really. while you got the above logs with it, it should works at least. to figure out why you got that error, just run LIBGXIM_DEBUG=all imsettings-applet after killing it once and attach a full debug log may be helpful.

Created attachment 334476 [details]
output of "LIBGXIM_DEBUG=all imsettings-applet >& /tmp/imsettings-applet.log"

in the last seconds each keypress event showed up after 2 further keypresses...

Thanks. I'll have a look.

BTW I've finally tried to run Arduino on Fedora 10. although I got a compiler error, I can type '{' without any problems so far. and I'm sure all of the key events are proceeded through libgxim/imsettings with disabiling IM feature.

hopefully I'll get any clues from your log.

it often (not always) takes some time after the AltGr key combination, if u want to c the bug... maybe up to 100 other keystrokes...

btw: i tested it with the previous kernel (2.6.27.15-170.2.24.fc10.x86_64) and it resulted in the same behaviour...

-Arne

Ah, ok. I see. probably all of you are facing the same issue then. guess you've sent too much key events by keep pressing a key say?

hm
possibly...
i held the AltGr Key + "{" down for a while...

i will test if it triggers the bug...:
nope... keeping a key pressed does not result in that bug...


should i try the january version of libgxim?
although just that "&0x7f" changed?
what might be the consequences of that "&0x7f"?


-Arne

Maybe not all of java apps but some java apps has sent X events with funny event type. looking at other XIM implementation, they mask the event type on X wired event with 0x7f. that's it. this caused keyevent lost issue, i.e. it may looks like application freezes. so if you have never seen that, it should be irrelevant for you.

the old package (libgxim-0.3.1-1.fc10.x86_64.rpm) works quite fine... :-)
but i cant type the euro sign in second life (€)... but i can type "{" in second life...
in that java app i cant type "€{}"...
in firefox everything is fine...
*arne puzzled* :-)
but it is ok now...

-Arne

Are you sure libgxim-0.3.1-1.fc10 really works? you should be able to see the event flows with the above debugging steps if it works.

FWIW I have pre-testing package for issue I've mentioned at Comment #23. if you are interested in, you can test that too for this issue. :)

testing package is available here:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1236736

with the current libgxim i saw that the mouse focus was stuck to the java app...

but with the old libgxim (libgxim-0.3.1-1.fc10.x86_64.rpm) i never had that...

-arne

(In reply to comment #26)
> with the current libgxim i saw that the mouse focus was stuck to the java
> app...
> 
> but with the old libgxim (libgxim-0.3.1-1.fc10.x86_64.rpm) i never had that...
> 
> -arne  

Can you exactly answer questions at Comment #25, please?

Does that java app still get stuck after even installing libgxim-0.3.2-4.fc10 and imsettings-0.105.1-3.fc10.3 (download it from a URL at Comment #25) and reboot?

Does that java app works with libgxim-0.3.1-1.fc10 and which version of imsettings?
No difference between imsettings-0.105.1-2.fc10 and imsettings-0.105.1-3.fc10.3?

After downgrading libgxim to 0.3.1-1.fc10 and reboot, kill imsettings-applet once and run again as LIBGXIM_DEBUG=all imsettings-applet --disable-xsettings. and can you see any logs when you run java app?

> After downgrading libgxim to 0.3.1-1.fc10 and reboot, kill imsettings-applet
> once and run again as LIBGXIM_DEBUG=all imsettings-applet --disable-xsettings.
> and can you see any logs when you run java app?
>
No, there r no logs... neither with that java app nor with that second life client...

> Does that java app works with libgxim-0.3.1-1.fc10 and which version of
> imsettings?
>
imsettings is untouched... it is the one provided by fc10:
# yum list imsettings\*
Installed Packages
imsettings.x86_64                       0.105.1-2.fc10                 installed
imsettings-libs.x86_64                  0.105.1-2.fc10                 installed

the java app works fine (i. e.: no unwanted repetitions, quick response), BUT: AltGr-characters (like "{}€") show up as if AltGr wasn't pressed ("70e")...

now i will test 
imsettings-0.105.1-3.fc10.3
with
imsettings-libs-0.105.1-3.fc10.3.x86_64.rpm
BUT:
i can't reboot... i will just log off and in again and check pids...

-arne

(In reply to comment #28)
> > After downgrading libgxim to 0.3.1-1.fc10 and reboot, kill imsettings-applet
> > once and run again as LIBGXIM_DEBUG=all imsettings-applet --disable-xsettings.
> > and can you see any logs when you run java app?
> >
> No, there r no logs... neither with that java app nor with that second life
> client...

Ok, actually it was supposed to work but wasn't. this was actually a bug in libgxim and fixed in -4. but there are also another bug in imsettings. and I'm trying to fix it and pre-testing package is for that.

> i can't reboot... i will just log off and in again and check pids...

if you can ensure old process is surely gone and new one is running, that's ok.

> Does that java app still get stuck after even installing libgxim-0.3.2-4.fc10
> and imsettings-0.105.1-3.fc10.3 (download it from a URL at Comment #25) and
> reboot?
>
hm
i didn't test with reboot... i just logged off & in, which should purge references to previous lib versions, too...

i used these packages for the test now:
# yum list installed libgxim\* imsettings\*
Installed Packages
imsettings.x86_64                     0.105.1-2.fc10                   installed
imsettings.x86_64                     0.105.1-3.fc10.3                 installed
imsettings-libs.x86_64                0.105.1-2.fc10                   installed
imsettings-libs.x86_64                0.105.1-3.fc10.3                 installed
libgxim.x86_64                        0.3.2-4.fc10                     installed

the java app didn't get stuck in this test...
before this test that java app got stuck very seldom anyhow, so that the test results doesn't say so much possibly...
funnily the AltGr-characters worked without problems (no delayed events, no unwanted repetitions, all pressed keys produced the proper character), too... :-)

i will test that today and give another about the results report tomorrow...

looks cool...

-arne

i tested 0.3.2-4.fc10 (libgxim.x86_64) and 0.105.1-3.fc10.3 (imsettings.x86_64/imsettings-libs.x86_64) several times with 2 applications that had problems before (arduino java app + second life client)...

there were no problems anymore...

thank you! :-)

-arne

*** This bug has been marked as a duplicate of bug 483840 ***