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 with 1 vote (vote)
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: accessibility, wayland
Depends on: 464452 464453 464456 464457 464458
Blocks:
  Show dependency treegraph
 
Reported: 2021-10-24 17:10 UTC by Nick W
Modified: 2023-01-18 20:32 UTC (History)
7 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