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

[Daniel Stone]

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.

Cheers,
Daniel