kwin-wayland zoom-effect just started (I think just started) reverting to proportional mouse tracking. The option continues to /say/ it's still on whatever other mouse-tracking, and setting something else does seem to work momentarily, but as soon as the (focus follows mouse) pointer focus switches windows, it's back to actually doing proportional. I tried all three other options, centered/push/disabled, and all three revert to proportional. I /believe/ this is a regression within the past week, as I /think/ it was working when I switched to wayland not much longer than that ago, but since I'm only about 10 days on plasma-wayland I can't say for /sure/ that it's a regression, maybe I just hadn't noticed it yet. FWIW I'm now on kwin commit 3acb1a788e592e8b8f1894c56330cfc2fb9663bb from my update a few minutes ago (with a quit to CLI and plasma-wayland restart, no *DM) to see if it was fixed before I filed a bug -- no luck. Just reading the log I /suspect/ the bug may be triggered by fe6c29607 Add windowID to EffectWindow due to window-switching triggering the revert-to-proportional, but building before 342961766 isn't first-try-simple due to the the seat/keyboard changes it adjusted to, and I've not yet tried revert-on-head or cherry-pick-on-old to test it.
(In reply to Duncan from comment #0) > I /suspect/ the bug may be triggered by fe6c29607 Bad theory. Tried right before it, 3281569c1, with 342961766 applied on top to build, and it still seems to go proportional. So three possibilities, it's before that, it's not a regression after all, or the trigger is in something other than kwin.
So there was a reason I didn't put "regression" in the title... Tried back to 592626150 (with 823e5b02e, 88f1883e9 and 342961766 applied on top to build against current kwayland_server) and everything's bad. While that may or may not have been after I first started the switch to wayland, it's quite likely to have been before I was zooming on wayland as the zoom keys I was using in X had to go thru evrouter for X to see them and I had to adjust things to zoom in wayland. So my first few days on wayland I didn't have zoom working at all. So it's likely to not be a regression on wayland after all and to have never worked properly there, always reverting to proportional mouse tracking no matter the settings. I simply hadn't noticed it yet. Either that or the regression is earlier than I'm testing, or in either something under kwin or in the commit named above that I was applying on top of the old versions in ordered to build against current kwayland-server. What's frustrating is that it starts to work the first time zoom is used after starting plasma-wayland or after resetting the option, so the code to do it is there and working, but a window-switch reverts it to proportional, so it doesn't /stay/ working.
Created attachment 133516 [details] hackpatch: prevent fallback to MouseTrackingProportional This relates to effects/zoom/zoom.cpp, ZoomEffect::recreateTexture(), which (at commit 786207a4b) is line 199-220. For some reason in zoom mode on wayland, after a window-switch (focusing a new window due to to focus-follows-mouse is the usual trigger here), cursor.image is null. Thus the if on line 203... if (!cursor.image().isNull()) ... falls thru to the else on line 216... ... that forces mouseTracking back to MouseTrackingProportional on line 218. This is a hack-patch that's not production-ready as I'm not a coder and don't know how to code up a test for wayland, nor do I understand why cursor.image is null in the first place unless wayland simply doesn't use cursor.image or perhaps due to a race condition and thus wouldn't consider disabling the fallback safe for production use. But by commenting the fallback, the hack-patch does demonstrate that the fallback is the issue and at least on wayland, falling back simply disables whatever the user set for no good reason, as things appear to continue as expected with that line commented. Additionally, the hack-patch allows me to work around the problem here until a proper fix appears in kwin-upstream.
A comment on another bug made me aware of the wayland/X flags, use 'em.
(In reply to Duncan from comment #4) > A comment on another bug made me aware of the wayland/X flags, use 'em. I know this is an old bug but do you remember which bug it was that you read? Or do you know what flags you're using to fix this weird zoom behavior?
(In reply to jacob ham from comment #5) > (In reply to Duncan from comment #4) > > A comment on another bug made me aware of the wayland/X flags, use 'em. > > I know this is an old bug but do you remember which bug it was that you > read? Or do you know what flags you're using to fix this weird zoom behavior? Misunderstanding. I was referring to the bug-classification flags (see the flags section of the bug). In this case, I set the wayland flag "+" and the X flag "-", indicating the bug only applied when running kwin on wayland, not when running it on X. And to my knowledge the bug remains (as of my last update about a week ago) as the hack-patch still applies and nothing in the kwin git logs has leapt out as a fix. Of course I'm not seeing it as I'm still applying the hack-patch. But they've been fixing a lot of wayland bugs recently so at my next update I should really test without the patch again and verify...
(In reply to Duncan from comment #6) > And to my knowledge the bug remains [but] > I should really test without the patch again and verify... As of 303132ae0 (from today) the bug remains. Back to the patch. =:^(
I can reproduce it on wayland. With X11 it works ok.
(In reply to Duncan from comment #3) > Created attachment 133516 [details] > hackpatch: prevent fallback to MouseTrackingProportional Commit 1f318a224: effects/zoom: Rework how cursor texture is managed ... removes the ZoomEffect::recreateTexture my hackpatch touched so that patch no longer applies locally. I've not yet built and tested the new code but it looks like it might fix this bug (as well as the more recent and severe bug #445412 which the commit was created against). I guess I'll soon find out. =:^)
(In reply to Duncan from comment #9) > Commit 1f318a224: effects/zoom: Rework how cursor texture is managed Yes, that fixes it. For those not on live-git, kwin_wayland --version reports 5.23.80. Presumably that means the fix will be in release 5.24.