-
-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mouse events cause VRR redraws when direct scanout is inactive #855
Comments
This is unexpected to me. Niri will try to submit a frame to the monitor only if something changed, and games usually hide the mouse cursor, so if you move the mouse then nothing changes on screen (since it's invisible) and no frame is submitted, so VRR keeps working. And certainly nothing changes when you just click the mouse. If I test with Are you sure this is not caused by something else? |
I am certain of this. This footage is from a fresh Niri install with a barebones config and only the game running. You can see that even though it's an fps with a hidden cursor, there are still extra frames rendered on mouse movement that aren't rendered by the game itself. Around the end of the clip you can see me just spamming left click without moving the mouse. Those spikes are hard to pick up since they're just one frame so my monitor only shows them every few clicks or so. 20241210_173407.mp4 |
That also influences VRR for the other monitor for me btw. 20241210_175014.mp4 |
What if you try with mpv and moving the mouse over the other monitor? |
Same result. Again the quick spikes near the end are the result of clicking the mouse a lot. 20241210_180314.mp4 |
Well that's quite strange. Works fine here: doc_2024-12-10_10-11-17.mp4 |
Huh that's odd. There's certainly something going on here for me. This same exact issue (and I do mean completely identical) pops up on Hyprland without enabling the tacked on fix they've implemented to prevent cursor updates when it's active. On the other hand KDE somehow doesn't suffer from this issue at all. |
I found a way to reproduce: when mpv is not directly scanned out, I seem to have a similar issue. I'll look into what causes it. |
Oh that makes sense! I'm running two GPUs with the weaker one rendering everything while the other one handles games. That might prevent my system from directly scanning out, hence causing me to see an issue that otherwise flew under the radar. However I'm not sure why mpv did it as well considering that was running off the same GPU that niri itself was. |
I was able to reproduce the hidden cursor issue too with Half-Life 1. When it is directly scanned out it's fine, but if I disable direct scanout then it breaks in the same way.
Yes, cross-GPU scanout is probably disabled (I don't remember the specifics but there are driver bugs with it atm in some cases); not sure why same-GPU doesn't work for you. |
Niri currently doesn't have a way to prevent cursor updates from incurring a frame draw event seperate from those requested by a fullscreen application. This leads to issues with VRR, particularly in games where the mouse is used as an input. For example; in a first person shooter with a framerate cap of 60fps and VRR enabled on a 144Hz monitor, moving the mouse causes the end result rendered framerate to spike up to the max capable refresh rate of the monitor (144Hz) in spite of what the fullscreen game is actually rendering at (60Hz). Obviously the same goes for games where to cursor is visible as well. This also isn't isolated to mouse movements, but also to mouse button events as well, however that only makes a quick 1 frame spike which might make it hard to spot depending on what info your monitor's OSD allows you to see.
I believe this is a common issue with many Wayland compositors, but I was unsure if this was on Niri's radar so I figured I'd add it to the issues list. I'm not sure what the correct way of fixing this issue should be, but I know Hyprland implemented a band-aid fix for it which mostly works. As for if other WM's or DE's have properly fixed it, I have no idea.
I'm honestly unsure if this should be classified as a bug report or maybe an enhancement, but since it causes VRR to function oddly I've reported it as a bug.
System Information
The text was updated successfully, but these errors were encountered: