Hi, As described at <http://bugs.debian.org/677173> and <https://bugzilla.redhat.com/816764>, some users accidentally holding down shift too long end up pressing some other modifiers and then are confused when applications stop accepting input. Restarting the X server fixes it, as does holding down shift again if you know to do so. Some people reporting running into this scenario: Vincent Lefevre Wookey Bjørn Mork They are bright people, and if they find this counterintuitive, I expect many others will as well. A common way to run into this is to hold down shift while performing some action with the mouse that takes at least 10 seconds. Julien Cristau pointed reporters to the blog entry http://who-t.blogspot.fr/2012/06/xkb-slowkeys.html so it looks like this usability problem is known, but there doesn't seem to be a bug filed for it. Of course, fixing it is tricky. The same annoying keyboard shortcut is used on Windows, although there the result is an annoying dialog box popping up instead of the keyboard seeming to just stop working. (I don't suggest copying that. :)) Making sure this feature remains discoverable might require some coordination with Desktop Environment authors, to put an appropriate entry in a keyboard layout switcher on the panel, for example (sorry, I'm out of touch with the DE world). Of course, as long as the education problem is solved somehow, the appropriate fix on the X side is obvious. The keyboard shortcut needs to be harder to accidentally trip. Perhaps it could be made configurable to allow people to experiment to find a good one. Sorry for the ramble, and hope that helps, Jonathan
(In reply to comment #0) > As described at <http://bugs.debian.org/677173> and > <https://bugzilla.redhat.com/816764>, some users accidentally > holding down shift too long end up pressing some other modifiers and > the Um, I mixed up Sticky Keys and Slow Keys, sorry. So modifiers are not involved --- the point is that the keyboard really does stop accepting normal input unless you hold down each key for a while. Another quick datum: on Mac OS X, holding down the Return key for 4 seconds produces a beep. Continuing to hold it for 4 more seconds turns on Slow Keys. Enter seems like a less common key to hold down than Shift and the beep provides useful feedback, so one nice approach might be to copy them.
(In reply to comment #0) > the appropriate fix on the X side is obvious. The keyboard shortcut needs > to be harder to accidentally trip. Unfortunately, that's rather inappropriate for reasons that should also be obvious - making it harder to activate makes it harder for the people who need this functionality (because they have motor control issues with their hands) to enable it on their own. I absolutely agree that the desktop environments should provide more feedback and notification here, as I've had to help a number of people who hit this and had no idea why, but we can't change that in the X server.
(In reply to comment #2) > (In reply to comment #0) >> the appropriate fix on the X side is obvious. The keyboard shortcut needs >> to be harder to accidentally trip. > > Unfortunately, that's rather inappropriate for reasons that should also be > obvious - making it harder to activate makes it harder for the people who > need this functionality Perhaps you missed the word "accidentally" and the example of using the "enter" key instead of shift.
(In reply to comment #2) > I absolutely agree that the desktop environments should provide more feedback > and notification here, Not everyone uses a desktop environment. But perhaps the feature [of activating SlowKeys by holding Shift for 8 seconds] should not be enabled by the X server by default, but only by desktop environments if they can provide the notification (and a way to inform the user how to disable the feature and to silent the notification). Using Enter instead of Shift would not be a solution, because one may hold Enter to insert many blank lines, to scroll (e.g. in less) or whatever. However you should probably not activate SlowKeys if Shift is used with a combination of mouse operations.
(In reply to comment #4) > Using Enter instead of Shift would not be a solution, because one may hold > Enter to insert many blank lines, to scroll (e.g. in less) or whatever. Do you disagree that it would be much, much better than Shift, at least? Do you have an alternative to suggest? > However you should probably not activate SlowKeys if Shift is used with a > combination of mouse operations. If someone can come up with a good heuristic for this, it would be nice, but it seems somewhat complex to distinguish between accidental mouse operations (e.g., ordinary mouse motion, which this heuristic would need to ignore) and intentional ones. Thanks, Jonathan
(In reply to comment #5) > (In reply to comment #4) > > Using Enter instead of Shift would not be a solution, because one may hold > > Enter to insert many blank lines, to scroll (e.g. in less) or whatever. > > Do you disagree that it would be much, much better than Shift, at least? It depends on whether the test with Shift can be improved. If Shift + mouse operations no longer activates SlowKeys, the use of Shift may become better. > Do you have an alternative to suggest? The ISO_Level3_Shift key (generally the AltGr physical key)? AFAIK, it is never used with a mouse combination. Or the CapsLock key (it doesn't make sense to keep it pressed). > If someone can come up with a good heuristic for this, it would be nice, > but it seems somewhat complex to distinguish between accidental mouse > operations (e.g., ordinary mouse motion, which this heuristic would need > to ignore) and intentional ones. If the goal is to activate SlowKeys, the user could be careful not to touch the mouse (there may still be a problem if the mouse is very sensible so that the mouse pointer can move by itself, but I suppose that persons who need SlowKeys do not have such a mouse, as a very sensitive mouse is harder to use without minimal skills).
(In reply to comment #5) > Do you disagree that it would be much, much better than Shift, at least? One advantage of Shift is that pressing it is unlikely to cause text entry to occur or applications to take any actions during the period it's being held down. (In reply to comment #6) > It depends on whether the test with Shift can be improved. If Shift + mouse > operations no longer activates SlowKeys, the use of Shift may become better. That seems reasonable to me, though I'd want to run by accessibility experts first.
[I'm one of the "accessibility experts" that Alan wanted to run this by...] Use of the shift key has been the standard for a long time across all desktop environments; why Mac OS is now reportedly using the <Return> key now is something I can't speak to at this time. Given the nature of the disabilities that need SlowKeys, requiring that there be no mouse movement for the entire 8 seconds that Shift is held down seems fine - I don't believe this will negatively impact anyone who needs SlowKeys. Shifting (pardon the pun) to having desktop environments explicitly turn this on and explicitly provide UI for it (e.g. when held down pop up a confirmation dialog box) also seems like a fine change. I would only be concerned about getting the timing & coordination right for that, so that we don't harm users who need this during a transition to a new model for the roles that the various components are playing. I think it would be a mistake to require a longer duration of holding down the key. I think it would be a mistake to move to a different key - particularly something that may not be on all keyboards. I am concerned about emitting a tone at 4 seconds with activation at 8 seconds, for the simple reason that users might erroneously think 4 seconds was enough to activate. But as there are (far) fewer users who need this compared to the general population, this would be a relatively easier education task. BUT... shifting this to the desktop environment's responsibility for UI notification is probably the better way to go; a beep is more easily missed (in both directions) than a dialog box appearing that explains what is going on.
(In reply to comment #8) > I am concerned about emitting a tone at 4 seconds with activation at 8 seconds, > for the simple reason that users might erroneously think 4 seconds was enough > to activate. A tone would be completely useless for me, unless that's a "visual tone" (the speakers are off most of the time). But if it has to be something visual, it should be something informative. > But as there are (far) fewer users who need this compared to the > general population, this would be a relatively easier education task. BUT... > shifting this to the desktop environment's responsibility for UI notification > is probably the better way to go; a beep is more easily missed (in both > directions) than a dialog box appearing that explains what is going on. Yes, exactly. But the information should be available even if one doesn't use a desktop environment (just a window manager), or you should shift the entire feature to the desktop environment.
It seems obvious to me this mis-feature should be disabled by default in the X server, and only "desktop environments" that have the infrastructure to displays notifications should enable it.
I hit this issue today, and i'm pretty sure that i did *not* actually hold down shift for more than 10 seconds. Quite possibly, i held down shift for a couple seconds, and while i did so, there was a successful keyboard grab from an XClient. at any rate, it seems like it might be possible to miss the shift release event.
(In reply to comment #10) > It seems obvious to me this mis-feature should be disabled > by default in the X server, and only "desktop environments" > that have the infrastructure to displays notifications > should enable it. It seems extremely obvious to me that this accessibility requirement should not be disabled by default. OTOH, it also seems obvious that it should be fixed to take mouse motion into account, and not trigger if there's been any substantial input activity while it's down. The patch should be reasonably simple, to wrap mouse events similarly to xkb/xkbPrKeyEv.c's ProcessKeyboardEvent, and pass them through to the AccessX code, which would then cancel any pending AccessX events if mouse activity is detected.
(In reply to comment #12) > It seems extremely obvious to me that this accessibility requirement should not > be disabled by default. It may be obvious for "desktop environments". But I would have thought that the users of this accessibility feature (mis-feature for those who don't need it) always are under a desktop environment, so that it would be fine to disable it by default everywhere else. I'd like to hear how this feature is used in practice (when, how often, etc.). Wouldn't the system be able to guess whether SlowKeys should be activated or not when Shift is held for 8 seconds (i.e. whether it is intended to activate SlowKeys or not)? It seems that I sometimes hold Shift without doing anything else, just because I intend to type PageUp/PageDown once I've finished to read text. So, fixing the problem for mouse actions would not be sufficient. IMHO, SlowKeys shouldn't be activated in the case another key is pressed while Shift is still held, i.e. SlowKeys could be activated at the Shift Key Release event if pressed for at least 8 seconds (not once the 8 seconds have elapsed like now), only when another key hasn't been pressed and the mouse hasn't been used between the key press and the key release.
I'm a bit puzzled because I too ran into this issue a couple weeks ago, and so did two others that I know who are running Debian. The fact that several people have been hit by this in such a short time seemed coincidental to me, and then I found the Debian bug report, and saw that other people that I know were also recently hit by this. In my case, I'm embarrassed to say that it took me *two weeks* before someone else who ran into this suggested it might be SlowKeys and I was able to then resolve the issue. I had resigned myself that my laptop keyboard had broken again, as it has now several times in the last two years, and had plugged in a USB keyboard to work around it. I dont know how long this accessibility feature has existed in X, nor do I remember how long I've been using X (at least a decade).... never in that time have I accidentally triggered this. I think its a good feature, and would not encourage its removal. Changing the key to be something less likely to be pressed might be a good solution, but presents transition problems. I do see how indicating to the user that this has been activated is a problem with the proliferation of different window managers, I also applaud the recent inclusion in the log that this has been triggered. But, boy it sucks when this gets enabled and you have no idea.
(In reply to comment #14) > I'm a bit puzzled because I too ran into this issue a couple weeks ago, and so > did two others that I know who are running Debian. The fact that several people > have been hit by this in such a short time seemed coincidental to me gdm3 turns the AccessX bit on. Then it remains enabled after you log in, even if the resulting environment doesn't know how to cope with that. After http://patchwork.freedesktop.org/patch/10795/ desktop environments should be able to more easily notice that Slow Keys has been enabled and throw up a popup. The discussion here has focused on how to avoid spuriously enabling Slow Keys in the first place, which seems useful because when such a popup appears it is still an interuption to work and a usability problem.
A few minutes ago, the system switched to SlowKeys while I didn't even touch the Shift key! Note: It sometimes happens that I unintentionally hold the Shift key for 8+ seconds (e.g. because I intend to type PageUp or PageDown, but don't do it immediately). In such a case, a message is written to the /var/log/Xorg.0.log file. But here, nothing was written! Here are the last messages in the /var/log/Xorg.0.log file: [778009.172] (II) XKB SlowKeys are now enabled. Hold shift to disable. [870684.606] (II) XKB SlowKeys are disabled. [870684.620] (II) XKB SlowKeys are now enabled. Hold shift to disable. [870793.988] (II) XKB SlowKeys are now enabled. Hold shift to disable. [870793.988] (II) XKB SlowKeys are disabled. [970681.038] (II) XKB SlowKeys are disabled. [970681.101] (II) XKB SlowKeys are now enabled. Hold shift to disable. [970710.197] (II) XKB SlowKeys are now enabled. Hold shift to disable. [970710.198] (II) XKB SlowKeys are disabled. [970782.228] (II) config/udev: removing device USB OPTICAL MOUSE [970782.519] (II) evdev: USB OPTICAL MOUSE: Close [970782.641] (II) UnloadModule: "evdev" [970783.017] (II) config/udev: Adding input device USB OPTICAL MOUSE (/dev/input/mouse0) [970783.056] (II) No input driver specified, ignoring this device. [970783.056] (II) This device may have been added with another device file. [970783.056] (II) config/udev: Adding input device USB OPTICAL MOUSE (/dev/input/event3) [970783.056] (**) USB OPTICAL MOUSE: Applying InputClass "evdev pointer catchall" [970783.056] (II) Using input driver 'evdev' for ' USB OPTICAL MOUSE' [970783.056] Option "XkbRules" "evdev" [970783.056] Option "XkbModel" "evdev" [970783.056] Option "XkbLayout" "us" [970783.056] Option "_source" "server/udev" [970783.056] Option "name" " USB OPTICAL MOUSE" [970783.056] Option "path" "/dev/input/event3" [970783.056] Option "device" "/dev/input/event3" [970783.056] Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.7/usb8/8-3/8-3.3/8-3.3:1.0/input/input19/event3" [970783.056] Option "driver" "evdev" [970783.056] (**) USB OPTICAL MOUSE: always reports core events [970783.056] (**) evdev: USB OPTICAL MOUSE: Device: "/dev/input/event3" [970783.057] (--) evdev: USB OPTICAL MOUSE: Vendor 0x15d9 Product 0xa4c [970783.057] (--) evdev: USB OPTICAL MOUSE: Found 3 mouse buttons [970783.057] (--) evdev: USB OPTICAL MOUSE: Found scroll wheel(s) [970783.057] (--) evdev: USB OPTICAL MOUSE: Found relative axes [970783.057] (--) evdev: USB OPTICAL MOUSE: Found x and y relative axes [970783.057] (II) evdev: USB OPTICAL MOUSE: Configuring as mouse [970783.057] (II) evdev: USB OPTICAL MOUSE: Adding scrollwheel support [970783.057] (**) evdev: USB OPTICAL MOUSE: YAxisMapping: buttons 4 and 5 [970783.057] (**) evdev: USB OPTICAL MOUSE: EmulateWheelButton: 4, EmulateWheelInertia: 10, EmulateWheelTimeout: 200 [970783.057] (**) Option "config_info" "udev:/sys/devices/pci0000:00/0000:00:1d.7/usb8/8-3/8-3.3/8-3.3:1.0/input/input19/event3" [970783.057] (II) XINPUT: Adding extended input device " USB OPTICAL MOUSE" (type: MOUSE, id 12) [970783.057] (II) evdev: USB OPTICAL MOUSE: initialized for relative axes. [970783.057] (**) USB OPTICAL MOUSE: (accel) keeping acceleration scheme 1 [970783.057] (**) USB OPTICAL MOUSE: (accel) acceleration profile 0 [970783.057] (**) USB OPTICAL MOUSE: (accel) acceleration factor: 2.000 [970783.057] (**) USB OPTICAL MOUSE: (accel) acceleration threshold: 4 [992084.496] (II) XKB SlowKeys are disabled. [992084.515] (II) XKB SlowKeys are disabled. SlowKeys got enabled for no reasons around 992000. I could disable it by holding Shift for 8+ seconds.
I was also bitten by this since I upgraded my Debian install to Wheezy, which means something happened between Xorg 7.5 and 7.7. I do not use gnome, I do not use KDE, in fact I do not consider I use a "desktop environment" most of the time, the main exception being "gnome-settings" that is started during my session. I notable have *disabled* the slow keys shortcut in gnome-settings, so I do not expect this to happen at all. I can confirm, however, that the following workaround works: gsettings set org.gnome.desktop.a11y.keyboard enable false ... but only if you are running "gnome-settings". Oh, and this bug manifests itself in non-GNOME sessions only if you run GDM, which enables accessibility features before your X session starts. I can also note that I cannot reproduce this with a USB keyboard, which seems at the very least inconsistent. I can also corroborate with other reports of this being triggered randomly, that is: I did not hold the shift key for 10 seconds - but maybe a serie of different keys were held down in a total of 10 seconds. As others here, I have thought that my keyboard was broken. I had to reboot my laptop a few times until a friend that was sitting next to me explained what happened. The fact that a line is now written in Xorg.0.log is useful, but will *never* be useful to most of the users out there - in fact I never thought of looking there until I found this bug report. I do not understand why this feature is there, or how i can be considered an "accessibility" feature. From my point of view, it makes the whole graphical interface a lot *less* usable, as it means that, without any explanation, your laptop's keyboard may stop working completely. I would like to understand what purpose it serves and while I do not object to the feature being present, I'd like to be able to turn this thing off, at the very least.
To clarify my last comment here: I had the setting disabled in my gnome-control-center, but because gnome-settings is not running, it's not taking effect. So in a way, as soon as you run gdm3, you are *forced* to run gnome (or more precisely gnome-settings) to make sure you can disable that setting, otherwise it stays turned on and there is no way to disable that behavior.
This bug bit me today. Although I am using the latest X server from Debian Sid, there was no line in Xorg.0.log notifying me that SlowKeys had been enabled. I am using Gnome, where keyboard accessability is disabled. $ gsettings get org.gnome.desktop.a11y.keyboard enable false Toggling SlowKeys on and back off in Gnome did not disable the behavior. Only holding down the shift key (after doing research to find this bug) could disable it. Some of these issues are the fault of Gnome, but it seems there is some path to enabling SlowKeys that does not result in a log entry or notification of the desktop environment.
(In reply to comment #19) > This bug bit me today. Although I am using the latest X server from Debian > Sid, there was no line in Xorg.0.log notifying me that SlowKeys had been > enabled. So, like what happened to me in comment #16 (I also use Debian/sid, but not GNOME).
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/xserver/issues/303.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.