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

[Jonas Ådahl]

On Wed, Mar 04, 2015 at 09:33:45AM +0200, Pekka Paalanen wrote:
> 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>

Pushed as

99d2775..8b2fbf8  master -> master

with a change clarifying what you mentioned above, as per IRC
discussion, as well as the issues raised addresed.

Jonas

> 
> 
> Thanks,
> pq