<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Tue, Feb 14, 2017 at 11:17 PM Jonas Ådahl <<a href="mailto:jadahl@gmail.com">jadahl@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Feb 14, 2017 at 10:20:06AM -0600, Derek Foreman wrote:<br class="gmail_msg">
> Attaching a NULL wl_buffer to a surface is not always valid, but<br class="gmail_msg">
> the previous text indicated it was.<br class="gmail_msg">
><br class="gmail_msg">
> Instead, let's define what NULL attachment does for all the surface<br class="gmail_msg">
> roles defined in wayland.xml, stop giving a blanket definition of<br class="gmail_msg">
> its behavior in wl_surface.attach, and warn developers that they<br class="gmail_msg">
> should refer to other protocol documentation for a full understanding<br class="gmail_msg">
> of wl_surface.attach.<br class="gmail_msg">
<br class="gmail_msg">
Good to see these things cleared up. Have some comments on the wording<br class="gmail_msg">
below, and the "cursor" role behaviour seems still undefined when<br class="gmail_msg">
attaching a NULL buffer.<br class="gmail_msg">
<br class="gmail_msg">
><br class="gmail_msg">
> Signed-off-by: Derek Foreman <<a href="mailto:derekf@osg.samsung.com" class="gmail_msg" target="_blank">derekf@osg.samsung.com</a>><br class="gmail_msg">
> ---<br class="gmail_msg">
><br class="gmail_msg">
> Changes from v1:<br class="gmail_msg">
> pretty much everything - define NULL attach for wl_shell specifically<br class="gmail_msg">
> and remove the generic statement from wl_surface.attach<br class="gmail_msg">
> refer readers to "other documentation"<br class="gmail_msg">
><br class="gmail_msg">
> protocol/wayland.xml | 10 +++++++---<br class="gmail_msg">
> 1 file changed, 7 insertions(+), 3 deletions(-)<br class="gmail_msg">
><br class="gmail_msg">
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml<br class="gmail_msg">
> index 29b63be..1a76e60 100644<br class="gmail_msg">
> --- a/protocol/wayland.xml<br class="gmail_msg">
> +++ b/protocol/wayland.xml<br class="gmail_msg">
> @@ -1002,6 +1002,10 @@<br class="gmail_msg">
> the related wl_surface is destroyed. On the client side,<br class="gmail_msg">
> wl_shell_surface_destroy() must be called before destroying<br class="gmail_msg">
> the wl_surface object.<br class="gmail_msg">
> +<br class="gmail_msg">
> + Attaching a NULL wl_buffer to a surface assigned a role by<br class="gmail_msg">
> + wl_shell will remove the content from the surface after the<br class="gmail_msg">
> + next commit.<br class="gmail_msg">
<br class="gmail_msg">
How is "removes the content" compared to unmaps? Does this mean a shell<br class="gmail_msg">
implementation need to keep track of the position when the shell surface<br class="gmail_msg">
is later remapped? That would be a new requirement that was previously<br class="gmail_msg">
undefined behaviour, and is not what mutter does at the moment.<br class="gmail_msg"></blockquote><div><br></div><div>Enlightenment does this.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br class="gmail_msg">
> </description><br class="gmail_msg">
><br class="gmail_msg">
> <request name="pong"><br class="gmail_msg">
> @@ -1324,6 +1328,9 @@<br class="gmail_msg">
> <description summary="set the surface contents"><br class="gmail_msg">
> Set a buffer as the content of this surface.<br class="gmail_msg">
><br class="gmail_msg">
> + The role of the surface influences the behaviour of attach,<br class="gmail_msg">
> + so this documentation is incomplete without further reading.<br class="gmail_msg">
> +<br class="gmail_msg">
<br class="gmail_msg">
Possible alternative wording, possibly in the end of the <description/>,<br class="gmail_msg">
as it talks about things that is specified below:<br class="gmail_msg">
<br class="gmail_msg">
The effect committing an attached buffer to a surface depends on<br class="gmail_msg">
what role the surface has been or is going to be assigned to.<br class="gmail_msg">
See the corresponding role specification for further details.<br class="gmail_msg">
<br class="gmail_msg">
This makes read more as the behaviour of *attach* does not change, but<br class="gmail_msg">
the effect of having attached and committed a buffer.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Jonas<br class="gmail_msg">
<br class="gmail_msg">
> The new size of the surface is calculated based on the buffer<br class="gmail_msg">
> size transformed by the inverse buffer_transform and the<br class="gmail_msg">
> inverse buffer_scale. This means that the supplied buffer<br class="gmail_msg">
> @@ -1358,9 +1365,6 @@<br class="gmail_msg">
> the surface contents. However, if the client destroys the<br class="gmail_msg">
> wl_buffer before receiving the wl_buffer.release event, the surface<br class="gmail_msg">
> contents become undefined immediately.<br class="gmail_msg">
> -<br class="gmail_msg">
> - If wl_surface.attach is sent with a NULL wl_buffer, the<br class="gmail_msg">
> - following wl_surface.commit will remove the surface content.<br class="gmail_msg">
> </description><br class="gmail_msg">
> <arg name="buffer" type="object" interface="wl_buffer" allow-null="true"<br class="gmail_msg">
> summary="buffer of surface contents"/><br class="gmail_msg">
> --<br class="gmail_msg">
> 2.11.0<br class="gmail_msg">
><br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
wayland-devel mailing list<br class="gmail_msg">
<a href="mailto:wayland-devel@lists.freedesktop.org" class="gmail_msg" target="_blank">wayland-devel@lists.freedesktop.org</a><br class="gmail_msg">
<a href="https://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br class="gmail_msg">
</blockquote></div></div>