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

[Jonas Ådahl]

On Wed, Dec 02, 2015 at 02:44:02PM +0000, Daniel Stone wrote:
> Hi,
> 
> On 2 December 2015 at 03:04, Bill Spitzak <spitzak at gmail.com> wrote:
> > 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.
> 
> 'Broken' is subjective; certainly had we specified from the beginning
> that it must not happen, they would be objectively broken.
> 'Undesirable behaviour' is pretty clear in this case, but when we're
> talking about compliance to a spec which was silent on the matter ...
> 
> > 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.
> 
> Yeah, exactly this. If it turns out that no serious client (so, not
> toytoolkit) relies on this, then brilliant. If we're banning
> compositors from implementing behaviour that real-world clients rely
> on, then not so great.

How do we determine the list of serious enough real-world clients?

Are proprietary clients shipped in various places using Wayland serious?
We can't check those very easily.


Jonas

> 
> Cheers,
> Daniel