SUMMARY After 9f8b9afa (core/outputlayer: when repaints are added, schedule the frame for them), cursor updates cause vsynced repaints for fullscreen apps even with VRR enabled. STEPS TO REPRODUCE 1. Use automatic VRR 2. Launch VRRTest in fullscreen mode and set FPS to an arbitrary value 3. Move the mouse OBSERVED RESULT The output stutters; cursor movement is always tied to the screen's refresh rate EXPECTED RESULT The output should not be affected by mouse movements, everything should remain smooth SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Kernel Version: 6.13.2-arch1-1 (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 5800X 8-Core Processor Memory: 62.7 GiB of RAM Graphics Processor: AMD Radeon RX 6600 XT
I don't know if it is the same that I'm experiencing, but while gaming, if I'm on game menu VRR kicks in As soon as I close the menu it is turned off https://photos.app.goo.gl/mDSBG1ouaUxAyMei8
I couldn't notice stuttering on my system running 2.1.0 version of the VRRTest appimage. Operating System: Fedora Linux 41 KDE Plasma Version: 6.3.80 KDE Frameworks Version: 6.12.0 Qt Version: 6.8.2 Kernel Version: 6.12.11-200.fc41.x86_64 (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 15.5 GiB of RAM Graphics Processor: AMD Radeon RX 6600
There is no stuttering on games or vrrTest, but the display refresh jumps to the max supported refresh, effectively disabling vsync.
I'm seeing the same here. I'm checking this out in WoW. I'm seeing the following: If the hardware mouse pointer is visible in the game, the framerate jumps to the monitor's maximum refresh rate on mouse movement. In this game I'm using to test, while you hold down the left/right mouse buttons you turn the game's camera and the game disables the mouse pointer, and in those moments a mouse movement will not put the refresh rate to max. The refresh rate only gets put to max when the pointer is visible and moving.
*** Bug 499603 has been marked as a duplicate of this bug. ***
This bug seems is still in 6.3.1. Is there a workaround for this? I tried setting environment variables KWIN_FORCE_SW_CURSOR=1 and KWIN_DRM_NO_AMS=1 and both didn't seem to work. I then ended up building kwin with these two commits reverted: https://invent.kde.org/plasma/kwin/-/commit/8291f8144b5a47c13fdf9da4af1a9d9623a3ce7c.patch https://invent.kde.org/plasma/kwin/-/commit/9f8b9afa504c2592e93a866ae23f08a6ca946272.patch And that seems to work without causing noticeable problems on my setup. Those commits mention Bug 498543. Reading through the description, it seems the problem there happened when changing the Night Light settings, but not while Night Light is in actual use? And moving the mouse around the screen would make the problem in the bug go instantly away? If this is the case, maybe reverting those commits for now and putting the Night Light problem back until the VRR mouse pointer problem can be fixed would be a good idea? This VRR mouse cursor problem here is bad, at least for me. I can't use Plasma 6.3 because of it (in the evening in games).
I've found that when games are launched with Mesa, mouse movements will deactivate VRR, as described here. However, if games are launched with AMDVLK instead, VRR will behave with mouse movement. Might be an acceptable workaround for games where AMDVLK has adequate performance, which many do not, unfortunately.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/7204
(In reply to Bug Janitor Service from comment #8) > A possibly relevant merge request was started @ > https://invent.kde.org/plasma/kwin/-/merge_requests/7204 I tried this 7204 patch applied on top of kwin 6.3.1 for a few minutes on the desktop and in a game and it seems to work fine.
Git commit a033e23d586bf8dd29d05beae98d6807548d04ed by Xaver Hugl. Committed on 20/02/2025 at 13:50. Pushed by zamundaaa into branch 'master'. core/renderloop: take vrr into account for output layer repaints Otherwise, every software cursor move triggers the next frame to be presented ASAP, breaking adaptive sync while the cursor is moved. FIXED-IN: 6.3.2 M +1 -1 src/core/outputlayer.cpp M +2 -2 src/core/renderloop.cpp M +2 -1 src/core/renderloop.h https://invent.kde.org/plasma/kwin/-/commit/a033e23d586bf8dd29d05beae98d6807548d04ed
Git commit 2d9cb31fe8756d9f6f6f38e49849fa77570e4350 by Xaver Hugl. Committed on 20/02/2025 at 15:02. Pushed by zamundaaa into branch 'Plasma/6.3'. core/renderloop: take vrr into account for output layer repaints Otherwise, every software cursor move triggers the next frame to be presented ASAP, breaking adaptive sync while the cursor is moved. FIXED-IN: 6.3.2 (cherry picked from commit a033e23d586bf8dd29d05beae98d6807548d04ed) Co-authored-by: Xaver Hugl <xaver.hugl@gmail.com> M +1 -1 src/core/outputlayer.cpp M +2 -2 src/core/renderloop.cpp M +2 -1 src/core/renderloop.h https://invent.kde.org/plasma/kwin/-/commit/2d9cb31fe8756d9f6f6f38e49849fa77570e4350