Add a way to skip cursor-only updates during VRR

[Gwenodai]

I recently decided to give Niri another shot considering there's been quite a bit of development since I last checked in. Everything is really great so far, but I did notice something that makes me hesitant to use Niri as my daily driver, or at least not when I want to play certain games.

Normally when VRR is enabled the games refresh rate dictactes the the monitors refresh rate. However, with games where there is a visible on screen cursor this doesn't seem to be the case. Of the few games I've tested that make use of a visible cursor (BG3 and Mini Airways) they both seem to ignore the game refresh rate when the cursor is in motion. In that situation the cursor gets updated at the speed of the monitor, which for me is 144hz. This causes output to the monitor to be delivered at a full 144hz despite the game itself outputing a much lower framerate.

I'm not sure if this is expected behaviour in Niri at this point in its development or not, so I figured I should make a bug report. Especially since I'd previously made a similar bug report which turned out to be a different issue due to my particular hardware situation at the time (which is no longer the case).

I will note that I've tried the disable-cursor-plane debug flag in hopes that it might solve the issue, but it didn't work (although I doubted it would help here).

System Information

• niri version: niri 25.02 (0.0.git.1904.26618f8d)

• Distro: Fedora 41

• GPU: AMD RX 6700 XT

• CPU: AMD R9 3900X

[Gwenodai]

Ok there's one other strange thing I'd like to mention that I just realised after opening the issue. I just tested the issue in the Pixmark-Piano benchmark and noticed that while the issue also exists there (which makes sense as it's not doing anything special with the cursor, just rendering a GPU heavy scene), it doesn't when the benchmark is taken out of fullscreen. When only maximized, cursor movements don't incur extra VRR redraws at all and the actual refresh rate matches the benchmarks refresh rate. (See clip below)

This struck me as odd as I had expected that if anything, not being fullscreened (and assumedly not directly scanning out) would cause the cursor to redraw as often as it could. Having noticed this, I tried doing the same in BG3 and Mini Airways to no success. I also tried running them in a gamescope session to see if that would have any effect on the issue, but that also didn't change anything.

I don't know if this behaviour is specific to the benchmark, or if the VRR cursor issue is specific to just these games while not being present in other games with visible cursors of which I've not tested.

20250306_141536.mp4

[YaLTeR]

So since recently, Smithay allows the compositor to skip cursor updates in such cases, but I intentionally don't do that because I expect the cursor to always do full FPS (e.g. when watching a video in mpv with VRR). (Also the logic would be somewhat tricky to make sure it wouldn't break.)

Some things:

• Is this actually a big problem? For video playing at least I consider the current behavior better, but then you're not constantly moving the cursor while playing videos.
• disable-cursor-plane actually makes this more difficult to do, i.e. that Smithay thing I mentioned only works when you have cursor on a plane.
• If the game draws the cursor internally (rather than setting the Wayland cursor surface) then it won't be affected by this problem.
• Direct scanout or not should not affect this problem (other than triggering your other bug, which is a separate thing).

If this is a big problem for games, we could look into making cursor-only updates not trigger VRR with a flag or a window rule or something.

[Gwenodai]

Yes, I'd consider the current behaviour to be unsatisfactory when it comes to video games. With the current behaviour the outputting refresh rate will constantly spike up and down with mouse movements creating an unsmooth and juddery look to the gameplay unless the game is running at the max refresh rate of the screen. (But that defeats the purpose of VRR in the first place)

For example a game locked at 60fps with VRR would be outputting to the screen at 60hz. Which would appear smooth to the user. But upon moving the mouse, the gameplay becomes juddery and unsmooth as Niri then prioritises making sure that just the cursor is moving as smoothly as possible at 144hz to the detriment of the game considering the game refresh rate is essentially no longer being synced with the screen. The end result is, VRR is essentially "disabled" during mouse movements currently.

Major DE's/compositors out there (KDE and Windows) will only update the cursor movements with the games framerate in fullscreen games for this reason.

I understand you're 3rd point but, I'm not sure how many games do, and rely on programs to do that themselves still leaves all those that don't 'incompatible' with Niri (in that functionality at least)

If this is a big problem for games, we could look into making cursor-only updates not trigger VRR with a flag or a window rule or something.

I think this would be the correct solution, and doing it via window rules would probably be the easier implementation over whatever automatic implementation is used in KDE.

[AbsusRex]

Yes, I'd consider the current behaviour to be unsatisfactory when it comes to video games. With the current behaviour the outputting refresh rate will constantly spike up and down with mouse movements creating an unsmooth and juddery look to the gameplay unless the game is running at the max refresh rate of the screen. (But that defeats the purpose of VRR in the first place)

For example a game locked at 60fps with VRR would be outputting to the screen at 60hz. Which would appear smooth to the user. But upon moving the mouse, the gameplay becomes juddery and unsmooth as Niri then prioritises making sure that just the cursor is moving as smoothly as possible at 144hz to the detriment of the game considering the game refresh rate is essentially no longer being synced with the screen. The end result is, VRR is essentially "disabled" during mouse movements currently.

Major DE's/compositors out there (KDE and Windows) will only update the cursor movements with the games framerate in fullscreen games for this reason.

I understand you're 3rd point but, I'm not sure how many games do, and rely on programs to do that themselves still leaves all those that don't 'incompatible' with Niri (in that functionality at least)

If this is a big problem for games, we could look into making cursor-only updates not trigger VRR with a flag or a window rule or something.

I think this would be the correct solution, and doing it via window rules would probably be the easier implementation over whatever automatic implementation is used in KDE.

Another point I'd like to add is that some monitors have changes in brightness when the refresh rate changes. That's usually barely noticeable, but if you have sudden refresh rate changes (e.g. game renders at 60fps but then the mouse moves and it spikes to 144Hz) it can be quite annoying.

And while lots of games support software rendered cursors, where that issue doesn't occur, they often have a very noticeable input lag (FFXIV is basically not playable for me with the software cursor)