[wayland-protocols,2/3] linux-explicit-synchronization: Warn about using the protocol while using graphics APIs

Submitted by Alexandros Frantzis on Nov. 29, 2018, 9:35 a.m.

Details

Message ID 20181129093530.3400-3-alexandros.frantzis@collabora.com
State Accepted
Series "Updates to linux-explicit-synchronization"
Commit 08903bdf90d8051b9e650ac2bcef3d73188a03e6
Headers show

Commit Message

Alexandros Frantzis Nov. 29, 2018, 9:35 a.m.
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 <alexandros.frantzis@collabora.com>
---
 .../linux-explicit-synchronization-unstable-v1.xml          | 6 ++++++
 1 file changed, 6 insertions(+)

Patch hide | download patch | download mbox

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"

Comments

Pekka Paalanen Dec. 14, 2018, 11:58 a.m.
On Thu, 29 Nov 2018 11:35:29 +0200
Alexandros Frantzis <alexandros.frantzis@collabora.com> 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 <alexandros.frantzis@collabora.com>
> ---
>  .../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 <pekka.paalanen@collabora.com>

Thanks,
pq