| Summary: | Hi-res scroll events aren't passed through to nested kwin-wayland | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | André M <andre.vmatos> |
| Component: | platform-wayland-nested | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | minor | CC: | kde, nate, poeticrpm, xaver.hugl |
| Priority: | NOR | ||
| Version First Reported In: | 6.4.5 | ||
| Target Milestone: | --- | ||
| Platform: | NixOS | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
André M
2025-09-15 12:19:43 UTC
I think it may be caused by this? https://invent.kde.org/plasma/kwin/-/blob/master/src/backends/wayland/wayland_backend.cpp#L139 Also (possibly related), cursor hotspots are not passed through correctly; even for default cursor and on breeze cursor theme, it's off horizontally by a few pixels, and non-default cursors are worse Yeah, pointer input in the nested backend will have to be ported away from kwayland and support for v120 events added. The hotspot issue is unrelated. A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8608 Git commit 859ac3326f781375476ff707584b93a8592f028c by Xaver Hugl. Committed on 08/01/2026 at 16:14. Pushed by zamundaaa into branch 'master'. backends/wayland: fix the cursor hotspot with scaling The hotspot on `OutputLayer` is in device pixels, but Wayland wants it in logical coordinates. M +1 -1 src/backends/wayland/wayland_egl_backend.cpp https://invent.kde.org/plasma/kwin/-/commit/859ac3326f781375476ff707584b93a8592f028c A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/8611 Hi-res scroll events (out of kwayland) would be nice, but a temp workaround/stopgap could be just providing multiplied discrete events, that'd be at least better than 0 Thank you for the hotspot fix, I'll try to compile kwin from master on my NixOS and report back. I have a similar issue, but I'm not knowledgeable enough about how scrolling works to know whether this bug report addresses the issue or whether I should file a new bug report. Using KDE on a host, any virtual machine run under virt-manager or boxes has uneven scrolling. So imagine scrolling on a web page: 3 lines -> 6 lines -> 3 lines -> 6 lines, etc. On Gnome virt-manager behaves as it should: 3 lines -> 3 lines -> 3 lines -> 3 lines, etc. I think this is because Gnome (mutter) detects when a client window can use hi-res scrolling and sends through hi-res data when it does- if it doesn't, it uses the legacy means of passing a scroll event. I should note that if I run virt-manager with "GDK_BACKEND=x11 virt-manager" it used to work correctly. This is a particularly annoying issue (especially when dealing with small text input boxes on web pages) because no alternatives exist for local viewing of VMs (karton isn't really there yet) with anywhere near the featureset. Is my issue related to this bug report, or should I file a new one? Git commit 863ff48acac21308b25f411818d985c8357f516c by Xaver Hugl. Committed on 12/01/2026 at 16:16. Pushed by zamundaaa into branch 'Plasma/6.5'. backends/wayland: fix the cursor hotspot with scaling The hotspot on `OutputLayer` is in device pixels, but Wayland wants it in logical coordinates. (cherry picked from commit 859ac3326f781375476ff707584b93a8592f028c) Co-authored-by: Xaver Hugl <xaver.hugl@kde.org> M +1 -1 src/backends/wayland/wayland_egl_backend.cpp https://invent.kde.org/plasma/kwin/-/commit/863ff48acac21308b25f411818d985c8357f516c (In reply to Jason from comment #8) > Is my issue related to this bug report, or should I file a new one? It's not related to this, and most likely a bug in the app / GTK. But yes, create a new bug report, and attach the output of > WAYLAND_DEBUG=1 command-to-run-app | grep pointer + scrolling a few clicks in the app's window before you close it there. |