It'll take two to three years till the user space components are available in distros, so that we can depend on it and devs running stable distros can develop on it.

Obvious problem: this requires (expensive) hardware.

(In reply to Martin Flöser from comment #1)
> 
> Obvious problem: this requires (expensive) hardware.
>

Do you mean monitors or GPUs? VRR is supported by low end GPUs as well. As for monitors, you can find 1920x1080 TN panel monitors with FreeSync support for under $200. So FreeSync doesn't appear to be equal to expensive hardware really.

Just in case, this can be helpful: https://www.amd.com/en/products/freesync-monitors

> 11:19 <pq> emersion, the compositor needs to set the VRR DRM property to allow VRR, when it detects the window that opted in being on direct scanout.

Does KWin even support direct scanout?

On wayland, no. It's on the TODO list. We want to.
on X, xserver can do some magic tricks to skip kwin.

Related Wayland issue: https://gitlab.freedesktop.org/wayland/wayland/issues/84#note_136147

In short, it requires new Wayland protocol extension first.

(In reply to Shmerl from comment #6)
> Related Wayland issue:
> https://gitlab.freedesktop.org/wayland/wayland/issues/84#note_136147
> 
> In short, it requires new Wayland protocol extension first.

Are you sure.   The reality here since Wayland applications are directly using EGL and the sync primitives are EGL.

https://wayland.freedesktop.org/docs/html/ch03.html#idm140152825611760
Basic wayland.

So to have freesync run most likely does not require any protocol change.

https://github.com/wayland-project/wayland-protocols/blob/master/stable/presentation-time/presentation-time.xml

If you are after the wayland protocol that needs any changes its the presentation-time.

"bitmask of flags in presented event"

May need a new flag for Freesync.  Or maybe its just vsync.

Wayland applications aren't supposed to be restricted to EGL. They can use WSI too (VK_USE_PLATFORM_WAYLAND_KHR and etc.).

(In reply to Shmerl from comment #8)
> Wayland applications aren't supposed to be restricted to EGL. They can use
> WSI too (VK_USE_PLATFORM_WAYLAND_KHR and etc.).

Again that path does not have required sync functionality in wayland.

When wayland was design EGL existed and Vulkan did not.

Reality here what you pass wl_buffer that is a platform particular buffer not in fact defined in wayland protocol.

Platform particular buffer contains all you sync stuff.

How to process platform particular contents of the wl_buffer that has to be sorted out but that is not a wayland protocol problem.

Wayland protocol is not a network server protocol like X11.    Its  local protocol.   Being a local protocol it can have platform particular things where it implemented..

Really this is not a wayland extension.

This would really be how does EGL use Vulkan buffers and how does Vulkan use EGL buffers and extract required information.

Wayland protocol particularly designed not to need changing just because a new sync system is made.

Drivers get updates and maintain compatibility with the interfaces they provide everything should work. 

Basically wayland protocol design should have no place for adaptive sync (FreeSync) because this is a platform particular thing and should in the wl_buffer where all other platform particular things should be.

So basically this problem should fall on mesa, nvidia and other graphics driver vendors to design the implementation.

This one is a big change of the Wayland design.    Don't have the compositor/wayland protocol inventing wheels to solve issues that should be solved at khronos.org.   Graphics drivers makes really should be able to advise/design how all this sync stuff works so it works the best because they understand the hardware.

There should be a use case of not using EGL. Not sure why it has to be required if you say that Wayland doesn't need to care about platform specifics. If you think EGL is required because Vulkan / WSI didn't exist in the past, then Wayland itself needs adjustment to take that into account today. From what I understood though, EGL is not a requirement.

And saying that compositors and drivers should handle sync logic can lead to complete mess of incompatible solutions (remember Nvidia's mess with other things). I don't find it a good idea, if no one will use the same method.

(In reply to oiaohm from comment #9)
> 
> Again that path does not have required sync functionality in wayland.
> 

Consensus is that it should be a Wayland protocol extension (see linked Wayland bug). That's what I expected. It will help to avoid reinventing the wheel differently in each compositor.

Regarding the OP, Sway 1.5 (beta) has implemented Adaptive Sync (VRR) by now:

* https://github.com/swaywm/sway/pull/5063
* https://github.com/swaywm/wlroots/pull/1987
! https://github.com/swaywm/sway/issues/5076

A possibly relevant merge request was started @ https://invent.kde.org/plasma/kwin/-/merge_requests/718

Git commit faddf0bf5f46953d10020b1fefead780bbef957c by Xaver Hugl.
Committed on 30/04/2021 at 14:18.
Pushed by zamundaaa into branch 'master'.

Wayland: variable refresh rate support

M  +17   -0    src/abstract_wayland_output.cpp
M  +6    -0    src/abstract_wayland_output.h
M  +9    -0    src/plugins/platforms/drm/drm_object_connector.cpp
M  +3    -0    src/plugins/platforms/drm/drm_object_connector.h
M  +27   -0    src/plugins/platforms/drm/drm_object_crtc.cpp
M  +4    -0    src/plugins/platforms/drm/drm_object_crtc.h
M  +63   -8    src/plugins/platforms/drm/drm_output.cpp
M  +5    -0    src/plugins/platforms/drm/drm_output.h
M  +33   -32   src/plugins/scenes/opengl/scene_opengl.cpp
M  +36   -2    src/renderloop.cpp
M  +24   -0    src/renderloop.h
M  +8    -0    src/renderloop_p.h
M  +29   -0    src/screens.cpp
M  +10   -0    src/screens.h
M  +16   -0    src/waylandoutputdevice.cpp
M  +1    -0    src/waylandoutputdevice.h
M  +16   -1    src/workspace.cpp

https://invent.kde.org/plasma/kwin/commit/faddf0bf5f46953d10020b1fefead780bbef957c