Bug 780948

Hello? This is a really serious issue for me, since it makes working on 12.2 almost unpredictable. It's as bad as if my machine just crashed, since the only way out is crashing all apps by forcibly restarting the X server :-/

Does the x200s have a PS/2 or USB keyboard?

xinput list
⎡ Virtual core pointer                    	id=2	[master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer              	id=4	[slave  pointer  (2)]
⎜   ↳ TPPS/2 IBM TrackPoint                   	id=13	[slave  pointer  (2)]
⎣ Virtual core keyboard                   	id=3	[master keyboard (2)]
    ↳ Virtual core XTEST keyboard             	id=5	[slave  keyboard (3)]
    ↳ Power Button                            	id=6	[slave  keyboard (3)]
    ↳ Video Bus                               	id=7	[slave  keyboard (3)]
    ↳ Sleep Button                            	id=8	[slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard            	id=12	[slave  keyboard (3)]
    ↳ ThinkPad Extra Buttons                  	id=14	[slave  keyboard (3)]

# lsusb
Bus 001 Device 054: ID 17ef:1005 Lenovo 
Bus 004 Device 002: ID 08ff:2810 AuthenTec, Inc. AES2810
Bus 004 Device 030: ID 0a5c:2145 Broadcom Corp. Bluetooth with Enhanced Data Rate II
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

So PS/2.

Attaching a USB keyboard during the freeze actually works. xinput query-state doesn't show anything strange though, and there's nothing in dmesg or anywhere else that hints at what is happening.

(I did try xinput disable/enable to see if that resets anything, but it doesn't.)

Does the LED on the keyboard react to pressing Caps Lock on the PS/2 keyboard and vice versa?

(In reply to comment #5)
> Does the LED on the keyboard react to pressing Caps Lock on the PS/2 keyboard
> and vice versa?

While unfrozen:

Activating capslock on the USB keyboard activates it on the PS/2 too, but does not set the LED there.

Activating capslock on the PS/2 keyboard activates it on the USB, but doesn't set the LED there.

(Funnily enough, pressing capslock on both will, in fact, turn capslock off, but leave the LED on one of the keyboards on. LED state appears to be local while capslock itself is global.)

I'm not sure how this relates to the freeze though?

During the most recent 'freeze', I noticed that it isn't quite a complete freeze. It's more like the system swallowing most events.

For example, if I hold a key for long enough, it will be entered. So I was actually able to see with xev that the keypresses would be registered 0-3s after I pressed (and held) the key down. The release of the keys registered immediately though.

This, somehow, did not appear to work with modifier keys - so ctrl-alt-f1 did not allow me to switch to a non-X console to see how the system behaved there. (I didn't have a USB keyboard around this time.)

(I don't think this is a hardware malfunction since restarting X immediately cures it.)

Hmm. Could it be that you sometimes accidentally enable slow-keys (an accessibility feature)? Some users were able to enable it by holding down Shift for 10 seconds or longer. I wasn't able to reproduce this ever though. Matthias wrote a small program to check the status, but I'm afraid I cannot find it any longer. You should be able to disable it again by pressing again Shift for 10 seconds or longer. Maybe this works for you. But this is only a shot in the dark ...

Stefan, you are a genius. This has been totally driving me nuts. Indeed, holding down shift for a while makes the system behave properly again! Thank you so much.

I am pretty sure though that I don't hold down shift for that long all the time this happened to me; I recall that it mostly happened while browsing or some such activity, and my typing behavior is unchanged from 12.1.

This seems to be GNOME related(?): http://library.gnome.org/users/gnome-help/3.3/a11y-slowkeys.html.en and 
https://bbs.archlinux.org/viewtopic.php?id=142721

How can I disable this annoying feature permanently?

Open the system settings (gnome-control-center), go to the "Universal Access" panel, go to the "Typing" tab. Is the "Turn on accessibility features from the keyboard" checkbox checked?

If yes, uncheck it, you're done.

If no, hrm...

According to that interface, that setting is off.

>gconftool-2 -a /desktop/gnome/accessibility/keyboard
 timeout_enable = false
 slowkeys_beep_reject = false
 bouncekeys_beep_reject = true
 stickykeys_modifier_beep = true
 slowkeys_delay = 300
 bouncekeys_delay = 300
 enable = false
 slowkeys_enable = false
 togglekeys_enable = false
 slowkeys_beep_press = true
 mousekeys_init_delay = 160
 slowkeys_beep_accept = true
 bouncekeys_enable = false
 stickykeys_enable = false
 mousekeys_max_speed = 750
 mousekeys_accel_time = 1200
 stickykeys_two_key_off = true
 timeout = 120
 feature_state_change_beep = false
 mousekeys_enable = false


(This was actually collected while I had enabled slowkeys using shift.)

(In reply to comment #11)
> According to that interface, that setting is off.
> 
> >gconftool-2 -a /desktop/gnome/accessibility/keyboard

You're displaying old GNOME 2 settings. What you want with GNOME 3 is:

  gsettings list-recursively org.gnome.desktop.a11y.keyboard

Ah. Silly me, I assumed commands would be compatible. ;-)

Anyway, that doesn't really change much, I think:

org.gnome.desktop.a11y.keyboard bouncekeys-beep-reject true
org.gnome.desktop.a11y.keyboard bouncekeys-delay 300
org.gnome.desktop.a11y.keyboard bouncekeys-enable false
org.gnome.desktop.a11y.keyboard disable-timeout 120
org.gnome.desktop.a11y.keyboard enable false
org.gnome.desktop.a11y.keyboard feature-state-change-beep false
org.gnome.desktop.a11y.keyboard mousekeys-accel-time 1200
org.gnome.desktop.a11y.keyboard mousekeys-enable false
org.gnome.desktop.a11y.keyboard mousekeys-init-delay 160
org.gnome.desktop.a11y.keyboard mousekeys-max-speed 750
org.gnome.desktop.a11y.keyboard slowkeys-beep-accept true
org.gnome.desktop.a11y.keyboard slowkeys-beep-press true
org.gnome.desktop.a11y.keyboard slowkeys-beep-reject false
org.gnome.desktop.a11y.keyboard slowkeys-delay 300
org.gnome.desktop.a11y.keyboard slowkeys-enable false
org.gnome.desktop.a11y.keyboard stickykeys-enable false
org.gnome.desktop.a11y.keyboard stickykeys-modifier-beep true
org.gnome.desktop.a11y.keyboard stickykeys-two-key-off true
org.gnome.desktop.a11y.keyboard timeout-enable false
org.gnome.desktop.a11y.keyboard togglekeys-enable false

I also don't get any beep or any other indicator.

I looked around and found https://bugzilla.redhat.com/show_bug.cgi?id=816764

It seems there are a bunch of issues according to this bug. Are you using GNOME, or another desktop? Also, are you using gdm?

Im not using GNOME or any other explicitly; but I do use gnome-terminal and firefox mostly, under openbox as the window manager.

According to /etc/sysconfig/displaymanager, I do use gdm, yes (just like under 12.1).

Reading through the bugzilla, it seems pretty clear to be GDM related. I'll try to see what happens when I use another displaymanager.

The problem does not happen with kdm.

It appears as if the analysis in the RHT bug that gdm activates, but then does not disable, X11 accessibility features is correct.

Incidentally, with kdm, my bug 779788 also disappears - overrides that setting too.

So good riddance gdm, but perhaps someone still wants to fix it ;-)

I'm pretty sure it is being enabled by GDM and you can argue that it needs to be possible to enable it during login, so impaired people requiring the slow-keys feature can log into their account.

Also I remember this topic being discussed in Novell's bugzilla not the first time. :-(

I didn't mind it being enabled during the gdm session (I can see the argument there), I *did* mind this *staying* enabled afterward, silently. This was one of the most annoying issues I've encountered in the last few years - the other one I also encountered on 12.2 ;-)

(And this definitely wasn't the case with 12.1.)

gdm should turn it off when it hands over to the displaymanager.

So this really https://bugzilla.gnome.org/show_bug.cgi?id=685063

Thank you Lars for reporting this and saving me much misery when I got bitten by it this week!  What an awful usability issue.

Marcus found another upstream bugreport about this issue: https://bugs.freedesktop.org/show_bug.cgi?id=52611

Workaround:

Run "xkbset -accessx" in your ~/.xinitrc or ~/.xsessionrc respectively. You can find xkbset in obs.

xkbset is currently only packaged for openSUSE in two home projects :-/

home:tiwai
home:seife:testing

Worth pushing to Factory?!

RESOLVED UPSTREAM per https://bugzilla.gnome.org/show_bug.cgi?id=685063