<div dir="ltr"><div><div><div>Again I don't understand why you think it is important to include all this confusing text.<br><br></div>If I am not mistaken, *some* compositors less than version 5 do *NOT* act in the old way.<br><br></div>Therefore no client can rely on this behaviour even if the compositor is less than verison 5. And people writing compositors I think should be encouraged to write the newest version api. So this text is irrelevant for everybody.<br><br></div><div>I really would just delete all this text. You want to require clients to monitor the capability events and destroy/create the wl_pointer in response, so just say that. Stop giving them ways to get around what you want.<br><br></div><div>I'm not sure if it is possible, but you might want to change creation of wl_pointer before the capability is received into an error. I would suspect a lot of clients create the wl_seat and then immediately create the wl_pointer (and wl_keyboard, etc) without waiting for anything. This is technically wrong, and probably a good indicator of a client that will also fail to destroy/recreate the wl_pointer correctly.<br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Dec 6, 2015 at 11:29 PM, Jonas Ådahl <span dir="ltr"><<a href="mailto:jadahl@gmail.com" target="_blank">jadahl@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Dec 07, 2015 at 03:43:35PM +1000, Peter Hutterer wrote:<br>
> Also applies to touch/keyboard<br>
><br>
> Signed-off-by: Peter Hutterer <<a href="mailto:peter.hutterer@who-t.net">peter.hutterer@who-t.net</a>><br>
<br>
</span>Looks good to me now, so consider this Reviewed-by: Jonas Ådahl<br>
<<a href="mailto:jadahl@gmail.com">jadahl@gmail.com</a>><br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
Jonas<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> ---<br>
> Changes to v1:<br>
> - reword the paragraph detailing the pre v5 behaviour<br>
><br>
>  protocol/wayland.xml | 33 ++++++++++++++++++++++++++++++---<br>
>  1 file changed, 30 insertions(+), 3 deletions(-)<br>
><br>
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml<br>
> index 7ca5049..df8ed19 100644<br>
> --- a/protocol/wayland.xml<br>
> +++ b/protocol/wayland.xml<br>
> @@ -1396,6 +1396,27 @@<br>
>       This is emitted whenever a seat gains or loses the pointer,<br>
>       keyboard or touch capabilities.  The argument is a capability<br>
>       enum containing the complete set of capabilities this seat has.<br>
> +<br>
> +     When the pointer capability is added, a client may create a<br>
> +     wl_pointer object using the wl_seat.get_pointer request. This object<br>
> +     will receive pointer events until the capability is removed in the<br>
> +     future.<br>
> +<br>
> +     When the pointer capability is removed, a client should destroy the<br>
> +     wl_pointer objects associated with the seat where the capability was<br>
> +     removed, using the wl_pointer.release request. No further pointer<br>
> +     events will be received on these objects.<br>
> +<br>
> +     In some compositors, if a seat regains the pointer capability and a<br>
> +     client has a previously obtained wl_pointer object of version 4 or<br>
> +     less, that object may start sending pointer events again. This<br>
> +     behavior is considered a misinterpretation of the intended behavior<br>
> +     and must not be relied upon by the client. wl_pointer objects of<br>
> +     version 5 or later must not send events if created before the most<br>
> +     recent event notifying the client of an added pointer capability.<br>
> +<br>
> +     The above behavior also applies to wl_keyboard and wl_touch with the<br>
> +     keyboard and touch capabilities, respectively.<br>
>        </description><br>
>        <arg name="capabilities" type="uint" enum="capability"/><br>
>      </event><br>
> @@ -1406,7 +1427,9 @@<br>
>       for this seat.<br>
><br>
>       This request only takes effect if the seat has the pointer<br>
> -     capability.<br>
> +     capability, or has had the pointer capability in the past.<br>
> +     It is a protocol violation to issue this request on a seat that has<br>
> +     never had the pointer capability.<br>
>        </description><br>
>        <arg name="id" type="new_id" interface="wl_pointer"/><br>
>      </request><br>
> @@ -1417,7 +1440,9 @@<br>
>       for this seat.<br>
><br>
>       This request only takes effect if the seat has the keyboard<br>
> -     capability.<br>
> +     capability, or has had the keyboard capability in the past.<br>
> +     It is a protocol violation to issue this request on a seat that has<br>
> +     never had the keyboard capability.<br>
>        </description><br>
>        <arg name="id" type="new_id" interface="wl_keyboard"/><br>
>      </request><br>
> @@ -1428,7 +1453,9 @@<br>
>       for this seat.<br>
><br>
>       This request only takes effect if the seat has the touch<br>
> -     capability.<br>
> +     capability, or has had the touch capability in the past.<br>
> +     It is a protocol violation to issue this request on a seat that has<br>
> +     never had the touch capability.<br>
>        </description><br>
>        <arg name="id" type="new_id" interface="wl_touch"/><br>
>      </request><br>
> --<br>
> 2.5.0<br>
><br>
</div></div></blockquote></div><br></div>