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.
