On Thu, 29 Nov 2018 11:35:29 +0200
Alexandros Frantzis <[email protected]> wrote:

> Graphics APIs are expected to use this protocol under the hood, and
> since there can only be one user of explicit synchronization per
> surface, warn about using the protocol directly in such cases.
> 
> Signed-off-by: Alexandros Frantzis <[email protected]>
> ---
>  .../linux-explicit-synchronization-unstable-v1.xml          | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git 
> a/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
>  
> b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
> index 5809b42..6d5783d 100644
> --- 
> a/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
> +++ 
> b/unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
> @@ -66,6 +66,12 @@
>  
>          If the given wl_surface already has an explicit synchronization 
> object
>          associated, the synchronization_exists protocol error is raised.
> +
> +        Graphics APIs, like EGL or Vulkan, that manage the buffer queue and
> +        commits of a wl_surface themselves, are likely to be using this
> +        extension internally. If a client is using such an API for a
> +        wl_surface, it should not directly use this extension on that 
> surface,
> +        to avoid raising a synchronization_exists protocol error.
>        </description>
>  
>        <arg name="id" type="new_id"

Reviewed-by: Pekka Paalanen <[email protected]>

Thanks,
pq

Attachment: pgpz9aC8f88zM.pgp
Description: OpenPGP digital signature

_______________________________________________
wayland-devel mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to