Launchpad has imported 14 comments from the remote bug at https://bugs.freedesktop.org/show_bug.cgi?id=73155.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2013-12-30T14:46:05+00:00 Libreoffice-org wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1245662/comments/6 ------------------------------------------------------------------------ On 2013-12-30T17:24:46+00:00 zBrain wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1245662/comments/8 ------------------------------------------------------------------------ On 2013-12-30T17:37:16+00:00 Alan Coopersmith wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1245662/comments/9 ------------------------------------------------------------------------ On 2013-12-30T18:46:10+00:00 Libreoffice-org wrote: @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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1245662/comments/10 ------------------------------------------------------------------------ On 2013-12-30T19:00:38+00:00 Alan Coopersmith wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1245662/comments/11 ------------------------------------------------------------------------ On 2014-01-06T01:45:29+00:00 Peter Hutterer wrote: (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? Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1245662/comments/12 ------------------------------------------------------------------------ On 2014-01-10T13:25:23+00:00 Libreoffice-org wrote: > 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1245662/comments/36 ------------------------------------------------------------------------ On 2014-01-16T05:43:43+00:00 Peter Hutterer wrote: bisected to this commit: commit 11319a922575f1da1d3c5774728c0dee12bab069 Author: Peter Hutterer <[email protected]> Date: Thu Oct 11 16:03:33 2012 +1000 xkb: ProcesssPointerEvent must work on the VCP if it gets the VCP Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1245662/comments/37 ------------------------------------------------------------------------ On 2014-02-14T10:20:39+00:00 Libreoffice-org wrote: 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! Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1245662/comments/38 ------------------------------------------------------------------------ On 2014-03-21T12:35:54+00:00 Libreoffice-org wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1245662/comments/39 ------------------------------------------------------------------------ On 2014-03-29T12:18:05+00:00 Andres G. Aragoneses wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1245662/comments/41 ------------------------------------------------------------------------ On 2014-03-29T21:12:33+00:00 Doug Tentilhao wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1245662/comments/42 ------------------------------------------------------------------------ On 2014-03-29T22:00:12+00:00 zBrain wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1245662/comments/43 ------------------------------------------------------------------------ On 2014-03-30T01:51:57+00:00 Peter Hutterer wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/xorg- server/+bug/1245662/comments/45 ** Changed in: xorg-server Status: Unknown => Confirmed ** Changed in: xorg-server Importance: Unknown => Medium -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to xorg-server in Ubuntu. https://bugs.launchpad.net/bugs/1245662 Title: Sticky Keys not released after mouse action. Status in X.Org X server: Confirmed Status in “xorg-server” package in Ubuntu: Confirmed Bug description: 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 Kubuntu 13.10 the 'Lock' feature is broken. It is _always_enabled_ for the mouse, and _always_disabled_ for the keyboard, regardless of whether or not the checkbox is checked. Actually, Kubuntu 13.04 had this problem as well, but I though that it was a configuration issue on my part and simply avoided updating to 13.04. However, I can no longer avoid updating and I cannot use current Kubuntu with the Accessibility issue in this state. What are the conditions for considering an issue high priority? Users with Accessibility issues can no longer use the current KDE, does that quality for high priority? Steps to Reproduce: 1. Enable Sticky Keys (System Settings -> Accessibility -> Modifier Keys) 2. Enable "Use sticky keys" and disable "Lock sticky keys". 3. In Kate, 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. ProblemType: Bug DistroRelease: Ubuntu 13.04 Package: systemsettings 4:4.10.5-0ubuntu0.1 ProcVersionSignature: Ubuntu 3.8.0-31.46-generic 3.8.13.8 Uname: Linux 3.8.0-31-generic x86_64 ApportVersion: 2.9.2-0ubuntu8.3 Architecture: amd64 Date: Mon Oct 28 22:13:10 2013 InstallationDate: Installed on 2013-05-01 (180 days ago) InstallationMedia: Kubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424) MarkForUpload: True SourcePackage: kde-workspace UpgradeStatus: No upgrade log present (probably fresh install) --- .tmp.unity.support.test.0: ApportVersion: 2.12.7-0ubuntu6 Architecture: amd64 CasperVersion: 1.336ubuntu1 CompizPlugins: No value set for `/apps/compiz-1/general/screen0/options/active_plugins' CompositorRunning: compiz CompositorUnredirectDriverBlacklist: '(nouveau|Intel).*Mesa 8.0' CompositorUnredirectFSW: true CurrentDesktop: Unity DistUpgraded: Fresh install DistroCodename: trusty DistroRelease: Ubuntu 14.04 DistroVariant: ubuntu ExtraDebuggingInterest: Yes GraphicsCard: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7480D] [1002:9993] (prog-if 00 [VGA controller]) Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] Trinity [Radeon HD 7480D] [1002:9993] LiveMediaBuild: Ubuntu 14.04 LTS "Trusty Tahr" - Alpha amd64 (20140108) MachineType: Gigabyte Technology Co., Ltd. To be filled by O.E.M. MarkForUpload: True Package: xorg-server (not installed) ProcKernelCmdLine: file=/cdrom/preseed/username.seed boot=casper initrd=/casper/initrd.lz quiet splash -- maybe-ubiquity ProcVersionSignature: Ubuntu 3.12.0-7.15-generic 3.12.4 Tags: trusty ubuntu regression reproducible compiz-0.9 Uname: Linux 3.12.0-7-generic x86_64 UpgradeStatus: No upgrade log present (probably fresh install) UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo dmi.bios.date: 09/24/2012 dmi.bios.vendor: American Megatrends Inc. dmi.bios.version: F2 dmi.board.asset.tag: To be filled by O.E.M. dmi.board.name: F2A55M-HD2 dmi.board.vendor: Gigabyte Technology Co., Ltd. dmi.board.version: x.x dmi.chassis.asset.tag: To Be Filled By O.E.M. dmi.chassis.type: 3 dmi.chassis.vendor: Gigabyte Technology Co., Ltd. dmi.chassis.version: To Be Filled By O.E.M. dmi.modalias: dmi:bvnAmericanMegatrendsInc.:bvrF2:bd09/24/2012:svnGigabyteTechnologyCo.,Ltd.:pnTobefilledbyO.E.M.:pvrTobefilledbyO.E.M.:rvnGigabyteTechnologyCo.,Ltd.:rnF2A55M-HD2:rvrx.x:cvnGigabyteTechnologyCo.,Ltd.:ct3:cvrToBeFilledByO.E.M.: dmi.product.name: To be filled by O.E.M. dmi.product.version: To be filled by O.E.M. dmi.sys.vendor: Gigabyte Technology Co., Ltd. version.compiz: compiz 1:0.9.10+13.10.20131011-0ubuntu1 version.ia32-libs: ia32-libs N/A version.libdrm2: libdrm2 2.4.50-1 version.libgl1-mesa-dri: libgl1-mesa-dri 10.0.1-1ubuntu2 version.libgl1-mesa-dri-experimental: libgl1-mesa-dri-experimental N/A version.libgl1-mesa-glx: libgl1-mesa-glx 10.0.1-1ubuntu2 version.xserver-xorg-core: xserver-xorg-core 2:1.14.5-1ubuntu2 version.xserver-xorg-input-evdev: xserver-xorg-input-evdev 1:2.8.2-1ubuntu1 version.xserver-xorg-video-ati: xserver-xorg-video-ati 1:7.2.0-0ubuntu10 version.xserver-xorg-video-intel: xserver-xorg-video-intel 2:2.99.907-0ubuntu1 version.xserver-xorg-video-nouveau: xserver-xorg-video-nouveau 1:1.0.10-1ubuntu1 xserver.bootTime: Wed Jan 8 16:29:02 2014 xserver.logfile: /var/log/Xorg.0.log xserver.version: 2:1.14.5-1ubuntu2 To manage notifications about this bug go to: https://bugs.launchpad.net/xorg-server/+bug/1245662/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
