Do someone have the instructions/hints to make work sway with nvidia? I'd like to give it a shot.
Announcement
Collapse
No announcement yet.
Sway 1.5-RC1 Wayland Compositor Brings VRR / Adaptive-Sync, New Protocol Support
Collapse
X
-
Originally posted by theriddick View PostDoes this VRR work in multi monitor environments? in particular when one monitor doesn't do GSYNC. That was the BIG issue with X11 for me, couldn't use GSYNC when second monitor was connected even if the application wasn't running fullscreen on that second monitor, it just disables gsync all together.
The other issue was this VRR/Gsync function flickered on my freesync1 monitor whereas that flicker did not exist under windows..
- Likes 4
Comment
-
Originally posted by Zeioth View PostDo someone have the instructions/hints to make work sway with nvidia? I'd like to give it a shot.
There are overwhelming technical and non-technical arguments as to why we are not going to support it [nvidia]. Face it, we are never going to support them. There is absolutely no point bringing it up; you are not going to change our minds.Last edited by lucrus; 25 June 2020, 09:32 AM.
- Likes 3
Comment
-
Originally posted by shmerl View Post
There wasn't one way to do it, so either they all agree how to do it in consistent manner, or it will be over all the place in each implementation.
Wayland display server stores a number of buffers, one for each surface, and at some moment it composes a screen buffer from them and send it to the video driver. Also there are clients which may send to display server commands to replace a buffer of this surface. Without VRR support DS may wait for a vsync, then check if there were changes and compose a new screenbuffer.
To implement VRR support DS should just start a composition right after an application have updated it's surface. But, if there are more than one surfaces, this may lead to too frequent updates. So, compositor should decide which surfaces updates it should respect and which may wait until next occasion. This may be done by some protocol extension... But there will be many stupid programmers whose will activate this just to make animations smoother. So, perhaps it is better to use some simple heuristic, like attach VRR composition to a focused window or activate it for fullscreen apps only.
Comment
-
Originally posted by Khrundel View PostDo they really need anything to agree about?
Wayland display server stores a number of buffers, one for each surface, and at some moment it composes a screen buffer from them and send it to the video driver. Also there are clients which may send to display server commands to replace a buffer of this surface. Without VRR support DS may wait for a vsync, then check if there were changes and compose a new screenbuffer.
To implement VRR support DS should just start a composition right after an application have updated it's surface. But, if there are more than one surfaces, this may lead to too frequent updates. So, compositor should decide which surfaces updates it should respect and which may wait until next occasion. This may be done by some protocol extension... But there will be many stupid programmers whose will activate this just to make animations smoother. So, perhaps it is better to use some simple heuristic, like attach VRR composition to a focused window or activate it for fullscreen apps only.
Comment
-
Originally posted by Tsih View Post
VRR does work with multiple monitors on AMD, I've got 4k 60Hz and 1440p 144Hz monitors with VRR enabled. However I don't think nouveau supports G-sync and Sway doesn't work with the proprietary driver.
Comment
-
Originally posted by kravemir View Post
That makes perfect sense for composition of multiple windows. But, don't games need some more assistance with freesync, than just (not) waiting for vsync?
Comment
-
Originally posted by theriddick View Post
Yes but possibly both your monitors support VRR which is why it works? I have a 4k 60hz with VRR and one 1080p portrait monitor which does not have VRR.
- Likes 1
Comment
Comment