https://bugs.kde.org/show_bug.cgi?id=487670
f...@fellr.net changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #7 from f...@fellr.net --- I haven't managed to attach a debugger yet, but I'm still planning to do that. It's hard to catch because it's so short. However now that 6.1 is released, I can definitely confirm that: - The problem still exists as described in 6.1. And it definitely wasn't there in 6.0.5. Same driver version 555.52.04. The cursor stutters/skips frames*. It seems to be worse when system is under any load, like loading a browser page. It could be related to GPU load. - I have not experienced those multi-second hangs in 6.1 yet, this one might've been a beta issue. - VRR is disabled and has been disabled for a while, so this specific issue is not related to VRR. (Although, I do still use a VRR-capable monitor, but the monitor's own FPS overlay shows a constant 144 Hz) * I'll try to record a video later, but for now here's a more detailed description of what I see: The cursor moves smoothly at 144 Hz for about 30-60 seconds and then seems to drop the refresh rate to something like 10 Hz for a period of about 1 or 2 seconds before returning to normal. It looks like it's skipping frames because it "skips" across the screen for a second, and the low refresh rate looks really irregular. I also noticed something strange: when I run `drm_info | grep -C 3 =\ Cursor` to verify if the hardware cursor is in use, the framebuffer ID is always 0. But when I run `watch "drm_info | grep -C 3 =\ Cursor"`, I can see the framebuffer ID of the cursor plane oscillate between zero and a different values like 112 or 113. So it goes 0, then 112, then 0 again, then 113. It looks like the cursor plane is being recreated constantly. Does that help? -- You are receiving this mail because: You are watching all bug changes.