Bug 499603

Summary:	Hardware cursor updates/movements temporarily disable VRR with Nvidia
Product:	[Plasma] kwin	Reporter:	tempel.julian
Component:	wayland-generic	Assignee:	KWin default assignee <kwin-bugs-null>
Status:	RESOLVED WORKSFORME
Severity:	normal	CC:	rropid, xaver.hugl
Priority:	NOR
Version First Reported In:	6.3.2
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed/Implemented In:
Sentry Crash Report:

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!

Comment 7 Bug Janitor Service 2025-04-04 03:46:45 UTC

🐛🧹 This bug has been in NEEDSINFO status with no change for at least 30 days. Closing as RESOLVED WORKSFORME.