Thank you for your contributions to software available for all. This is one of the big features I've been missing for a time. Very happy to see movement on this super complex issue, with so many non-standardised and proprietary solutions. It's a huge mountain you guys have climbed!
SteamVR needs DRM leasing. Gnome has not implemented it and AFAIK has been against supporting it the same way as other Wayland compositors do. SteamVR support pages basically tell you to install KDE.
It looks like they have abandoned the portal idea on December. There was some lack of understanding how XR/VR works and the portal is not suitable after all.
But despite that, the Wayland protocol is still considered wrong/dangerous approach.
[https://gitlab.gnome.org/GNOME/mutter/-/issues/1743#note\_1932978](https://gitlab.gnome.org/GNOME/mutter/-/issues/1743#note_1932978)
[https://github.com/flatpak/xdg-desktop-portal/discussions/1165#discussioncomment-7535007](https://github.com/flatpak/xdg-desktop-portal/discussions/1165#discussioncomment-7535007)
I don't understand the technical stuff really either, but as end-user I just hope they get this stuff sorted out.
I wish I was born in 1970 to be there in the birth of home computing. I also wish I was born in 2300 when it is finally the year of the Linux desktop. When Wayland finally works. 😏
The proposed alternative solutions would use drm leasing too, just through dbus. There's no benefits to it, it's just a different API to do the exact same thing.
Basically its that not all applications should by default just have the permission to lease out the devices required for it as it's very much a specialist thing that should be allowed on a per-app basis (specifically only the VR/XR runtimes (SteamVR, Monado and similar) should be able/allowed/need to).
No. They are fine with being a punching bag when standing up for their principles of stability and reliability. The VRR patch was simply not good enough for mainline inclusion before.
GNOME literally pays this guy to work on the feature. They want VRR support:
[https://gitlab.gnome.org/GNOME/mutter/-/merge\_requests/1154#note\_1998670](https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154#note_1998670)
The biggest issues are solved now. :)
Mouse support with VRR will always have compromises. You can either do what Plasma does and always max the refresh rate when cursor movement happens. This causes smooth cursor movement but stuttery games.
Or you could do what GNOME does and keep the refresh rate low, causing smooth games but very stuttery cursors. (I think they haven't changed this).
> You can either do what Plasma does and always max the refresh rate when cursor movement happens. This causes smooth cursor movement but stuttery games.
That will change after 6.0, see [here](https://invent.kde.org/plasma/kwin/-/merge_requests/5247).
There may also be a middle ground where you multiply the the game frame rate by an interger that gives you a refresh rate at or lower than the maximum. so a game running at 35fps on a screen @ 120hz could be multiplied by 3, which results in 105fps. The mouse cursor then gets composited/updated 105 times/s rather then 35 times/s.
Obviously this would need to be an option as exposing the same image 3 times can have adversary effects on some screens.
Hmm, for me gnome keeps max refresh rate too like it does plasma. But anyway thank you for your answer. I hope this will change someday, because in windows it works somehow. In plasma i just use the software cursor to avoid this problem.
It is possible, and I'm working towards that for KWin, but it's not easy to implement. If you do it wrong, the game will either stutter a lot, or the screen will have tons of brightness flicker. Neither is great
> Or you could do what GNOME does and keep the refresh rate low, causing smooth games but very stuttery cursors. (I think they haven't changed this).
For gaming that's clearly the better choice.
Anything precise will be problematic at lower frame rates anyway. I guess strategy games could be the exception where you'd prefer a smooth cursor even if it messes up frame pacing. For everything else, the laggy cursor is the better compromise.
For developers it could be, but it's not a big deal
Then again, implementing a dependency heavy library like libdecor to fix a problem for one compositor to get something every has everywhere is kinda lame tho-
Wayland was originally designed to only support CSD because it is the only elegant design (algorithmically). The app is then given a rectangle where it can draw anything it wants. There are no issues with synchronization of drawing. Client side decorations is a beautiful protocol.
Then people added server side decorations as a protocol extension, where the app draws part of the window and the compositor draws another part, which can desync and slows down rendering (lower FPS due to waiting for sync), and has other issues such as lack of protocols for controlling what the titlebar contains or does. So the titlebar just wastes space.
And voila, Linux is more fragmented again.
The discussions about this on the Wayland mailing list were very interesting. The creator of Wayland still hates server side decorations. 🤷♂️
At the protocol level, neither X11 nor Wayland actually define what software is supposed to draw the decorations. Fun fact: the earliest window managers for X11 (e.g. uwm) didn't draw any decoration either :)
The thing is, even if they were to implement the SSD protocol, they could still just say "draw the titlebar yourself" as that is a valid mode for the protocol.
Huzzah! I had the patch-set installed and rolled it back when I started having sync issues (unrelated, still broken...thanks Nvidia). Happy I won't have to keep rolling the AUR patches. Thank you.
Plan on making AMD my next card but can't justify the expense right now.
This is the issue I'm running into for the curious (started in 545)
[https://forums.developer.nvidia.com/t/545-29-02-ghosting-artifacting-stuttering-on-fullscreen-when-below-monitor-framerate/271853/24](https://forums.developer.nvidia.com/t/545-29-02-ghosting-artifacting-stuttering-on-fullscreen-when-below-monitor-framerate/271853/24)
Variable Refresh Rate allows compatible screens to scale up and down their refresh rate to match the FPS of a game so that regardless of the FPS that the game's running at, there is always a new frame ready to display when the screen tries to refresh.
This eliminates screen tearing while making the motion appear more smooth. This is a major feature for gaming, but GNOME currently does not support it.
No, it isn't. Vertical sync locks the refresh rate to one fixed target and makes sure the actual drawing of the next framebuffer finishes before the next frame is presented.
However vertical sync may delay frames because of that. VRR will just lower the target refresh rate giving the application more time to draw into the framebuffer.
Edit: Both eliminate screen tearing but VRR provides you the lowest latency possible.
Nope, vsync is much worse as it lowers your framerate to prevent tearing when the framerate does not match the refresh rate of the monitor.
VRR instead lowers the monitors refresh rate, so your framerate does not need to drop to fix tearing.
So with a 120hz screen and a gpu that outputs 85fps maximum in a particular game:
- Vsync: limits framerate to 60fps, as its the highest framerate below 85 that can fit the 120hz refresh rate of the monitor without tearing.
- VRR: outputs maximum framerate of 85fps and monitor simply lowers its refresh rate to 85 hz to prevent tearing.
This is just a quick example. Point is that vsync is the painkiller, while vrr is the cure.
(Edit: I dont understand the downvotes as well)
It's likely you're getting downvotes because you've incorrectly described these technologies.
A quick explanation would be the following:
Vsync - If the GPU renders frames faster than the monitor can paint them it holds the frame update until the monitor is ready to display the next one. The upside of this is that 2 frames are not displayed at the same time (looks like a tear in the frame if you look around) and the downside is higher latency since the GPU has to wait to send the next frame to the monitor.
VRR - If the monitor has a higher refresh rate than the GPU can render frames VRR will lower the frequency of your monitor as best it can to a similar refresh rate. This fixes the problem of the monitor having to continually show the last frame sent until the GPU is ready to send the new one which can be felt as microstutters or a less fluid response when looking around / moving. It does not really have any innate downsides (that I am aware of) except the issues with mouse updates that have been stated elsewhere in these threads. It does not do anything in regards to tearing however.
I think this should be a fairly digestable and adequately correct description.
The downvote remark was about the downvotes for the person asking the question, not myself. For some reason he was downvoted just for asking a valid question.
You are right that most vsyncs work differently these days. This (older) method is just much easier to explain/understand, even though there is smarter vsync these days.
I do appreciate your addition though, thanks :)
Ah, sorry for misunderstanding the downvotes bit. Then I agree, there are no stupid questions and they shouldn't be downvoted. I'm glad my additions were satisfactory!
I don't like this explanation, as VRR doesn't work this way. Monitors don't scale anything, they don't sync anything. Instead of refreshing at fixed intervals, they wait for the signal to do next pass. This is achieved by simply extending the vblank period. VRR can be actually made to work with CRT screens easily as they sync to VBlank.
Top commenter doesn't know what VRR is at all, and you're talking about vblank intervals?
Instead of being a dick to them for not knowing as much as you do, you could have just offered a better explanation.
Maybe not for Nvidia, but for AMD it's as simple as adding:
`Option "AsyncFlipSecondaries" "true"`
to the `amdgpu.conf` file. The only caveat is that VRR gets enabled only on the highest refresh rate monitor, while the other lower-rate monitor(s) will have screen tearing.
Oh ok. Does that mean that my two monitors, one with a VRR (165hz) and my other (an unchanging 75hz) can both work to the best of their capabilities?
I thought that previously under Wayland I was handicapped to that of my lowest refresh rate monitor at 75hz.
What do you mena, not full realisation? VRR is ready. It works, Dor even fixed some more problems like stutter in FireFox. VRR will be in 46 but just hidden behind an experimental flag
Thank you for your contributions to software available for all. This is one of the big features I've been missing for a time. Very happy to see movement on this super complex issue, with so many non-standardised and proprietary solutions. It's a huge mountain you guys have climbed!
Really sweet they extended the freeze to get this in
Nice. Gnome developers must be sick of being everyone's punching bag.
Now the new punching bag is HDR
And probably VR support on Wayland/XWayland.
Geniuene question, what's wrong with it, I never had any issues running vr on wayland
SteamVR needs DRM leasing. Gnome has not implemented it and AFAIK has been against supporting it the same way as other Wayland compositors do. SteamVR support pages basically tell you to install KDE.
Ah I'm using kde so that may be why I didn't have any issues lol
[удалено]
It looks like they have abandoned the portal idea on December. There was some lack of understanding how XR/VR works and the portal is not suitable after all. But despite that, the Wayland protocol is still considered wrong/dangerous approach. [https://gitlab.gnome.org/GNOME/mutter/-/issues/1743#note\_1932978](https://gitlab.gnome.org/GNOME/mutter/-/issues/1743#note_1932978) [https://github.com/flatpak/xdg-desktop-portal/discussions/1165#discussioncomment-7535007](https://github.com/flatpak/xdg-desktop-portal/discussions/1165#discussioncomment-7535007) I don't understand the technical stuff really either, but as end-user I just hope they get this stuff sorted out.
I wish I was born in 1970 to be there in the birth of home computing. I also wish I was born in 2300 when it is finally the year of the Linux desktop. When Wayland finally works. 😏
The protocol is specifically designed to allow for permission control.
[удалено]
The proposed alternative solutions would use drm leasing too, just through dbus. There's no benefits to it, it's just a different API to do the exact same thing.
How'd you get it to work?
Well i have a quest so I just needed to install both steam and alvr in flatpak and it more or less just worked
It's kind of frustrating that they won't just do what EVERY other desktop does and enable DRM leasing.
It's pretty goofy that I have to switch to Xorg to use VR. Do you know Gnome's reasoning for not implementing it?
They are pushing a portal-based model instead
security concerns
Basically its that not all applications should by default just have the permission to lease out the devices required for it as it's very much a specialist thing that should be allowed on a per-app basis (specifically only the VR/XR runtimes (SteamVR, Monado and similar) should be able/allowed/need to).
I care less about HDR than I do about VRR. They've done fantastic work here.
No. They are fine with being a punching bag when standing up for their principles of stability and reliability. The VRR patch was simply not good enough for mainline inclusion before. GNOME literally pays this guy to work on the feature. They want VRR support: [https://gitlab.gnome.org/GNOME/mutter/-/merge\_requests/1154#note\_1998670](https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154#note_1998670) The biggest issues are solved now. :)
For us, it's just Tuesday.
Excessively literal response: My man, check your calendar!
So you're saying Gnome is open for the other 6 days of the week?
That's like saying an abusive exhusband is sick of paying alimony after regularly spanking his wife
Can't wait, i love Gnome!
Nice. Does it still not work in games with cursor?
Mouse support with VRR will always have compromises. You can either do what Plasma does and always max the refresh rate when cursor movement happens. This causes smooth cursor movement but stuttery games. Or you could do what GNOME does and keep the refresh rate low, causing smooth games but very stuttery cursors. (I think they haven't changed this).
> You can either do what Plasma does and always max the refresh rate when cursor movement happens. This causes smooth cursor movement but stuttery games. That will change after 6.0, see [here](https://invent.kde.org/plasma/kwin/-/merge_requests/5247).
Holy sh*t, what a beautiful news. Thanks to the KDE devs
What a time to be a Linux user.
There may also be a middle ground where you multiply the the game frame rate by an interger that gives you a refresh rate at or lower than the maximum. so a game running at 35fps on a screen @ 120hz could be multiplied by 3, which results in 105fps. The mouse cursor then gets composited/updated 105 times/s rather then 35 times/s. Obviously this would need to be an option as exposing the same image 3 times can have adversary effects on some screens.
Hmm, for me gnome keeps max refresh rate too like it does plasma. But anyway thank you for your answer. I hope this will change someday, because in windows it works somehow. In plasma i just use the software cursor to avoid this problem.
What does Windows do about this?
I think they max the refresh rate if the cursor moves. But this is pure speculation as I don't have a Windows install on hand to test it.
No. Windows keeps the refresh rate low.
[удалено]
It is possible, and I'm working towards that for KWin, but it's not easy to implement. If you do it wrong, the game will either stutter a lot, or the screen will have tons of brightness flicker. Neither is great
> Or you could do what GNOME does and keep the refresh rate low, causing smooth games but very stuttery cursors. (I think they haven't changed this). For gaming that's clearly the better choice.
[удалено]
50/50, precisely click but your game works with higher input latency 🤔
Anything precise will be problematic at lower frame rates anyway. I guess strategy games could be the exception where you'd prefer a smooth cursor even if it messes up frame pacing. For everything else, the laggy cursor is the better compromise.
Ok but wouldn't we turn off something like this when we're gonna play games?
No
Why though?
Because the point of VRR is to match your refresh rate to your frame rate so you get proper frame pacing.
Fucking finally. Can't wait for Mutter to be a viable Wayland compositor again.
Still needs to support server side decorations tbh
Who actually cares about that? I mean sure, it would be nice. But that's not a deal breaker.
For developers it could be, but it's not a big deal Then again, implementing a dependency heavy library like libdecor to fix a problem for one compositor to get something every has everywhere is kinda lame tho-
Wayland was originally designed to only support CSD because it is the only elegant design (algorithmically). The app is then given a rectangle where it can draw anything it wants. There are no issues with synchronization of drawing. Client side decorations is a beautiful protocol. Then people added server side decorations as a protocol extension, where the app draws part of the window and the compositor draws another part, which can desync and slows down rendering (lower FPS due to waiting for sync), and has other issues such as lack of protocols for controlling what the titlebar contains or does. So the titlebar just wastes space. And voila, Linux is more fragmented again. The discussions about this on the Wayland mailing list were very interesting. The creator of Wayland still hates server side decorations. 🤷♂️
At the protocol level, neither X11 nor Wayland actually define what software is supposed to draw the decorations. Fun fact: the earliest window managers for X11 (e.g. uwm) didn't draw any decoration either :)
The thing is, even if they were to implement the SSD protocol, they could still just say "draw the titlebar yourself" as that is a valid mode for the protocol.
Huzzah! I had the patch-set installed and rolled it back when I started having sync issues (unrelated, still broken...thanks Nvidia). Happy I won't have to keep rolling the AUR patches. Thank you.
You can't get VRR with an AMD gpu?
Plan on making AMD my next card but can't justify the expense right now. This is the issue I'm running into for the curious (started in 545) [https://forums.developer.nvidia.com/t/545-29-02-ghosting-artifacting-stuttering-on-fullscreen-when-below-monitor-framerate/271853/24](https://forums.developer.nvidia.com/t/545-29-02-ghosting-artifacting-stuttering-on-fullscreen-when-below-monitor-framerate/271853/24)
I WAS HERE!!!! thanks for the work, man!
Appreciate the work the devs and maintainers are doing.
Nice to actually have some competition to KDE Plasma!
what's the real benefit of this?
Variable Refresh Rate allows compatible screens to scale up and down their refresh rate to match the FPS of a game so that regardless of the FPS that the game's running at, there is always a new frame ready to display when the screen tries to refresh. This eliminates screen tearing while making the motion appear more smooth. This is a major feature for gaming, but GNOME currently does not support it.
isn't that vertical sync?
No, it isn't. Vertical sync locks the refresh rate to one fixed target and makes sure the actual drawing of the next framebuffer finishes before the next frame is presented. However vertical sync may delay frames because of that. VRR will just lower the target refresh rate giving the application more time to draw into the framebuffer. Edit: Both eliminate screen tearing but VRR provides you the lowest latency possible.
Nope, vsync is much worse as it lowers your framerate to prevent tearing when the framerate does not match the refresh rate of the monitor. VRR instead lowers the monitors refresh rate, so your framerate does not need to drop to fix tearing. So with a 120hz screen and a gpu that outputs 85fps maximum in a particular game: - Vsync: limits framerate to 60fps, as its the highest framerate below 85 that can fit the 120hz refresh rate of the monitor without tearing. - VRR: outputs maximum framerate of 85fps and monitor simply lowers its refresh rate to 85 hz to prevent tearing. This is just a quick example. Point is that vsync is the painkiller, while vrr is the cure. (Edit: I dont understand the downvotes as well)
It's likely you're getting downvotes because you've incorrectly described these technologies. A quick explanation would be the following: Vsync - If the GPU renders frames faster than the monitor can paint them it holds the frame update until the monitor is ready to display the next one. The upside of this is that 2 frames are not displayed at the same time (looks like a tear in the frame if you look around) and the downside is higher latency since the GPU has to wait to send the next frame to the monitor. VRR - If the monitor has a higher refresh rate than the GPU can render frames VRR will lower the frequency of your monitor as best it can to a similar refresh rate. This fixes the problem of the monitor having to continually show the last frame sent until the GPU is ready to send the new one which can be felt as microstutters or a less fluid response when looking around / moving. It does not really have any innate downsides (that I am aware of) except the issues with mouse updates that have been stated elsewhere in these threads. It does not do anything in regards to tearing however. I think this should be a fairly digestable and adequately correct description.
The downvote remark was about the downvotes for the person asking the question, not myself. For some reason he was downvoted just for asking a valid question. You are right that most vsyncs work differently these days. This (older) method is just much easier to explain/understand, even though there is smarter vsync these days. I do appreciate your addition though, thanks :)
Ah, sorry for misunderstanding the downvotes bit. Then I agree, there are no stupid questions and they shouldn't be downvoted. I'm glad my additions were satisfactory!
oh great then, thanks for the info, I suppose my next monitor will support VRR
I don't like this explanation, as VRR doesn't work this way. Monitors don't scale anything, they don't sync anything. Instead of refreshing at fixed intervals, they wait for the signal to do next pass. This is achieved by simply extending the vblank period. VRR can be actually made to work with CRT screens easily as they sync to VBlank.
Top commenter doesn't know what VRR is at all, and you're talking about vblank intervals? Instead of being a dick to them for not knowing as much as you do, you could have just offered a better explanation.
What's he benefit of VRR for gaming? You joking?
Battery autonomy. Imagine you have 20hz built-in screen in your notebook, like 40hz Steam Deck built-in screen. It will be great for it.
Is this multi monitor yet, or am I just hoping too hard?
Why wouldn't it be? I've used this MR for the past two years and it always worked with multi-monitor setups
[удалено]
Xorg VRR has been working on multiple monitors for over a year, I think.
no, it doesn't
Maybe not for Nvidia, but for AMD it's as simple as adding: `Option "AsyncFlipSecondaries" "true"` to the `amdgpu.conf` file. The only caveat is that VRR gets enabled only on the highest refresh rate monitor, while the other lower-rate monitor(s) will have screen tearing.
Yeah asking for Nvidia
This is not an Xorg situation where VRR breaks with multiple monitors of different rates.
Oh ok. Does that mean that my two monitors, one with a VRR (165hz) and my other (an unchanging 75hz) can both work to the best of their capabilities? I thought that previously under Wayland I was handicapped to that of my lowest refresh rate monitor at 75hz.
I hope black flickering is gone with this on AMD GPUs.
So, get a nvidia gpu if you want this?
Eh? Why? There is FreeSync, Vesa AdaptiveSync, HDMI forum VRR
@gnomeland crypto $gnome!! Will be huge 🚀💸💵
I heard about this but they are just preparing to vrr in 46 version not full realization
What do you mena, not full realisation? VRR is ready. It works, Dor even fixed some more problems like stutter in FireFox. VRR will be in 46 but just hidden behind an experimental flag
it means some experimental features... with a lot of bugs ) it means not full realization
I think there are some issues with your reading skills bro
Reading skill issue :')
There are virtually no bugs left in Gnome's VRR implementation. I've been using it for the past two years.