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

[Peter Hutterer]

On Mon, Nov 30, 2015 at 09:46:36PM +0000, Daniel Stone wrote:
> Hi,
> 
> On 30 November 2015 at 03:25, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > index f9e6d76..370fafc 100644
> > --- a/protocol/wayland.xml
> > +++ b/protocol/wayland.xml
> > @@ -1350,6 +1350,24 @@
> >         This is emitted whenever a seat gains or loses the pointer,
> >         keyboard or touch capabilities.  The argument is a capability
> >         enum containing the complete set of capabilities this seat has.
> > +
> > +       When the pointer capability is added, a client may create a
> > +       wl_pointer object using the wl_seat.get_pointer request. This object
> > +       will receive pointer events until the capability is removed in the
> > +       future.
> > +
> > +       When the pointer capability is removed, a client should destroy the
> > +       wl_pointer objects associated with the seat where the capability was
> > +       removed, using the wl_pointer.release request. No further pointer
> > +       events will be received on these objects.
> 
> These are good! (Except the last sentence - see below.)
> 
> > +       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.

so the main question is then: are we ok with per-version behaviour?

Cheers,
   Peter