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

[Bill Spitzak]

On Mon, Nov 30, 2015 at 3:32 PM, Peter Hutterer 
wrote:

> On Mon, Nov 30, 2015 at 09:46:36PM +, 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.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Jonas Ådahl]

On Wed, Dec 02, 2015 at 02:44:02PM +, Daniel Stone wrote:
> Hi,
> 
> On 2 December 2015 at 03:04, Bill Spitzak  wrote:
> > On Mon, Nov 30, 2015 at 3:32 PM, Peter Hutterer 
> > wrote:
> >> On Mon, Nov 30, 2015 at 09:46:36PM +, 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
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Daniel Stone]

Hi,

On 30 November 2015 at 03:25, Peter Hutterer  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.

The rest looks good though.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Peter Hutterer]

On Mon, Nov 30, 2015 at 09:46:36PM +, Daniel Stone wrote:
> Hi,
> 
> On 30 November 2015 at 03:25, Peter Hutterer  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

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

[Peter Hutterer]

Also applies to touch/keyboard

Signed-off-by: Peter Hutterer 
---
 protocol/wayland.xml | 30 +++---
 1 file changed, 27 insertions(+), 3 deletions(-)

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.
+
+   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.
+
+   The above behavior also applies to wl_keyboard and wl_touch with the
+   keyboard and touch capabilities, respectively.
   
   
 
@@ -1360,7 +1378,9 @@
for this seat.
 
This request only takes effect if the seat has the pointer
-   capability.
+   capability, or has had the pointer capability in the past.
+   It is a protocol violation to issue this request on a seat that has
+   never had the pointer capability.
   
   
 
@@ -1371,7 +1391,9 @@
for this seat.
 
This request only takes effect if the seat has the keyboard
-   capability.
+   capability, or has had the keyboard capability in the past.
+   It is a protocol violation to issue this request on a seat that has
+   never had the keyboard capability.
   
   
 
@@ -1382,7 +1404,9 @@
for this seat.
 
This request only takes effect if the seat has the touch
-   capability.
+   capability, or has had the touch capability in the past.
+   It is a protocol violation to issue this request on a seat that has
+   never had the touch capability.
   
   
 
-- 
2.5.0

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel