GNOME Bugzilla – Bug 135031
Gnome-settings-daemon locks up keyboard
Last modified: 2004-12-22 21:47:04 UTC
gnome-settings-daemon has (with no immediatly apparant cause) started reproducably freezing my keyboard up, to the point where any input (to a gnome control, plain X control, or xev) fails. Contexts with a cursor generally see the cursor blink. Xev reports: ------------------------------------------------------------- FocusOut event, serial 30, synthetic NO, window 0x3600002, mode NotifyGrab, detail NotifyAncestor FocusIn event, serial 30, synthetic NO, window 0x3600002, mode NotifyUngrab, detail NotifyAncestor KeymapNotify event, serial 30, synthetic NO, window 0x0, keys: 2 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 ------------------------------------------------------------- Tracking the problem in gnome-settings-daemon with gdb led me to the following: - a breakpoint on gnome-settings-multimedia-keys.c:222 will stop program before the keyboard locks. - at this point, one 'next' is safe. - the following next fails. - at line 223 'if (grab_key_real (key, gdk_screen_get_root_window (screen), grab, result) == FALSE)', gdb reports: ------------------------------------------------------------- (gdb) ptype key type = struct { guint keysym; guint state; guint keycode; } * (gdb) print key->keysym $9 = 269025042 (gdb) print key->state $10 = 0 (gdb) print key->keycode $11 = 0 (gdb) ------------------------------------------------------------- Willing to diagnose further with assistance, of course. Marking critical and TARGET2.6.0, since I'd call the complete disabling of the keyboard for all apps, gnome or otherwise, a crasher. Modify if you disagree.
So, um. How do you reproduce?
I still don't know what got my system started on this behavior, and I haven't found a way to stop it. Running a gdm failsafe session, then starting gnome-settings-daemon (directly, or indirectly via gnome-session) triggers the problem, apparantly immediatly upon execution. I'm still new to gdb, but I hope what I listed there was useful. Either the values passed on to grab_key_real() are already bad and the problem is earlier, or the problem is later on.
Jody? Any idea?
Hmm, sounds like something is screwing xkb's notion of the keyboard up. Lets start with the obvious things. 1) Upgrade your distro to the non experimental 4.3.0-3 xfree packages that way we'll at least have the same x server. 2) Specificly the output of xprop -root | grep XKB and gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb and xdpyinfo | head
I am currently running the latest version of debian available in sid (4.3.0-3). atrus@agaeris:~$ xprop -root | grep XKB _XKB_RULES_NAMES(STRING) = "xfree86", "itouchin", "dvorak", "", "" atrus@agaeris:~$ gconftool-2 -R /desktop/gnome/peripherals/keyboard/xkb layouts = [dvorak] model = itouchin overrideSettings = false options = [] atrus@agaeris:~$ xdpyinfo | head name of display: :0.0 version number: 11.0 vendor string: The XFree86 Project, Inc vendor release number: 40300001 XFree86 version: 4.3.0.1 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7
Look at this: atrus@agaeris:~$ xprop -root | grep XKB _XKB_RULES_NAMES(STRING) = "xfree86", "itouchin", "dvorak", "", "" This is a bit strange - there is no _XKB_RULES_NAMES_BACKUP property - which is always set by g-s-d at startup. Do you see any xkb-related error messages at startup? gconf configuration looks pretty much ok.
That was the output of those commands before running gnome-settings-daemon. After gnome-settings-daemon has run (and therefore after my keyboard is broken) I see the following results: _XKB_RULES_NAMES_BACKUP(STRING) = "xfree86", "itouchin", "dvorak", "", "" _XKB_RULES_NAMES(STRING) = "xfree86", "itouchin", "dvorak", "", "" ............... layouts = [dvorak] model = itouchin overrideSettings = false options = [] ............... name of display: :0.0 version number: 11.0 vendor string: The XFree86 Project, Inc vendor release number: 40300001 XFree86 version: 4.3.0.1 maximum request size: 4194300 bytes motion buffer size: 256 bitmap unit, bit order, padding: 32, LSBFirst, 32 image byte order: LSBFirst number of supported pixmap formats: 7
???? How did you do it - "before running g-s-d"? g-s-d runs as one of the first things in the session AFAIK - so how could you get something before running it? Anyway, the configuration looks reasonable. Still do not quite understand what could break xkb...:(
For the purposes of this bug, i'm not running gnome-session. Running gnome-session produces the same problem, ie, starting gnome-settings-daemon and subsequently killing the keyboard.
I see now. Anyway, the configuration looks pretty reasonable and I do not see why would media keys make g-s-d go bananas... Will try to play around (it is pity I do not have real "itouchin" keyboard around).
I have the same problem with my microsoft media keyboard. Key's always work in the "keyboard shortcut" dialog when in other program's they do not. Setting the launch webbrowser key to disabled makes all keys work again after logging in and out. All other keys have no effect on the bug
Tryed your config - it was ok for me. It seems someone should loan me these keyboards:/
Same thing here.... gnome-keybinding-properties is the only app that appears to see keys when this problem is present, and unbinding the internet shortcut key instantly restores the keyboard to normal function. Binding it again instantly reproduces the problem.
After further testing, logging out and logging back in caused the problem again. Each time, disabling another of my keyboard's extra keys fixed the problem, until the next logout/login, at which point the problem would strike again. Once all the non-standard keys had been removed from gnome-keybinding-properties, gnome-keybinding-properties (and subsequently, gnome-settings-daemon and gnome-session) started working as expected again. Uneducated guess: Is it possible that (somehow) multimedia key bindings are causing something in gnome-settings-daemon (gnome-settings-multimedia-keys.c ?) to forcefully grab the focus away from all the regular x apps (thus relating to the spurious xev focus events in my original report?)
At least the part of g-s-d which belongs to gswitchit does not grab anything. Do not know about other parts though.
I didn't have the exact same problems that this bug describes, but some related ones. I'm attaching a patch that seems to fix the problems for me.
Created attachment 25676 [details] [review] Call XKeysymToKeycode if the keyval is non-zero
Maintainers, can we give this patch some review-love for 2.6.0, please?
This patch does appear to address my original issue. Multimedia keys are now working great.
I've got a similar patch that goes a bit further.
Created attachment 25768 [details] [review] A restructuing of chris' proposal and some additional checks
My modified variant of chris' patch has been applied.
*** Bug 134613 has been marked as a duplicate of this bug. ***