Bug 444335 - Full sticky keys functionality does not work under Wayland
Summary: Full sticky keys functionality does not work under Wayland
Status: ASSIGNED
Alias: None
Product: kwin
Classification: Plasma
Component: input (show other bugs)
Version: 5.22.5
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: accessibility, wayland
Depends on: 464453 464456 464457 464452 464458
Blocks:
  Show dependency treegraph
 
Reported: 2021-10-24 17:10 UTC by Nick W
Modified: 2024-03-05 22:16 UTC (History)
13 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Nick W 2021-10-24 17:10:44 UTC
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
Comment 1 Vlad Zahorodnii 2021-10-25 16:05:33 UTC
I'm not sure that it's wired anywhere in on wayland.
Comment 2 Robert Kratky 2022-01-08 10:17:21 UTC
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
Comment 3 Dan Snis 2022-03-12 20:04:19 UTC
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
Comment 4 Nick W 2022-04-30 22:01:35 UTC
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.
Comment 5 Robert Kratky 2022-06-18 11:14:30 UTC
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.)
Comment 6 Nicolas Fella 2022-10-04 16:41:51 UTC
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
Comment 7 Bug Janitor Service 2022-12-27 02:35:03 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/3365
Comment 8 Dan Snis 2022-12-29 09:50:10 UTC
(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.
Comment 9 Nicolas Fella 2022-12-29 12:44:28 UTC
(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?
Comment 10 Nicolas Fella 2023-01-18 14:05:52 UTC
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
Comment 11 Marius P 2023-11-30 16:12:09 UTC
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?
Comment 12 Dan Snis 2023-12-03 12:00:50 UTC
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.
Comment 13 Nick W 2023-12-08 20:52:01 UTC
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.
Comment 14 Nicolas Fella 2023-12-17 19:27:31 UTC
> 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
Comment 15 Nicolas Fella 2023-12-17 19:31:49 UTC
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
Comment 16 Ganton 2023-12-21 16:24:36 UTC
> 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...
Comment 17 Dan Snis 2024-03-05 18:39:33 UTC
(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)
Comment 18 Bug Janitor Service 2024-03-05 19:34:47 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/5367
Comment 19 Nicolas Fella 2024-03-05 19:37:08 UTC
> 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
Comment 20 Jure Repinc 2024-03-05 20:02:32 UTC
(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.
Comment 21 Nick W 2024-03-05 22:16:40 UTC
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.