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>
This commit is contained in:
Scott Anderson 2019-05-13 21:40:12 +12:00 committed by Simon Ser
parent 6dbf9f72b6
commit a281783339

View file

@ -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