mirror of
https://gitlab.freedesktop.org/wayland/wayland.git
synced 2025-10-29 05:40:16 -04:00
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:
parent
6dbf9f72b6
commit
a281783339
1 changed files with 6 additions and 0 deletions
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue