Turning on sticky keys in Wayland has no effect. STEPS TO REPRODUCE Turn on sticky keys in system settings -> accessibility Press & release shift Press a letter key OBSERVED RESULT A lower case letter is typed EXPECTED RESULT An upper case letter is typed
I'm not sure that it's wired anywhere in on wayland.
Can confirm on: Operating System: Fedora Linux 35 KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.2 Kernel Version: 5.15.12-200.fc35.x86_64 (64-bit) Graphics Platform: Wayland
Can confirm on: Operating System: Arch Linux KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 Kernel Version: 5.16.14-arch1-1 Graphics Platform: Wayland
This bug unfortunately makes KDE completely unusable under Wayland for those that need this feature. Given that a number of major distros are pushing to make Wayland default, I'm hoping to draw attention to it before that happens.
Still present on: Operating System: Fedora Linux 36 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 Kernel Version: 5.18.5-200.fc36.x86_64 (64-bit) Graphics Platform: Wayland The setting in ~/.config/kaccessrc is correct (and reflects the state of the respective checkbox in SystemSettings): [Keyboard] StickyKeys=true (This is the only thing that's stopping me from switching to Wayland. If there's a manual workaround, I'd love to know about it.)
See https://lists.freedesktop.org/archives/wayland-devel/2016-March/027419.html for some discussion how sticky keys and related things could be implemented on Wayland TL;DR it's something that the compositor/kwin needs to do in its input processing, possibly with help from xkbcommon, but as far as I can tell no relevant work on xkbcommon was done
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/3365
(In reply to Nicolas Fella from comment #6) May I add a future feature request to this.. Make the "Lock Keys Status" indicator in the system-tray aware of the status of the sticky-keys.
(In reply to Dan Snis from comment #8) > (In reply to Nicolas Fella from comment #6) > > May I add a future feature request to this.. > Make the "Lock Keys Status" indicator in the system-tray aware of the status > of the sticky-keys. Sounds reasonable. Can you please make a new report in kdeplasma-addons | Keyboard Indicator for this so we can track it properly?
https://invent.kde.org/plasma/kwin/-/merge_requests/3365 makes the basic functionality work on Wayland. For the various options the KCM provides see these follow-up bugs: https://bugs.kde.org/show_bug.cgi?id=464452 https://bugs.kde.org/show_bug.cgi?id=464453 https://bugs.kde.org/show_bug.cgi?id=464456 https://bugs.kde.org/show_bug.cgi?id=464457 https://bugs.kde.org/show_bug.cgi?id=464458 It would be great to have some input on which of these are most important/should be prioritized or which of them may be unimportant enough to drop them
The following scenario works correctly on KDE neon Unstable Edition Live CD (Wayland, Qt 6.6.0, KDE Plasma Version 5.81.80): "Turn on sticky keys in System Settings -> Input & Output > Accessibility > Modifier Keys > make sure that the checkbox "Enable" is turned on. Apply. Open kate. Press & release shift Press a letter key An upper case letter is typed" Is 444335 only about this scenario and therefore we can close this issue? Or is 444335 a metabug and therefore might require fixing a number of other issues before we can close 444335?
If it'a a meta bug or not I'm not aware of. As a user with only one "finger" or a single key press every time It needs to be more than "shift", "ctrl", "alt gr" and "alt" are also required and sometimes in combination, like if I want to make a circle in Inkscape that starts in the center you are suppose to hold "ctrl" + "shift" + left mouse button. My mouse button is sticky as well (under X), with ''' xinput --set-prop --type=int --format=8 "$id" 'libinput Drag Lock Buttons' 8 ''' ps. try putting a pen in your mouth and then use the computer inputs without hands and only pen. I love your work and understand that it's hard to imagine different user scenarios, I couldn't imagine it before I had my accident. And everybody has different needs.
It's great to see work being done on this! Question - when a patch is merged, how do I know which version of KDE/Plasma it will be available? As far as I can tell these are my only blockers to giving Wayland a go, so I'd like to know when I can test a fix.
> when a patch is merged, how do I know which version of KDE/Plasma it will be available? Each merge request has a "Milestone" filed that indicates the target release. It doesn't include the patch version though. If there is a bugreport for it then the "Version Fixed In" field tells that
I'm currently not planning to work on the remaining items, unless someone expresses interest in having those working. I'm just not sure how relevant things like "Ring system bell when locking keys are toggled" actually are, but if someone has a use case for those I'm happy to implement them
> but if someone has a use case for those I'm happy to implement them "Emma is blind, when typing a password she needs to know if she presses Caps Lock." I mean, sighted people have the problem of typing a password several times (for example in the command line), wondering if the password was the correct one, typing it again, wondering if the password was the correct one again... just to discover later that Caps Lock was on. For blind people is worse...
(In reply to Marius P from comment #11) > "Turn on sticky keys in System Settings -> Input & Output > Accessibility > > Modifier Keys > make sure that the checkbox "Enable" is turned on. > Apply. > Open kate. > Press & release shift > Press a letter key > An upper case letter is typed" > > Is 444335 only about this scenario and therefore we can close this issue? Its 'only' about sticky modifier keys. As of today with plasma6 in wayland it sort of works. SHIFT and CTRL works (both left and right) However even Win, ALT and Alt Gr is needed with this behaivour. as of now I can't switch between activities (Win+TAB), switch between programs (ALT+TAB) or type '$' (Alt Gr+4 (swedish layout)) Meta key labels according to 'xev': keycode 50 (keysym 0xffe1, Shift_L) keycode 37 (keysym 0xffe3, Control_L) keycode 133 (keysym 0xffeb, Super_L) (key marked 'windows logo') keycode 64 (keysym 0xffe9, Alt_L) keycode 108 (keysym 0xfe03, ISO_Level3_Shift) (key marked 'alt gr') keycode 105 (keysym 0xffe4, Control_R) keycode 62 (keysym 0xffe2, Shift_R)
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5367
> However even Win, ALT and Alt Gr is needed with this behaivour. as of now I can't switch between activities (Win+TAB), switch between programs (ALT+TAB) or type '$' (Alt Gr+4 (swedish layout)) As far as I can tell Alt works as expected. Alt Gr was missing because keyboards are confusing. https://invent.kde.org/plasma/kwin/-/merge_requests/5367 fixes that. Meta/Win should work in principle as far as I can tell. However when pressing Meta the application launcher opens, so I don't get a chance to press the second key, breaking the UX here
(In reply to Nicolas Fella from comment #15) > I'm just not sure how relevant things like "Ring system bell when locking keys are toggled" > actually are I remember this (and audible confirmations for many other state changes) being mentioned as a requirement for software acceptance for use in Slovenian government offices. Sure the presentation was something like 15-20 years ago, but I doubt it has changed. And I suspect a couple of other public institutions in other countries might have the same requirement.
In response to "It would be great to have some input on which of these are most important/should be prioritized or which of them may be unimportant enough to drop them" I would say any accessibility features are going to have widely differing priorities depending who you ask. My impairment is purely motor, but others it's vision, motion, color, the list unfortunately is long. All these features exist because *someone* needs it. And by needs, I mean the system is utterly unusable without it. For that reason, any accessibility functions should be considered as hard blockers, imo.
Git commit 463d77ec183df20ef2b74916c1646b6e27a1d391 by Nicolas Fella. Committed on 10/07/2024 at 09:35. Pushed by nicolasfella into branch 'master'. Fix sticky keys for AltGr We map AltGr to Qt::GroupSwitchModifier, but then ignore it Instead map it to Mod5, which for some reason xkbcommon doesn't expose a define for Also, since the Qt modifiers enum doesn't map nicely to XKB modifiers introduce our own enum to avoid confusion M +31 -10 autotests/integration/sticky_keys_test.cpp M +7 -7 src/plugins/stickykeys/stickykeys.cpp M +23 -26 src/xkb.cpp M +15 -2 src/xkb.h https://invent.kde.org/plasma/kwin/-/commit/463d77ec183df20ef2b74916c1646b6e27a1d391
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/604
(In reply to Dan Snis from comment #8) > (In reply to Nicolas Fella from comment #6) > > May I add a future feature request to this.. > Make the "Lock Keys Status" indicator in the system-tray aware of the status > of the sticky-keys. https://invent.kde.org/plasma/kdeplasma-addons/-/merge_requests/604 does this
Git commit 0374acb1d82e827c254eeb1444cb0ce15aee635c by Nicolas Fella. Committed on 17/07/2024 at 11:33. Pushed by nicolasfella into branch 'Plasma/6.1'. Fix sticky keys for AltGr We map AltGr to Qt::GroupSwitchModifier, but then ignore it Instead map it to Mod5, which for some reason xkbcommon doesn't expose a define for Also, since the Qt modifiers enum doesn't map nicely to XKB modifiers introduce our own enum to avoid confusion (cherry picked from commit 463d77ec183df20ef2b74916c1646b6e27a1d391) M +31 -10 autotests/integration/sticky_keys_test.cpp M +7 -7 src/plugins/stickykeys/stickykeys.cpp M +23 -26 src/xkb.cpp M +15 -2 src/xkb.h https://invent.kde.org/plasma/kwin/-/commit/0374acb1d82e827c254eeb1444cb0ce15aee635c
All sub-tasks are closed, so this project is now completed!!! Thanks a lot, Nicolas Fella!
Git commit 3d22217681bd412ab93204409017fe528cea4df1 by Nicolas Fella. Committed on 04/11/2024 at 13:33. Pushed by nicolasfella into branch 'master'. [applets/keyboardindicator] Show when modifiers are latched/locked This indicates whether modifiers are latched/locked when using sticky keys in an unobtrusive manner This is useful to know which state the keys are in, which is important when using them to avoid surprises and mistyping Related: bug 158053 M +61 -4 applets/keyboardindicator/contents/ui/main.qml https://invent.kde.org/plasma/kdeplasma-addons/-/commit/3d22217681bd412ab93204409017fe528cea4df1