After upgrading to F12 occassionally the keyboard freezes. Also unplugging/replugging the USB-keyboard doesn't help. No keys seem to work but mouse etc. still does. So I can use the mouse to logout. When the login-manager appears, keyboard works fine again and I can relogin as usual. Windows-manager used: KDE I hope my guess that xorg-drv-keyboard might be at fault is correct. I'm unfortunately not able to identify a faulty component and there don't seem to be reproducible steps for the error. But it happens around 2 times a day during normal work.
A friend confirmed he experiences the exactly same but on F11. He said it occurs since around a week after "some of the latest updates".
Just found out that it looks like a bug which was experienced in F10 reappeared. Could it be #490934 is related? (Was just closed due to F10 being EOL.)
I see this bug roughly once a week. One curious thing happens when the keyboard focus is lost: the eclipse drop down menus won't appear. That is, if I click on menu item such as File or Edit it will highlight but the drop down menu won't appear. The eclipse is directly from eclipse.org and not from fedora. I have a gut feeling that this bug appears while I'm doing copy-pasting in GTK application (usually the eclipse). Killing the eclipse wont help. Ctrl-Alt-Fx and caps lock led work fine. I can type in other terminals but there is no way to enter text with keyboard in KDE (mouse copy-pasting works).
Workaround: Try moving _any_ window, by holding down the Alt-key and moving your mouse. Upon releaseing the drag (releasing the Alt-key) the keyboard always seems to revert back to normal for me. Still didn't figure out completely what causes this - but copy-n-paste-operations involving GTK-programs under KDE *might* be an option. Happens to me around once a day meanwhile.
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf, if available), output of the dmesg command, system log (/var/log/messages), and X server log file (/var/log/Xorg.*.log) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Same problem here... We are in the proces of deploying 250> desktops from SLED10.x into FEDORA12.x When using the combination: KDE displaymanager + GNOME environment the keyboard freezes after loging. When reverting back using KDE dm + KDE environtment ... no problem. Already removed nouveau (with we think is buggy, nog suitable for professional environent ...) and installed nvidia (and blacklisted noveau in every thinkable way) It seems to be not an problem using xorg... but the combination of GNOME and xorg .... [sysinfo:] Linux bhw185 2.6.31.12-174.2.22.fc12.i686 #1 SMP Fri Feb 19 19:26:06 UTC 2010 i686 i686 i386 GNU/Linux [dmesg] nvidiafb 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 nvidiafb 0000:01:00.0: BAR 3: can't reserve mem region [0xf0000000-0xf1ffffff] nvidiafb: cannot request PCI regions nvidia 0000:01:00.0: setting latency timer to 64 NVRM: loading NVIDIA UNIX x86 Kernel Module 173.14.22 Sun Nov 8 20:26:31 PST 2009 [x log] (II) config/hal: Adding input device AT Translated Set 2 keyboard (II) LoadModule: "evdev" (II) Loading /usr/lib/xorg/modules/input/evdev_drv.so (II) Module evdev: vendor="X.Org Foundation" compiled for 1.7.1, module version = 2.3.2 Module class: X.Org XInput Driver ABI class: X.Org XInput driver, version 7.0 (**) AT Translated Set 2 keyboard: always reports core events (**) AT Translated Set 2 keyboard: Device: "/dev/input/event3" (II) AT Translated Set 2 keyboard: Found keys (II) AT Translated Set 2 keyboard: Configuring as keyboard (II) XINPUT: Adding extended input device "AT Translated Set 2 keyboard" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "pc105+inet" (**) Option "xkb_layout" "us" (**) Option "xkb_options" "terminate:ctrl_alt_bksp" (II) config/hal: Adding input device HID 05af:0301 **) HID 05af:0301: Device: "/dev/input/event6" (II) HID 05af:0301: Found keys (II) HID 05af:0301: Configuring as keyboard (II) XINPUT: Adding extended input device "HID 05af:0301" (type: KEYBOARD) (**) Option "xkb_rules" "evdev" (**) Option "xkb_model" "evdev" (**) Option "xkb_layout" "us"
the problem is almost certainly a stuck grab, where some application requests a keyboard grab but then never releases this grab. Currently, we know that there's one issue where this can be triggered (see Bug 543647) and that issue has been adddressed in xorg-x11-server-1.7.4-6. I just updated the patch so if you could try xorg-x11-server-1.7.5-4 that would be much appreciated. I'm not sure if it is the exact same issue though. The build is available from koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=2012520 At this point, we need to narrow down when this happens and what clients are affected. Given that the keyboard-based window movement still works I am inclined to think that metacity may be involved. Killing metacity (e.g. from the tty) may release the stuck grab. Please also check if a switch to the tty alone is enough already. If it is metaciy, it could be a result of alt-tab as well.
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Can't reproduce it anymore. Works with updated packages it seems.