That's not true; you can post back a sync token every time the client buffer is used by the compositor.
Technically, yes but it's very cumbersome and invasive to the point where it becomes impractical. Explicit sync is much cleaner solution.
For instance, Mesa adds the `wl_drm` extension, which is used for bidirectional communication between the EGL implementations in the client and compositor address spaces, without modifying either.
Broadcom driver adds "wl_nexus" extension which servers similar purpose for both EGL and Vulkan WSI
OK. As it stands, everyone else has the kernel mechanism (e.g. via dmabuf resv), so in this case if you are reinventing the underlying platform in a proprietary stack, you get to solve the same problems yourselves.
That's an important point. In the explicit synchronisation scenario the sync token is passed with the buffer. It becomes irrelevant where the token originated from, as long as it's a commonly used type of token, i.e. dma_fence in kernel space or sync_fd in user space. That allows for greater flexibility and works with and without dma reservation objects.
Cheers, Tomek