Summary: | On Wayland, scrolling speed being scaled causes scroll-based UIs (e.g. switching virtual desktops, changing volume) to go at a different speed than was intended | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | Alfred <home.isfar+kde> |
Component: | wayland-generic | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | minor | CC: | bugseforuns, john, kde, nate, xaver.hugl |
Priority: | NOR | Keywords: | usability, wayland-only |
Version First Reported In: | 5.26.4 | ||
Target Milestone: | --- | ||
Platform: | Fedora RPMs | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Alfred
2022-12-01 19:37:01 UTC
Scrolling on the desktop, you mean? Yes. I meant try to scroll the mouse wheel (up/down) while the cursor is hovering the over the desktop. As far as I know by default this action should move the user to the next/previous virtual desktop. Ok, I can reproduce this. I'm pretty sure that it happens because on Wayland, we're scaling all input events to approximate a scroll speed setting, which Libinput doesn't provide. We would have to de-scale the scroll events in Plasma to ensure a consistent scroll speed for things that should stick to the logic of one mouse wheel "tick" equaling one change in the thing being scrolled Scrolling speed also affects the zoom adjustment with ctrl+scrolling in Gwenview. Gwenview 24.01.85 Operating System: Arch Linux KDE Plasma Version: 5.91.0 KDE Frameworks Version: 5.247.0 Qt Version: 6.7.0 Graphics Platform: Wayland *** This bug has been marked as a duplicate of bug 470746 *** |