diff options
| author | Scott Anderson <scott.anderson@collabora.com> | 2019-05-13 21:40:12 +1200 |
|---|---|---|
| committer | Simon Ser <contact@emersion.fr> | 2019-07-09 17:26:11 +0000 |
| commit | a281783339f7be4d5b6a65c2ba0a6d70ed6d0f1d (patch) | |
| tree | eac4090a1fd75d56a1f34728b6b7f7dafba1ba4b /protocol | |
| parent | protocol: clarify wl_display.delete_id description (diff) | |
| download | wayland-a281783339f7be4d5b6a65c2ba0a6d70ed6d0f1d.tar wayland-a281783339f7be4d5b6a65c2ba0a6d70ed6d0f1d.tar.gz wayland-a281783339f7be4d5b6a65c2ba0a6d70ed6d0f1d.tar.bz2 wayland-a281783339f7be4d5b6a65c2ba0a6d70ed6d0f1d.tar.lz wayland-a281783339f7be4d5b6a65c2ba0a6d70ed6d0f1d.tar.xz wayland-a281783339f7be4d5b6a65c2ba0a6d70ed6d0f1d.tar.zst wayland-a281783339f7be4d5b6a65c2ba0a6d70ed6d0f1d.zip | |
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 <scott.anderson@collabora.com>
Diffstat (limited to 'protocol')
| -rw-r--r-- | protocol/wayland.xml | 6 |
1 files changed, 6 insertions, 0 deletions
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 |