Skip to content
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

Open
Gwenodai opened this issue Dec 10, 2024 · 10 comments
Open

Mouse events cause VRR redraws when direct scanout is inactive #855

Gwenodai opened this issue Dec 10, 2024 · 10 comments
Labels
bug Something isn't working

Comments

@Gwenodai
Copy link

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

  • niri version: niri 0.1.10 (0.0.git.1533.9824321f)
  • Distro: Fedora 41
  • GPU: AMD RX 470 + AMD RX 6700 XT
  • CPU: AMD Ryzen 9 3900X
@Gwenodai Gwenodai added the bug Something isn't working label Dec 10, 2024
@YaLTeR
Copy link
Owner

YaLTeR commented Dec 10, 2024

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 mpv and https://bxt.rs/files/test-videos/60.mp4 then moving the mouse over mpv does break VRR (since the mouse is visible, mpv doesn't hide it when you move the mouse), but moving the mouse over a second monitor keeps VRR working just fine.

Are you sure this is not caused by something else?

@YaLTeR YaLTeR added the question Further information is requested label Dec 10, 2024
@Gwenodai
Copy link
Author

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

@Gwenodai
Copy link
Author

moving the mouse over a second monitor keeps VRR working just fine.

That also influences VRR for the other monitor for me btw.

20241210_175014.mp4

@YaLTeR
Copy link
Owner

YaLTeR commented Dec 10, 2024

What if you try with mpv and moving the mouse over the other monitor?

@Gwenodai
Copy link
Author

Same result. Again the quick spikes near the end are the result of clicking the mouse a lot.

20241210_180314.mp4

@YaLTeR
Copy link
Owner

YaLTeR commented Dec 10, 2024

Well that's quite strange. Works fine here:

doc_2024-12-10_10-11-17.mp4

@Gwenodai
Copy link
Author

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.

@YaLTeR
Copy link
Owner

YaLTeR commented Dec 10, 2024

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.

@YaLTeR YaLTeR removed the question Further information is requested label Dec 10, 2024
@YaLTeR YaLTeR changed the title Mouse events incur extra frame draw events at all times (This hinders VRR functionality in fullscreen applications) Mouse events cause VRR redraws when direct scanout is inactive Dec 10, 2024
@Gwenodai
Copy link
Author

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.

@YaLTeR
Copy link
Owner

YaLTeR commented Dec 10, 2024

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.

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.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants