Bug 541049 - Occassional keyboard-freezes until logout/relogin
Occassional keyboard-freezes until logout/relogin
Product: Fedora
Classification: Fedora
Component: xorg-x11-server (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Peter Hutterer
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2009-11-24 15:24 EST by Stefan Neufeind
Modified: 2018-04-11 03:53 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-05-11 16:08:37 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stefan Neufeind 2009-11-24 15:24:08 EST
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.
Comment 1 Stefan Neufeind 2009-12-01 05:05:19 EST
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".
Comment 2 Stefan Neufeind 2009-12-18 04:25:46 EST
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.)
Comment 3 Juha Heljoranta 2010-01-05 09:59:54 EST
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).
Comment 4 Stefan Neufeind 2010-02-11 18:41:36 EST
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.
Comment 5 Matěj Cepl 2010-02-12 12:34:06 EST
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.
Comment 6 Remke 2010-02-24 05:52:07 EST
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 ....

Linux bhw185 #1 SMP Fri Feb 19 19:26:06 UTC 2010 i686 i686 i386 GNU/Linux

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"
Comment 7 Peter Hutterer 2010-02-24 19:52:57 EST
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:

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.
Comment 8 Matěj Cepl 2010-05-11 12:54:38 EDT
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.
Comment 9 Stefan Neufeind 2010-05-11 16:08:37 EDT
Can't reproduce it anymore. Works with updated packages it seems.

Note You need to log in before you can comment on or make changes to this bug.