I recently got a pop-up say "Sticky keyboard - disabled" and my keyboard stopped working. My first reaction was that the message was translated to English, and "stuck key" became "sticky keyboard." Can't think of a sensor for that.
In any case, keyboard was *WAY* disabled, plugging in a USB keyboard didn't help, ssh from another machine didn't help (keystrtokes not accepted), and I finally had to reboot the machine, after migrating all the guests elsewhere or shutting them down. Major PITA.
So is there (supposed to be) a way to clear that? And how does the driver tell a stuck key from a user holding a key, like a gamer holding down "F" to fire weapons, as I've seen them do. How is it detected, and please may I make it not do that? Recovery by boot is a Windows technology, they might have it patented.
It's a massive usability fail, masquerading as an accessibility feature. See:
https://bugzilla.redhat.com/show_bug.cgi?id=816764
Rich.
On Tue, Apr 23, 2013 at 11:12 PM, Richard W.M. Jones rjones@redhat.com wrote:
It's a massive usability fail, masquerading as an accessibility feature.
Yep. And there has been a depressing lack of willingness in the Fedora community to find out what's causing it. It spontaneously activates for me with no apparent trigger. I'm certainly not holding down the shift key for extended periods. From memory, this started happening some time around F17. Yes, I can disable it each time it happens, but it's a pain in the arse to have to do so. It seems to mostly be affecting those that aren't using the default desktop (I'm using fvwm here).
Tet
-- "Java is a DSL for taking large XML files and converting them to stack traces" -- Bulat Shakirzyanov
On Wed, 24 Apr 2013 14:14:52 +0100 Tethys tethys@gmail.com wrote:
On Tue, Apr 23, 2013 at 11:12 PM, Richard W.M. Jones rjones@redhat.com wrote:
It's a massive usability fail, masquerading as an accessibility feature.
Yep. And there has been a depressing lack of willingness in the Fedora community to find out what's causing it. It spontaneously activates for me with no apparent trigger. I'm certainly not holding down the shift key for extended periods. From memory, this started happening some time around F17. Yes, I can disable it each time it happens, but it's a pain in the arse to have to do so. It seems to mostly be affecting those that aren't using the default desktop (I'm using fvwm here).
Tet
-- "Java is a DSL for taking large XML files and converting them to stack traces" -- Bulat Shakirzyanov
I got the same symptoms when using gdm + fvwm. With lightdm + fvwm are gone.
/usr/bin/xkbset -accessx is the cure under gdm.
BR, Bob
On Wed, 24 Apr 2013 15:54:41 +0200 Bob Marcan wrote:
I got the same symptoms when using gdm + fvwm. With lightdm + fvwm are gone.
I've never had the problem, but I also haven't used GDM in years and years and I note the bugzilla pointed at earlier in this thread mentions GDM as the probable culprit. (I use KDM + fvwm).
I stopped using GDM due to this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=451562
which is waaayyyy older than the accessibility problem, but has also never been fixed.
Hey fedora! I seriously think you ought to just drop GDM (or at least never make it the default).
On Tue, 2013-04-23 at 17:59 -0400, Bill Davidsen wrote:
I recently got a pop-up say "Sticky keyboard - disabled" and my keyboard stopped working. My first reaction was that the message was translated to English, and "stuck key" became "sticky keyboard." Can't think of a sensor for that.
In any case, keyboard was *WAY* disabled, plugging in a USB keyboard didn't help, ssh from another machine didn't help (keystrtokes not accepted), and I finally had to reboot the machine, after migrating all the guests elsewhere or shutting them down. Major PITA.
I would say that it's not stuck key, but the sticky key feature for helping the disabled (one of those slow typing aids). It's turned on or off by holding the shift key down for an extended period (and just the sort of thing typists will do who don't use the capslock).
In my case, when activated, the notification window would always appear behind the current window, and there'd be no clue that it'd done that. Suddenly the keyboard wouldn't work any more, as the computer's waiting for me to respond the hidden notification window (this is a bad design, in itself). Once I cottoned on to that, any time that the keyboard was locked out, I'd minimise windows for the applications I was using, one-by-one, until I found the hidden notification window.
So is there (supposed to be) a way to clear that? And how does the driver tell a stuck key from a user holding a key, like a gamer holding down "F" to fire weapons, as I've seen them do. How is it detected, and please may I make it not do that? Recovery by boot is a Windows technology, they might have it patented.
I've yet to see anything attempt it, but (without pondering about any ramifications) it sounds a useful thing. I've certainly come across times where a jammed key has caused a problem. In my case, it's usually something falling on the keyboard, but I've used other people's keyboards where the keyboard has been damaged.
Bill Davidsen wrote:
I recently got a pop-up say "Sticky keyboard - disabled" and my keyboard stopped working. My first reaction was that the message was translated to English, and "stuck key" became "sticky keyboard." Can't think of a sensor for that.
Thanks to all who contributed ideas. I do sometimes type a line without the cap lock, depending on what the text is and if that is convenient. That MAY have been the original cause.
In any case, keyboard was *WAY* disabled, plugging in a USB keyboard didn't help, ssh from another machine didn't help (keystrtokes not accepted), and I finally had to reboot the machine, after migrating all the guests elsewhere or shutting them down. Major PITA.
So is there (supposed to be) a way to clear that? And how does the driver tell a stuck key from a user holding a key, like a gamer holding down "F" to fire weapons, as I've seen them do. How is it detected, and please may I make it not do that? Recovery by boot is a Windows technology, they might have it patented.
-
Bill Davidsen -
Bob Marcan -
Richard W.M. Jones -
Tethys -
Tim -
Tom Horsley