On Mon, Nov 30, 2015 at 09:46:36PM +0000, Daniel Stone wrote: > Hi, > > On 30 November 2015 at 03:25, Peter Hutterer <peter.hutte...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel