protocol: remove implicit attach semantics

To match the Weston commit e7144fd175d1d68b91aa0cec7ab63381b79385a9:
Author: Kristian Høgsberg <krh@bitplanet.net>
Date:   Mon Mar 4 12:11:41 2013 -0500

    compositor: Only send release event in response to wl_surface.attach

Remove the implicit attach semantics from wl_surface.commit and .attach.

Before, if you did this on a wl_surface: attach, commit, commit, you
would receive wl_buffer.release for both commits. After this change, you
will only receive wl_buffer.release for the first commit. To get a
second release, the same buffer must be attached again.

There is no need for the implicit attach on the second commit. If the
compositor needs the wl_buffer for repainting, it will not release it to
begin with. If the compositor does not need to keep the wl_buffer around
for repainting, it will not need it for a new commit either.

Signed-off-by: Pekka Paalanen <ppaalanen@gmail.com>

diff --git a/protocol/wayland.xml b/protocol/wayland.xml
index cc8fb06..c4d62da 100644 (file)
--- a/protocol/wayland.xml
+++ b/protocol/wayland.xml
@@ -755,10 +755,10 @@
 
        The initial surface contents are void; there is no content.
        wl_surface.attach assigns the given wl_buffer as the pending wl_buffer.
-       wl_surface.commit applies the pending wl_buffer as the new
+       wl_surface.commit makes the pending wl_buffer the new
        surface contents, and the size of the surface becomes the size of
-       the wl_buffer. The wl_buffer is also kept as pending, until
-       changed by wl_surface.attach or the wl_buffer is destroyed.
+       the wl_buffer. After commit, there is no pending buffer until the
+       next attach.
 
        Committing a pending wl_buffer allows the compositor to read the
        pixels in the wl_buffer. The compositor may access the pixels at any
@@ -770,8 +770,6 @@
        event, and is not used by the compositor.
 
        Destroying the wl_buffer after wl_buffer.release does not change the
-       surface contents, even if the wl_buffer is still pending for the
-       next commit. In such case, the next commit does not change the
        surface contents. However, if the client destroys the wl_buffer
        before receiving wl_buffer.release, the surface contents become
        undefined immediately.
@@ -788,11 +786,10 @@
     <request name="damage">
       <description summary="mark part of the surface damaged">
        This request is used to describe the regions where the pending
-       buffer (or if pending buffer is none, the current buffer as updated
-       in-place) on the next wl_surface.commit will be different from the
-       current buffer, and needs to be repainted. The pending buffer can be
-       set by wl_surface.attach. The compositor ignores the parts of the
-       damage that fall outside of the surface.
+       buffer is different from the current surface contents, and where
+       the surface therefore needs to be repainted. The pending buffer must
+       be set by wl_surface.attach before sending damage. The compositor
+       ignores the parts of the damage that fall outside of the surface.
 
        Damage is double-buffered state, see wl_surface.commit.
 
@@ -894,7 +891,7 @@
        On commit, a pending wl_buffer is applied first, all other state
        second. This means that all coordinates in double-buffered state are
        relative to the new wl_buffer coming into use, except for
-       wl_surface.attach itself. If the pending wl_buffer is none, the
+       wl_surface.attach itself. If there is no pending wl_buffer, the
        coordinates are relative to the current surface contents.
 
        All requests that need a commit to become effective are documented