[PATCH wayland] protocol: specify behavior of get_pointer when capabilities change

[Bill Spitzak]

On Mon, Nov 30, 2015 at 3:32 PM, Peter Hutterer <peter.hutterer at who-t.net>
wrote:

> On Mon, Nov 30, 2015 at 09:46:36PM +0000, Daniel Stone wrote:
>
> > > +       If a seat regains the pointer capability and a client has a
> pointer
> > > +       object obtained previously, that object may start sending
> pointer
> > > +       events. This behavior is implementation-dependent and must not
> be
> > > +       relied upon.
> >
> > Urgh, I don't really like having this there as a bit of a get-out
> > clause. Can we just strengthen the 'client should destroy the
> > wl_pointer objects' to a 'must'? Especially since this paragraph
> > contradicts the immediately previous one ('No further pointer events
> > will be received on these objects'). Maybe we could fold bits of this
> > paragraph in to replace that problematic sentence, but couple with a
> > recommendation that compositors should not send events to stale
> > objects - and bump that to a must for compositors advertising whatever
> > our next version of wl_seat ends up being.
>
> if the per-version behaviour works correctly we can add this, otherwise we
> still have to keep this paragraph in, otherwise we're retroactively
> disallowing current working implementations. The same goes for the
> should/must, we already have implementations doing this.
>

I don't think you want this text. An existing implementation that sends
pointer events after the loss/gain is broken. People wrote lots of other
bugs into existing implementations, that does not mean all descriptions
have to allow any existing bug.

A more practical reason for being more insistent is that if a popular
compositor does this, it is quite likely to be relied on by some clients
(due to the fact that it is much easier to write a client that relies on
this), quickly leading to this being a required behaviour of all
compositors. Explicitly saying that is wrong may encourage the compositors
to not do this, though of course it does not guarantee it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151201/b6eafd80/attachment.html>