Sway Wayland Compositor Seeing Adaptive-Sync/VRR Support

[mroche]

This image totally describes what variable refresh rate does

Hah, gave me a good laugh there

Cheers,
Mike

[mdedetrich]

What are you talking about



This image totally describes what variable refresh rate does

Yeah I don't know what people are talking about here, VRR is independent of how much bandwidth you can push over a HDMI cable/port. VRR is only about the GPU telling the display how many frames it can send so that the display can adjust.

See https://www.pcgamingwiki.com/wiki/Gl...resh_rate_(VRR)

[shmerl]

It should become part of Wayland protocol first. I suppose Sway implementation is just an experiment, so no yet standard.

Details here: https://gitlab.freedesktop.org/wayla...land/issues/84

[ssokolow]

It should become part of Wayland protocol first. I suppose Sway implementation is just an experiment, so no yet standard.

Details here: https://gitlab.freedesktop.org/wayla...land/issues/84

The Wayland protocol deals with communication between the compositor and the applications. Aside from being something you'd aspire to get working first, I don't see how that has any relevance to communication between the compositor and the monitor on the matter of updating whole-desktop frames.

(That said, I would definitely like to see whole-desktop VRR in whatever compositor I eventually wind up using when it comes time to buy VRR-capable monitors. Maybe I could finally eliminate tearing across my triple-head setup by using VRR to simulate three monitors sharing the same pixel clock regardless of what heterogeneous mix I might be using.)

[mroche]

Yeah I don't know what people are talking about here, VRR is independent of how much bandwidth you can push over a HDMI cable/port. VRR is only about the GPU telling the display how many frames it can send so that the display can adjust.

See https://www.pcgamingwiki.com/wiki/Gl...resh_rate_(VRR)

Lifting this quote from an article: "With HDMI 2.1, VRR support becomes a mandatory feature of the standard, forcing both TV makers and device makers to adopt support for variable refresh rates." This seems more of an industry push to enforce support for this feature in panels. I.e. if LG, Samsung, etc wants to make a TV with HDMI 2.1 support, it needs VRR support which can then be utilized by peripheral devices. This is my understanding of the matter.

https://www.overclock3d.net/news/gpu_displays/nvidia_s_bringing_hdmi_2_1_vrr_support_to_its_rtx_20_series_gpus/1

Cheers,
Mike

[shmerl]

The Wayland protocol deals with communication between the compositor and the applications. Aside from being something you'd aspire to get working first, I don't see how that has any relevance to communication between the compositor and the monitor on the matter of updating whole-desktop frames.

(That said, I would definitely like to see whole-desktop VRR in whatever compositor I eventually wind up using when it comes time to buy VRR-capable monitors. Maybe I could finally eliminate tearing across my triple-head setup by using VRR to simulate three monitors sharing the same pixel clock regardless of what heterogeneous mix I might be using.)

That thread actually explains why it needs to be communicated by the protocol.

[yariv]

The Wayland protocol deals with communication between the compositor and the applications. Aside from being something you'd aspire to get working first, I don't see how that has any relevance to communication between the compositor and the monitor on the matter of updating whole-desktop frames.

(That said, I would definitely like to see whole-desktop VRR in whatever compositor I eventually wind up using when it comes time to buy VRR-capable monitors. Maybe I could finally eliminate tearing across my triple-head setup by using VRR to simulate three monitors sharing the same pixel clock regardless of what heterogeneous mix I might be using.)

For games you are probably right. For desktop use, this https://gitlab.gnome.org/GNOME/mutte..._requests/1042 as well as any follow up MRs is probably enough.

[remenic]

Back in august 2019, I mentioned not understanding why freesync needed to be implemented at a toolkit level. It's the compositor that knows how often the screen updates, so that's where freesync should be implemented. That it hasn't been tried before really suprises me. Maybe it can't be done and has to be done on a per-app basis, but my guess is that you only need a compositor that is freesync capable to make it just work everywhere.

[Danny3]

Kinda yes and kinda no. HDMI VRR is technically actually not specifically tied to any HDMI version, for example the latest XBox One is actually using VRR over HDMI 2.0b.

It would be more accurate to say that no device apart from XBox one is using VRR on HDMI (regardless of the HDMI port version). Different HDMI versions only specify the maximum amount of bandwidth that they can support.

In that case then they can probably do it and they should do it.
I mean if they decided to stick with such old hardware version, if there's a possibility to make in software then they should definitely do it.
Especially now when the new generation TVs are coming that many of them will have VRR from what I heard.