Provide zwp_linux_explicit_synchronization_unstable_v1

[romangg]

Resources

• Protocol xml: zwp_linux_explicit_synchronization_unstable_v1
• See mailing thread about its usefulness in modern graphics: Link
• wlroots WIP implementation: Link

Server plan

Three classes representing protocol objects:

• LinuxExplicitSynchronizationV1 (global)
• LinuxSurfaceSynchronizationV1
• LinuxBufferReleaseV1

LinuxSurfaceSynchronizationV1

Writing these alone looks rather simple. But the integration of LinuxSurfaceSynchronizationV1 with Surface might be difficult. On commit we want the wl_buffer to not yet be sampled.

Wrapland might only provide a getter on the Buffer object to tell the compositor if this Buffer has a fence. Then the compositor must listen for the fd signal (this task could be encapsulated in the Buffer object).

LinuxBufferReleaseV1

The events of LinuxBufferReleaseV1 can likely be processed in the Buffer class. Not sure about the fenced_release. What's the advantage to immediate_release if the client can not expect it to always be this one? Also should it be sent at the same time wl_buffer.release is sent?

[romangg]

mentioned in issue kwinft#3

[romangg]

marked this issue as related to kwinft#3

[romangg]

Note that there is a v2 proposed: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/90

[romangg]

[14:17] <romangg> What's your expectation regading the kernel discussion? You think the protocol can stay the same or you assume a lot might change depending on what kernel decides to do?
[14:20] <romangg> emersion: Do you think it still is worthwhile to also implement v1?
[14:20] <romangg> Or better to directly and only go for v2?
[14:20] <emersion> i'd expect the protocol to stay more or less the same, but the type of the FD to change
[14:20] <emersion> i don't think it's worthwhile to spend some cycles doing v1
[14:21] <emersion> "i'd expect the protocol to stay more or less the same" → i mean, same as WIP v2
[14:25] <romangg> Yes, I think I got what you said. You say: don't spend time on v1. And for v2 the final protocol that will be merged to wayland-protocols will likely be pretty similar to what you currently have in your WIP MR of v2.

[romangg]

So it is probably better to directly start implementing v2 of the protocol.

[romangg]

In GitLab by @aramgrigoryan on Aug 24, 2021, 17:44

what if something needs v1 too?

[romangg]

In case a client supports v1 but not v2, the client would fall back to implicit synchronization. This is not optimal but acceptable.

The most important client to consider though is Mesa, and this is guaranteed to be updated to v2 rather soon after the kernel bits are in place and the v2 Wayland protocol has been released.