[PATCH wayland] protocol: Change wording of subsurface placement scheduling

[Pekka Paalanen]

On Tue,  3 Mar 2015 15:55:37 +0800
Jonas Ådahl <jadahl at gmail.com> wrote:

> Change wording to be more consistent with other parts of the subsurface
> protocol. Before this change, wl_subsurface.set_position explicitly
> stated that the new state was to be applied on the parents
> wl_surface.commit and wl_subsurface.place_above/below only said "on
> the next commit of the parent surface". What "committed" means is
> ambiguous considering that a wl_surface.commit actually defers the
> actual commit when in synchronized mode, but the intention has always
> been that placement of a subsurface should be considered part of its
> content, i.e. placement state should be applied when other state
> (buffer, regions). This patch makes that more clear.
> 
> Note that prior to this patch, one could correctly have interpreted
> the protocol meaning that placements operations takes effect explicitly
> on wl_surface.commit of the parent surface no matter whether other state
> of the parent surface is applied at that point. This patch clarifies that
> that is not the case.
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=88857
> 
> Signed-off-by: Jonas Ådahl <jadahl at gmail.com>
> ---
>  protocol/wayland.xml | 14 +++++++++-----
>  1 file changed, 9 insertions(+), 5 deletions(-)
> 

A collection of comments from irc follows.

> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 4fb8035..38e463a 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -2061,8 +2061,10 @@
>  	coordinate system. The coordinates are not restricted to the parent
>  	surface area. Negative values are allowed.
>  
> -	The next wl_surface.commit on the parent surface will reset
> -	the sub-surface's position to the scheduled coordinates.
> +	The scheduled coordinates will take effect whenever the state of the
> +	parent surface is applied. When this happens depends on whether the
> +	parent surface is in synchronized or not. See wl_subsurface.set_sync

missing word?

> +	and wl_subsurface.set_desync for details.
>  
>  	If more than one set_position request is invoked by the client before
>  	the commit of the parent surface, the position of a new request always
> @@ -2084,9 +2086,11 @@
>  	will cause a protocol error.
>  
>  	The z-order is double-buffered. Requests are handled in order and
> -	applied immediately to a pending state, then committed to the active
> -	state on the next commit of the parent surface.
> -	See wl_surface.commit and wl_subcompositor.get_subsurface.
> +	applied immediately to a pending state, then applied to the active
> +	state the next time the state of the parent surface is applied. When
> +	this happens depends on whether the parent surface is in synchronized
> +	or not. See wl_subsurface.set_sync and wl_subsurfac.set_desync for

typo "subsurfac"

> +	details.
>  
>  	A new sub-surface is initially added as the top-most in the stack
>  	of its siblings and parent.

In IRC, Jasper gave:
Acked-by: Jasper St. Pierre <jstpierre at mecheye.net>


I would like to confirm one more thing here about chaging the
z-order.

The requests are of the form "put this above/below that". We do those
modifications to the pending state. The thing I want to be clear on is
that when the pending state is applied, these operations are not
replayed but the pending order is simply set as the current order. Is
there any risk of getting that wrong?

If not:
Reviewed-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>


Thanks,
pq