From a281783339f7be4d5b6a65c2ba0a6d70ed6d0f1d Mon Sep 17 00:00:00 2001 From: Scott Anderson Date: Mon, 13 May 2019 21:40:12 +1200 Subject: wayland.xml: Make releases for multiple 'wl_surface.attach' undefined Fixes #46 The way wl_buffer is specified makes this situation inherently racy, meaning there is no way this can be done unambiguously. Current real compositor implementations already have differing behaviour for this, so any client relying on it was already broken, if any such client exists. This specifically only singles out wl_buffer.release as being undefined; every other aspect of it should still be valid. This is so existing and correct uses of multiple attaches are still valid, where a "static"/immutable wl_buffer is being used (i.e. they don't care about the release event). Signed-off-by: Scott Anderson --- protocol/wayland.xml | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'protocol') diff --git a/protocol/wayland.xml b/protocol/wayland.xml index d1b28be..50fe381 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1368,6 +1368,12 @@ will not receive a release event, and is not used by the compositor. + If a pending wl_buffer has been committed to more than one wl_surface, + the delivery of wl_buffer.release events becomes undefined. A well + behaved client should not rely on wl_buffer.release events in this + case. Alternatively, a client could create multiple wl_buffer objects + from the same backing storage or use wp_linux_buffer_release. + Destroying the wl_buffer after wl_buffer.release does not change the surface contents. However, if the client destroys the wl_buffer before receiving the wl_buffer.release event, the surface -- cgit v1.2.3-70-g09d2