fwwi, most (all?) effect settings aren't applied to a running kwin since 5.0 here.
"kwin_x11 --replace &" should use the updated config?

For me the setting is applied immediately, but after a few minutes reverts by itself. If I log out, the setting is proplerly "Push" again, but after a couple of minutes... reset itself.

can you please attach ~/.config/kwinrc ?

Here is my kvimrc:
[Compositing]
OpenGLIsUnsafe=false

[Effect-Zoom]
MouseTracking=2

[Plugins]
invertEnabled=true
[manjaro@manjaro .config]$ cat kwinrc 
[Compositing]
OpenGLIsUnsafe=false

[Effect-Zoom]
EnableFocusTracking=true
MouseTracking=2

[Plugins]
invertEnabled=true


(While writing this comment, Zoom has again decided to use Proportional, even though the kvimrc says MouseTracking=2 (Push).)

the support information should include the runtime settings for zoom as well.

Please run:
qdbus org.kde.KWin /KWin supportInformation

once when it's working in zoom, and once when it's not working. Ideally there should be a difference.

You are right, there is a difference with qdbus.

When I first ran it with correct settings, there is a line that says mouseTracking: 2. Now after awhile it reads mouseTracking: 0.

I don't know exactly what triggers this change, but on this specific occasion I had clicked in the Firefox address bar and just hit the backspace key, and then this setting changed by itself. Maybe something to do with focus tracking assuming a specific setting?

We'll likely fail to create a cursor pixmap - no idea why that would happen "after some time™" only.
run "kwin_x11 --replace &" from konsole and watch the output - should say "Falling back to proportional mouse tracking!" at some point.

Maybe firefox/whatever replaces the cursor with a pixmap cursor and xcb_xfixes_get_cursor_image* doesn't support this?

Restarting kwin shows a few errors like these>
QMetaProperty::read: Unable to handle unregistered datatype 'KWayland::Server::SurfaceInterface*' for property 'KWin::Toplevel::surface'
QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1656, resource id: 0, major code: 14 (GetGeometry), minor code: 0
QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1657, resource id: 0, major code: 14 (GetGeometry), minor code: 0
QXcbConnection: XCB error: 9 (BadDrawable), sequence: 1658, resource id: 0, major code: 14 (GetGeometry), minor code: 0

I don't know whether they have anything to do with Zoom, but looking at the code it would make sense if the xcb_xfixes_get_cursor_image call fails - it is the only place where I see the tracking being explicitly set to proportional again. Why is this done?

no the pasted errors are not related, they are from GetGeometry calls.

Because it's the only mode where the visual pointer position matches the actual one.
If we cannot replace the pointer with an image, we cannot scale it nor show it off-place.

PS, the warning would show up when the mode resets, not when restarting KWin.
You may also need to explicitly enable effects debug out, but I don't see the string for the category, ie. it's probably not configurable at all?

Thanks, I see.

To preserve the tracking mode, could we instead use the previous cursor image if the call to get a new one fails? I have no idea why the call would fail, but if it succeeds again soon thereafter, a few frames with the "incorrect" cursor image would be less of a problem than reverting to proportional tracking.

We should first ensure this is the cause and ideally figure why the image request fails (in case) - you could easily run into this as initial case (so there's no cursorimage to stick with)

Can you spot a pattern?  (like "whenever I hover element foo in application bar")

I am unfortunately not able to replicate the issue consistently. I can get it to happen frequently with the following procedure, but it's definitely not always the case:

1. I move the pointer to the bottom left corner of the screen, where the menu button is.
2. Sometimes the above is enough to trigger the problem. If not, it can happen if I then move the pointer along the bottom of the screen towards the bottom right corner.

I can say there is definitely something going on with the cursor image though, as after playing around for awhile, the defalt cursor changed to the "up-and-down scrolling" cursor. In that case, when I turned off Zoom the cursor image reverted to the proper arrow. I then went ahead and changed the desktop theme to Breeze Dark and that caused a dark strip to appear at the bottom of the zoomed-in view.

I would really like to help debug this more properly, but since I need a usable screen magnifier all the time to use the computer, it becomes quite the challenge.

Completely untested, I'd still prefer know to why getting the cursor image would fail.

diff --git a/effects/zoom/zoom.cpp b/effects/zoom/zoom.cpp
index 72a976f..1807c3c 100644
--- a/effects/zoom/zoom.cpp
+++ b/effects/zoom/zoom.cpp
@@ -207,8 +207,15 @@ void ZoomEffect::recreateTexture()
         free(ximg);
     }
     else {
-        qCDebug(KWINEFFECTS) << "Falling back to proportional mouse tracking!";
-        mouseTracking = MouseTrackingProportional;
+        if ((effects->isOpenGLCompositing() && texture.isNull())
+#ifdef KWIN_HAVE_XRENDER_COMPOSITING
+            || (effects->compositingType() == XRenderCompositing && xrenderPicture.isNull())
+#endif
+                                                                ) {
+            qCDebug(KWINEFFECTS) << "Falling back to proportional mouse tracking!";
+            mouseTracking = MouseTrackingProportional;
+        }
+        // keep old texture rather than altering the behavior, bug #362898
     }
 }

I'm having exactly this bug, and I agree that it's frustratingly difficult to spot a pattern. The only significant thing that I've managed to figure out is that it usually happens fairly quickly after logging in, usually within five minutes or so. But, after it happens, if I go into Desktop Effects and manually change the Zoom mode from Push to Proportional and back, it seems to stick. I have had it revert to Proportional even after to doing this, but it's much less frequent. Not sure if that helps at all.

Another thing I noticed (Forgive me if there is an Edit Comment button; I couldn't find it.) is that it's very likely to revert to Proportional when I'm typing in Firefox's address bar. The magnifier seems to "snap" to focus on what I'm typing and then immediately revert to Proportional. I didn't see any such focus option in KDE - and I would've disabled it if I had - so I'm a bit confused as to what's going on there.

Please tell me if there are any logs I can post or commands I can run to help. This bug drives me nuts, and I'd love to see it squashed.

There's no edit function and it's actually no bug.

It seems firefox (what a surprise) can cause the server to return a null cursor image (maybe it hides it? in a weird way) and we just resolves this as general problem the most robust way (the consideration was rather that fetching the cursor image could fail in general)

However, bug or not, shit happens and it's probably more elegant to resolve it by keeping the cursor (iff any present, see comment #15 for a patch), notably when considering this an a11y feature.

"kcmshell5 kwineffects", configure the zoom effect, there's a checkbox for focus tracking. If this rather happens because FF warps the pointer, this won't have any impact, though.

I can confirm that it seems to often happen in Firefox, though it does happen on the KDE desktop as well, without any applications open, when moving the cursor to the corners a few times.

I know this is old... but it is still occurring in KDE Plasma 5.19.5. It seems like the problem I experience daily with the mouse tracking changing from "push" to "proportional" is identical to what's happening here. One small caveat... I do not use firefox. For me the problem is most likely to occur when I move the mouse to the KDE taskbar and/or Application launcher.