The accessibility option Sticky Keys in it's default state releases the 'stuck' modifier key after any HID input (mouse click, keyboard non-modifier button pressed). Additionally, Sticky Keys has a Lock feature which does not automatically release the 'stuck modifier', but rather waits until the user presses the modifier key again to release it. In recent XKB releases on all popular Linux distros (since about the beginning of year 2013) the 'Lock' feature is broken. It is _always_enabled_ for the mouse, and _always_disabled_ for the keyboard, regardless of whether or not the configuration option is enabled. What are the conditions for considering an issue high priority? Users with Accessibility issues can no longer use the current Linux distros, does that quality for high priority? I'm still stuck on Kubuntu 12.10 due to this issue as I have a manual disability. Steps to Reproduce: 1. Enable Sticky Keys (In KDE: System Settings -> Accessibility -> Modifier Keys ; In Gnome: Settings -> Accessibility -> Some tab with keyboard/typing) 2. Enable "Use sticky keys" and disable "Lock sticky keys". Now test: In Kmail, click Ctrl then click a mail in the Message List Pane to select it. Now click on a second mail and notice that it too is selected. Now a third. Actual Results: All the mails are added to the selection. Expected Results: One would expect that with the "Lock sticky keys" checkbox disabled that the Ctrl button would be released after clicking a single mail. With "Lock sticky keys" disabled the expected workflow to select multiple mails is to either press the Ctrl button after each mail or to hold it down. Note that this issue affects all modifier keys in all applications. This is most annoying when using Shift- or Ctrl- MouseScroll i.e. in Firefox as the modifier is not release when expected. This is also a serious accessibility issue for disabled users (such as myself).
Confirming this bug as well as it's severity and high level of importance to disabled users. It causes all sorts of unexpected behaviour - just imagine your control or shift keys being pressed when you aren't expecting it. Virtual desktops flipping, emails deleted instead of moved to trash are but 2 of many issues. It's most notable in my text editor. Shift click to highlight text, then ctrl+c (which is now shift+ctrl+c as shift was not released by the mouse click as expected) then ctrl+v and it pastes the wrong thing because the copy operation didn't do what was expected. This bug apparently affects all disabled users across all DEs. As mentioned, some users are forced to remain on old and soon to be unsupported versions in order to avoid the problem.
You've filed this bug against the XKB configuration data files - i.e. the ones with all the different keyboard layouts for all the different international keyboards in different locales. While there are some configuration data for sticky keys in these files, it hasn't changed in years: http://cgit.freedesktop.org/xkeyboard-config/log/compat/accessx Are you sure this bug is in the configuration data and not the X server or the input (evdev) driver? Helping narrow down which package is responsible and which versions work or don't work will greatly help in finding where the bug is to get it fixed.
@Alan: Thank you, I had intended to file with XKB but it doesn't show on the list, so I filed in the closest place that I could find. For reference, here is the list: https://bugs.freedesktop.org/enter_bug.cgi If you know of a better place, I would love to get it in there.
(In reply to comment #3) > Thank you, I had intended to file with XKB but it doesn't show on the list, Because XKB is not a single piece of software - it's a protocol, data files, a bunch of utilities, support in various other programs, etc. Most of the XKB software is found in bugzilla under the "Xorg" product.
(In reply to comment #0) > In Kmail, click Ctrl then click a mail in the Message List Pane to select > it. Now click on a second mail and notice that it too is selected. Now a > third. > Actual Results: All the mails are added to the selection. > Expected Results: One would expect that with the "Lock sticky keys" checkbox > disabled that the Ctrl button would be released after clicking a single > mail. With "Lock sticky keys" disabled the expected workflow to select > multiple mails is to either press the Ctrl button after each mail or to hold > it down. I don't think that's the intended behaviour. Looking at the protocol description at http://www.x.org/docs/XKB/XKBproto.pdf it says "Modifiers are automatically unlatched when the user presses a non-modifier key.". Buttons are not keys in X, so going by just this I'd say that it works as intended. Are you saying that this used to work differently, and if so what server version is the latest you know of working?
> Looking at the protocol description at http://www.x.org/docs/XKB/XKBproto.pdf > it says "Modifiers are automatically unlatched when the user presses a > non-modifier key.". Buttons are not keys in X, so going by just this I'd say > that it works as intended. Are you saying that this used to work differently, > and if so what server version is the latest you know of working? Yes, up until Xorg 1.13.0 inclusive it worked differently. In those systems and action with the mouse would also release the sticky keys. In all other systems (Windows, Mac OSX) sticky keys is also released after the first mouse action. Releasing sticky keys on the first mouse action is definitely the way users expect sticky keys to work, and the way that it had worked until recently. Remember, these are disabled users and cannot easily change their work habits to accommodate this disruptive change. I am one of them :) and simply cannot use a system with the new behaviour. This is from a Kubuntu 12.10 machine which _works as expected_: $ X -version X.Org X Server 1.13.0 Release Date: 2012-09-05 X Protocol Version 11, Revision 0 Build Operating System: Linux 3.2.0-37-generic x86_64 Ubuntu Current Operating System: Linux bruno 3.5.0-44-generic #67-Ubuntu SMP Tue Nov 12 19:36:14 UTC 2013 x86_64 Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.5.0-44-generic root=UUID=d817f86c-cf93-4736-89c8-65a8a4ee4f85 ro quiet splash vt.handoff=7 Build Date: 16 October 2013 04:38:15PM xorg-server 2:1.13.0-0ubuntu6.4 (For technical support please see http://www.ubuntu.com/support) Current version of pixman: 0.26.0 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. Kubuntu 13.04 suffers from this bug (which is the reason that I cannot upgrade), according to distrowatch.com that system uses Xorg 1.13.3. Additionally, I just tested in the latest dev release of Ubuntu 14.04 with Xorg 1.14.5 and it also suffers from this bug. Thus, the change was made in one of the following Xorg versions: 1.13.1 1.13.2 1.13.3 Thank you for looking into this issue.
bisected to this commit: commit 11319a922575f1da1d3c5774728c0dee12bab069 Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Thu Oct 11 16:03:33 2012 +1000 xkb: ProcesssPointerEvent must work on the VCP if it gets the VCP
Thank you for finding the relevant commit, Peter! Is there any progress in resolving the issue? The latest popular Linux distros which do not suffer from this regression are all scheduled for depreciation soon. Thank you!
Is there any schedule for resolving this? Myself and other disabled users rely on Sticky Keys and at least I personally cannot use a system that demonstrates this bug. That means that I am currently using older, unsupported Linux distros and I will soon have to find an alternative operating system. I understand that the change was made to resolve a different issue, but the bug introduced is severe enough that certain disabled users can not use any operating system that suffers from this issue. You can image my concern at the prospect of having to use an alternative OS and possibly upsetting my entire workflow (and the applications that I use) just because of this issue. As Linus says, old bugs are better than new bugs. Please consider a fix or reverting the change.
In case you didn't know, this bug has hit slashdot. The only useful comment there, though, seems to be this one: http://linux.slashdot.org/comments.pl?sid=4959535&cid=46607985 (which seems to reply to comment#5, so I'll quote it: "I do know that even as a non-disabled user, the behavior Peter describes as "per spec" (that is, mouse buttons are not keys for the purposes of releasing the sticky keys) is counter-intuitive since the modifier keys interact with mouse buttons the same way they do with non-modifier keys (ie. Control modifies selection with mouse clicks the same way it modifies selection with the keyboard). Given that normal interaction with both non-modifier keys and mouse buttons, I'd expect instructions about how modifier keys behave to also apply analogously when both non-modifier keys and mouse buttons (but not mouse movements) are involved. Either that or I would expect modifier keys to not interact with mouse clicks the same way they do with regular keys." HTH
Is this what introduced the 'bug` and if so wouldn't it be trivial to revert, except maybe the old behaviour was wrong. Is there any other option to configure sticky-keys+keyboard+mouse events to the satisfaction of the original poster. http://cgit.freedesktop.org/xorg/xserver/commit/?id=2decff6393a44b56d80d53570718f95354fde454
No, it is not posible to configure around the bug. This is not a 'bug', but a bug. There is no question the current implementation is not working as it should. Part of the issue here seems to be the spec, and the want to follow it. The spec unfortunately is either poorly worded or written wrong. The honest truth of the matter is it needs to be fixed, and then we can hopefully move past that. The sentence "Modifiers are automatically unlatched when the user presses a non-modifier key." in the spec needs to read to the effect of: "Modifiers are automatically unlatched when the user performs an action which is affected by the modifier, unless the lock option is selected." The bottom line here is the current functionality is broken for the group of people it is intented to help, and that is a fundamental flaw.
fwiw, that commit linked above broke the behaviour but merely reverting it will break the thing that commit fixed in the first place. When I looked at it fixing this properly was more complicated than I hoped and I've since been busy with other stuff. I'm not claiming that the spec is correct and the one and only solution. if we had one behaviour for years that is often (not always) a better indicator what we should do than what the spec says. and since it has been on slashdot: please refrain from commenting unless you have something useful to contribute to this bug and how it could be fixed. if you're affected and/or want this fixed, add yourself to the CC list, don't comment here. If you are outraged, tell it to your friends and neighbours, don't comment here. Too many comments muddy the water and make it harder to follow what's going on, which again makes it less likely this will get fixed.
http://patchwork.freedesktop.org/patch/23451/
commit 98924719d524bf87cdf301063cd744d1271c33ff Author: Peter Hutterer <peter.hutterer@who-t.net> Date: Wed Apr 2 13:55:10 2014 +1000 Revert "xkb: ProcesssPointerEvent must work on the VCP if it gets the VCP"
Thank you Peter, I look forward to triaging this change. Have a terrific week! Your contributions to Xorg and to the the systems that we depend upon are very much appreciated!
This change has hit Debian Testing, and is such a relief I had to come back and say thanks again for the fix!
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.