Thursday, June 21, 2012

XKB SlowKeys

XKB has an accessibility feature called SlowKeys. Once enabled, a key must be pressed longer than a certain timeout (default: 300ms) to register as key event. Why? From XkbGetSlowKeysDelay(3):
Some users may accidentally bump keys while moving a hand or typing stick toward the key they want. Usually, the keys that are accidentally bumped are just hit for a very short period of time. The SlowKeys control helps filter these accidental bumps by telling the server to wait a specified period, called the SlowKeys acceptance delay, before delivering key events. If the key is released before this period elapses, no key events are generated.
This is a useful feature for those that need it, but quite disturbing when it gets enabled without the user noticing. And that can happen and it then appears as if the keyboard drivers are broken (after all, a restart of the X server reverts it). So here's a what you have to do to avoid this issue:

The server has a built-in key sequence that if either shift key is held for 8 seconds, SlowKeys are enabled. Likewise, another 8s press of either shift key disables them again. This may accidentally happen when playing games or scrolling through long documents.

The server keeps two bitflags around. One for "accessibility features enabled" and one for "slow keys enabled". If the former is set, the key sequence above will activate slow keys (and thus toggle the second bit).

In GNOME3, you can find these options in the Universal Access panel of your System Settings:



If "Turn on accessibility features from the keyboard" is checked, holding shift will enable/disable SlowKeys. If the SlowKeys toggle is on, SlowKeys are always on.

The equivalent gsettings command (to uncheck the checkbox) is:
gsettings set org.gnome.desktop.a11y.keyboard enable false
 I recommend that if you do not need this feature, uncheck the checkbox to avoid nasty surprises. I've also added a patch to the X server to put a warning in the log if SlowKeys is enabled via the shift key. This should make future triaging a bit easier. If you see the message
(II) XKB SlowKeys are now enabled. Hold shift to disable.
in your log, you're likely better off disabling the checkbox. This patch will be in server 1.13 and server 1.12.3.
 
GNOME3 should also warn about SlowKeys being enabled but due to Bug 668213 it stopped doing so in January. Affected is GNOME 3.2+ but we're working on a fix to this.

7 comments:

E. Lewis said...

Good advice.
Thanks.

Linulin said...

Looks like a part of AccessX set of features, which, I strongly believe, needs to be disabled by default. I was annoyed by similar accessibility killer feature on Windows not a single time. There you get a message box with lengthy suggestion to make your keyboard unusable. The wording and buttons were so unclear that in half of the cases I actually agreed with the proposal... But doing this by default and behind the scenes is even worse from usability point of view.

Peter Hutterer said...

Linulin:
The thing with accessibility features is that those who needs them may not be able to enable them. Hence the default to enabled.

GNOME should display a message box and I linked to the bugreport that explains why it doesn't at the moment.

Linulin said...

The problem is that not many are aware of this feature, and more often than not it strikes as complete surprise. And even if you're aware, accidental switches to this mode are not less annoying. (I always considered Shift as no-op key unless something else was pressed in addition.)

To prove how intrusive may AccessX be, -r option is not actually enough to disable keyboard auto-repeat for good, because AccessX raises from the deep with two minutes delay after some key presses, and magically re-enables auto-repeat... Even after finding the relation with AccessX, it turns out -accessx option does not fix the problem, and X Server patch, (not even a configuration option), is required. Consider adding XkbDfltAccessXTimeout = 0; to -accessx processing branch of XkbProcessArguments(). This was verified with 1.8.1 but looking at git HEAD, I don't think current sources work differently in this area.

Peter Hutterer said...

Linulin:
I repeat, AccessX is enabled by default because those that need it may not be able to enabled it otherwise.

As for the other issue - have you filed a bug?

Andrew Pimlott said...

Thank goodness you put that line in the log, or I would never have figured this out. I have accidentally turned on slow keys twice in the last week (since getting a new computer and installing a recent Xorg), and both times ended up restarting X because I thought it was broken. (Only the second time did I figure out I could at least get a key press through by holding down the key long enough.)

I am not using GNOME, and nothing gave me any warning I was turning on this feature. I agree it needs to be available for those that need it, but my experience shows that activating it is too easy to do by accident, and many people will never figure out what happened. There must be a better way. Are many users who need this not able to navigate with the mouse to a dialog where they can turn it on?

Ulrich Klauer said...

I found this blog post several months ago when doing a web search for the log message, and it has helped me a lot – finally, an explanation for those mysterious keyboard lock-ups! As I am lazy, I resorted to holding shift whenever I had accidentally activated this (mis)feature; still annoying, but much less than previously, where I had had to restart my session whenever this happened.

Today, I’ve finally overcome my laziness and replaced gdm with lightdm, which hopefully will solve this issue for good. However, I wanted to come back and thank you for adding that log message in the first place. Without it, I might still looking be for the cause of this problem all over the place (hardware faults, driver problems, etc.).