SUMMARY When using a "pixel scrolling"[0] touchpad zooming in/magnifying your desktop is pretty much broken STEPS TO REPRODUCE 1. Get a touchpad with pixel scrolling, or a mouse with high-res scrolling 2. Hold Ctrl+Meta 3. Try zooming in OBSERVED RESULT If you scroll slowly it does not zoom in. You have to scroll really fast, to the point where you pretty much have no control anymore. I'm pretty sure this is caused by ignoring the distance value of the scroll events, I've seen very similar bug in other apps before. I don't know if this is caused by running on wayland, but it didn't happen in the past when I was on xorg. EXPECTED RESULT It should zoom in "pixel by pixel", just like it does for scrolling in applications. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.8 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 Kernel Version: 6.1.59-1-lts (64-bit) Graphics Platform: Wayland Processors: 8 × AMD Ryzen 7 4700U with Radeon Graphics Memory: 15.0 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: HP Product Name: HP ENVY x360 Convertible 15-ee0xxx System Version: Type1ProductConfigId [0] https://community.kde.org/Get_Involved/Design/Frequently_Discussed_Topics#Names_of_different_scrolling_effects
[Over a year after the initial filing (not by me), on plasma 6.2.80 according to systemsettings about but actually on the live-git-master ebuilds from the gentoo/kde project overlay, on wayland also, the bug remains in general but with slightly different behavior here as described below.] Heh! I'm looking at filed bugs in preparation for filing my own (zoom but otherwise unrelated). Thanks for "discovering" this feature for me. =:^) I'm a heavy user of the zoom keys on my keyboard but had no idea ctrl-meta-scroll-zoom was a thing. FWIW (now that I've discovered it) my touchpad's resolution is high-res and this works works "reasonably" (I often have problems with apps being way too sensitive if they're hard-coded to low-res scroll and can't be reconfigured), **BUT** there's a trick (or two, actually) to it. *** IMPORTANT *** First, configure your zoom effect to 1.01 zoom factor ([1] for instructions). I believe the default is 1.05, which is simply too fast (I just tried it) for scroll-zooming as it currently works. The rest is written assuming that 1.01 zoom factor. (I attempted to set 1.001 just to see what it would do, but the UI won't take the extra digit of resolution, so 1.01 appears the finest it'll take (below 1.00 the zoom direction reverses and 0.99 is the finest it'll take...).) * It works reasonably well when I "scroll-coast" aka "inertial-scroll, that is, "throw" the scroll by starting it and then lifting my fingers off the pad (which when normal scrolling usually keeps scrolling but "coasts" the scroll to a stop). By "reasonably well", I mean I can use it for medium-level zooming, then fine-tune if necessary using the keyboard scroll. Given that inertial-scroll isn't designed to be used for precise scrolling that's actually what I would expect from it. * With normal "non-inertial" scrolling (leaving the fingers on the touchpad) the behavior is near uncontrollable as you say: ** When scroll-zooming in from 1:1 normal size, non-inertial scroll-zooming will start to zoom in, then near immediately zoom back out, often to normal size but sometimes it stops before it gets quite back to normal size (especially if I lift my fingers as it's starting to zoom out). ** When already zoomed in, non-inertial scroll-zooming will *most* of the time (but not entirely predictably) zoom OUT regardless of whether I scroll up or down. The zoom-out is /very/ touchy but /can/ be controlled to /some/ extent, basically what I would expect from an effect configured for normal-res scrolling on my high-res touchpad. So for me: Given I just discovered scroll-zoom and already had the keyboard zoom set to 1.01 zoom factor for fine zoom control, relying on key-repeat to zoom to my desired level... Previously with 1.01 I had my desired fine zoom control for keyboard zoom, but zooming a large degree required a bit of patience, depending on the configured keyboard repeat rate. Using inertial-scroll zooming rather usefully gives me a faster way to zoom to a medium degree (repeat if zooming to a large degree), and I can still fine-zoom using the keyboard. --- [1] Zoom effect configuration, including zoom factor (for plasma/systemsettings/kwin 6.2.80 according to systemsettings about, I'm actually on git-master using the live ebuilds in the gentoo/kde overlay, updated a couple days ago): plasma systemsettings > Apps & Windows > Window Management > Desktop Effects > Accessibility > Zoom > (configure button).
*** Bug 500454 has been marked as a duplicate of this bug. ***
Update prompted by the bug-dup reminder... (In reply to Duncan from comment #1) > * It works reasonably well when I "scroll-coast" aka "inertial-scroll [but > w]ith normal "non-inertial" scrolling (leaving the fingers on the touchpad) > the behavior is near uncontrollable as you say: Something changed some days/weeks after posting that. Non-inertial scrolling works much better now tho it's still a bit touchy... > ** When scroll-zooming in from 1:1 normal size, non-inertial scroll-zooming > will start to zoom in, then near immediately zoom back out, often to normal > size but sometimes it stops before it gets quite back to normal size > (especially if I lift my fingers as it's starting to zoom out). > ** When already zoomed in, non-inertial scroll-zooming will *most* of the > time (but not entirely predictably) zoom OUT regardless of whether I scroll > up or down. I haven't seen either of these bugs in some time. Scroll/zoom direction is now as expected. =:^) > The zoom-out is /very/ touchy but /can/ be controlled to /some/ > extent, basically what I would expect from an effect configured for > normal-res scrolling on my high-res touchpad. This seems much better too, but not entirely fixed. Zoom to an appropriate level is at least doable now, but still faster than I'd like. I'm guessing the code checks for a hi-rez touchpad now and adjusts for it, but just not enough for /my/ case. Zoom speed seems to be 3-5X what I'd want now;slow enough I can get what I want if I'm careful and zoom back and forth a bit, whereas IIRC it was more like 10-20X before so nearly impossible to work with except using short inertial-scrolls to get /near/ what I wanted and then fine-tune with keyboard zoom. IOW, I still have to be careful to scroollll slooowwwlllyyy, but touchpad-zoom /is/ actually useful on its own now, unlike before where I had to fine tune with keyboard zoom. Of course having the zoom direction bugs fixed helped immensely with usability as well. =:^)
I tested ths with a Firefox window on two different systems with trackpads - 6.3.0 and git-master I was using Ctrl+two finger pinch I can confirm that on both systems, the zoom is overly sensitive.
(In reply to TraceyC from comment #4) > I tested ths with a Firefox window on two different systems with trackpads - > 6.3.0 and git-master > I was using Ctrl+two finger pinch > I can confirm that on both systems, the zoom is overly sensitive. FWIW what you're testing with ctrl-pinch in firefox is /not/ kwin/plasma's zoom mechanism for the entire desktop (including non-firefox windows), but firefox's own independent zoom mechanism (that will only zoom firefox, not non-firefox windows). That would therefore be firefox's bug and need filed with them, not kwin/kde's. The bug here is for the kwin full-desktop (and all apps including firefox) zoom mechanism, accessed with ctrl-meta (aka ctrl-win) two-finger-scroll (hard-coded, plus any hotkey configured at the location in comment #1 footnote #1).
Since this issue seems to have picked up activity now I've tried again now (different, newer laptop - not sure it matters). Apparently the behaviour has changed, now both scrolling directions seem to get "rounded up" to a full scroll event. The only saving grace that makes it at all usable with lower zoom factors is that, while the "zoom animation" is going on, it ignores further scroll events. This leads to the awkward behavior where the amount you zoom doesn't depend on on distance-scrolled, but the time-scrolled.
For any high precision scroll events - to my understanding - the correct behavior should be to skip the animation entirely, and instantly zoom by the zoom factor multiplied with the "fraction of a real scroll event" that's been scrolled since the last event was processed (which might need to summed up if the gpu/sw renderer is very slow and there have been more than the current one received.) In any case, a smooth zoom/scroll animation just isn't compatible with high precision scrolling exactly _because_ it doesn't stop when you do.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7429
Git commit 23fb51dd0d63b4b98debbf3b7c020043ff66e6a5 by Xaver Hugl. Committed on 01/04/2025 at 20:57. Pushed by zamundaaa into branch 'master'. input: accumulate delta for high resolution mice and touchpads Otherwise, shortcuts like zoom trigger insanely fast. This could still be improved on, to actually apply the partial delta to shortcuts where it makes sense (like zoom), but this at least makes it usable. M +12 -12 autotests/integration/lockscreen.cpp M +14 -7 src/globalshortcuts.cpp M +1 -1 src/globalshortcuts.h M +27 -24 src/input.cpp https://invent.kde.org/plasma/kwin/-/commit/23fb51dd0d63b4b98debbf3b7c020043ff66e6a5
Having found this bug through the KDE blog, I was reminded of a very similar bug I filed a few years ago: https://bugs.kde.org/show_bug.cgi?id=426716 Could this be related in any way concerning how touchpad scrolling events are processed?
(In reply to Frank Steinmetzger from comment #10) > [similar bug]: https://bugs.kde.org/show_bug.cgi?id=426716 Will reply there to avoid spamming this bug further, but thanks for the pointer.