Bug 499603 - Hardware cursor updates/movements temporarily disable VRR with Nvidia
Summary: Hardware cursor updates/movements temporarily disable VRR with Nvidia
Status: NEEDSINFO WAITINGFORINFO
Alias: None
Product: kwin
Classification: Plasma
Component: wayland-generic (show other bugs)
Version: 6.3.2
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-02-06 17:01 UTC by tempel.julian
Modified: 2025-03-20 03:46 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tempel.julian 2025-02-06 17:01:28 UTC
SUMMARY
When moving the hardware cursor with VRR in a game at 80fps, monitor refresh rate changes from 80Hz to 144Hz (vsync maximum) until the cursor is not moved anymore. Naturally, this doesn't look smooth. When forcing a software cursor via env var, monitor stays at 80Hz also with cursor movement and motion picture is smooth accordingly.

STEPS TO REPRODUCE
1. Start a game with visible hardware cursor with VRR enabled that runs at fps below maximum refresh rate (e.g. 80fps on 144Hz maximum refresh rate monitor).
2. Move the cursor.

OBSERVED RESULT
Monitor VRR OSD jumps to maximum refresh rate during cursor updates/movement.

EXPECTED RESULT
At 80fps, it should remain at 80Hz also with hardware cursor updates/movement for a smooth result. This is the case on Xorg, but not Wayland.

SOFTWARE/OS VERSIONS
Linux/KDE Plasma: 6.2.91-1 from recent KDE-Unstable repo, everything else up-to-date

ADDITIONAL INFORMATION
Nvidia RTX 3060, Nvidia driver 570.86.16 (open kernel module), Linux 6.13.1
Comment 1 Harald Weissmueller 2025-02-13 16:14:03 UTC
I would guess this is the same as Bug 499848, "Commit 9f8b9afa makes mouse movement break VRR scenarios", so a general problem with kwin 6.3.0 and not just with Nvidia drivers.

Here's a link to that commit, it is from January 29:

https://invent.kde.org/plasma/kwin/-/commit/9f8b9afa504c2592e93a866ae23f08a6ca946272
Comment 2 Zamundaaa 2025-02-13 17:29:25 UTC
*** This bug has been marked as a duplicate of bug 499848 ***
Comment 3 tempel.julian 2025-02-27 17:21:09 UTC
No change with 6.3.2. The commit description...

"Otherwise, every software cursor move triggers the next frame to be presented ASAP,
breaking adaptive sync while the cursor is moved."

...also doesn't seem to fit, as there seems to be a hardware cursor by default with Nvidia fullscreen VRR. And the issue went/goes away when explicitly forcing a software cursor via env var.

So not a duplicate after all?
Comment 4 Zamundaaa 2025-03-04 15:53:05 UTC
You're right, it doesn't affect this issue.

The code to delay cursor updates in KWin doesn't depend on any driver features; unless the driver does something really stupid with cursor updates in general, this really shouldn't be happening. From bug 487563 I know for sure that the NVidia driver isn't broken in this way.

Do you have some KWin environment variables set, forcing it to legacy modesetting maybe?
Comment 5 tempel.julian 2025-03-05 05:06:50 UTC
No env vars set. 

For the sake of trying everything, I've given

KWIN_DRM_NO_AMS=0
KWIN_FORCE_SW_CURSOR=0
KWIN_DRM_DELAY_VRR_CURSOR_UPDATES=1

a try: Result is unchanged. Only with KWIN_FORCE_SW_CURSOR=1 the refresh rate OSD of my monitor doesn't jump to 144Hz anymore when moving the cursor.
Comment 6 Bug Janitor Service 2025-03-20 03:46:59 UTC
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME.

For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging.

Thank you for helping us make KDE software even better for everyone!