Re: [PATCH v2 wayland] protocol: specify behavior of get_pointer when capabilities change
On Mon, Dec 07, 2015 at 03:08:19PM +1000, Peter Hutterer wrote: > On Fri, Dec 04, 2015 at 09:01:09AM +0800, Jonas Ådahl wrote: > > On Fri, Dec 04, 2015 at 10:34:34AM +1000, Peter Hutterer wrote: > > > Also applies to touch/keyboard > > > > > > Signed-off-by: Peter Hutterer > > > --- > > > Changes to v1: > > > - make it clear that from the next version onwards sending events to an > > > earlier wl_pointer object is a no-no. > > > > > > protocol/wayland.xml | 36 +--- > > > 1 file changed, 33 insertions(+), 3 deletions(-) > > > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > > index 7ca5049..471c1fe 100644 > > > --- a/protocol/wayland.xml > > > +++ b/protocol/wayland.xml > > > @@ -1396,6 +1396,30 @@ > > > 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 was implemented in some compositors supporting > > > + version 5 or less of the wl_seat interface and is considered a > > > > 5 -> 4 > > oh, right. we haven't released v5 yet, sorry. > > > > + misinterpretation of the intended behavior. > > > > tricycleshed: This newline will be ignored when displayed as HTML, so I > > don't think it that good to rely on such formatting. > > > > > + This behavior must not be relied upon by the client. A compositor > > > + implementing version 6 or later of the wl_seat or wl_pointer > > > > 6 -> 5 > > > > > + interface must not send events to a wl_pointer object created > > > + before the most recent event notifying the client of an added > > > + pointer capability. > > > > > > This to me reads like we are now aiming to break those clients, as if > > they happen to connect to a newer compositor supporting version >= 5 > > of wl_seat will not continue supporting the old behaviour. Was that the > > conclusion drawn? > > don't you get to pick which version you support? so if a client v1 connects > to a compositor supporting v5 you still run v1 of the protocol on that > connection and the compositor needs to be backwards compatible. This is what > the wording was supposed to convey, anyway. Ah, I see. I suspected so, but it didn't sound like it. > > Maybe better to reword this as "If client and compositor use version 5 or > later ...". It needs to be clear that it's the objects created from the wl_seat bound to version 5 or later, and only those objects, that may implement the misbehaviour. Another suggestion that tries to document that: In some compositors, if a seat regains the pointer capability and a client has a previously obtained a wl_pointer object of version 4 or less, that object may start sending pointer events again. This behaviour is considered a misinterpretation and must not be relied upon by the client. wl_pointer objects of version 5 or must not send events if created before the most recent event notifying the client of an added pointer capability was sent. Jonas > > Cheers, >Peter > > > > If so is the case, the text sounds correct to me, but I think it could be > > made to sound more obvious that the behaviour is not supported any more. > > > > In some compositors only supporting version 4 or less of the > > wl_seat, if a seat regains the pointer capability and a client > > has a pointer object obtained previously, that object may start > > sending pointer events. This behaviour is considered a > > misinterpretation and must not be relied upon by the client. A > > compositor implementing version 5 or later of the wl_seat or > > wl_pointer interface must not send events to a wl_pointer object > > created before the most recent event notifying the client of an > > added pointer capability. > > > > That way its more up front that its old unsupported behaviour. > > > > > > Jonas > > > > > + > > > + The above behavior also applies to wl_keyboard and wl_touch with the > > > + keyboard and touch capabilities, respectively. > > > > > > > > > > > > @@ -1406,7 +1430,9 @@ > > > for this seat. > > > > > > This request only takes effect if the seat has the
Re: [PATCH v2 wayland] protocol: specify behavior of get_pointer when capabilities change
On Fri, Dec 04, 2015 at 09:01:09AM +0800, Jonas Ådahl wrote: > On Fri, Dec 04, 2015 at 10:34:34AM +1000, Peter Hutterer wrote: > > Also applies to touch/keyboard > > > > Signed-off-by: Peter Hutterer > > --- > > Changes to v1: > > - make it clear that from the next version onwards sending events to an > > earlier wl_pointer object is a no-no. > > > > protocol/wayland.xml | 36 +--- > > 1 file changed, 33 insertions(+), 3 deletions(-) > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > index 7ca5049..471c1fe 100644 > > --- a/protocol/wayland.xml > > +++ b/protocol/wayland.xml > > @@ -1396,6 +1396,30 @@ > > 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 was implemented in some compositors supporting > > + version 5 or less of the wl_seat interface and is considered a > > 5 -> 4 oh, right. we haven't released v5 yet, sorry. > > + misinterpretation of the intended behavior. > > tricycleshed: This newline will be ignored when displayed as HTML, so I > don't think it that good to rely on such formatting. > > > + This behavior must not be relied upon by the client. A compositor > > + implementing version 6 or later of the wl_seat or wl_pointer > > 6 -> 5 > > > + interface must not send events to a wl_pointer object created > > + before the most recent event notifying the client of an added > > + pointer capability. > > > This to me reads like we are now aiming to break those clients, as if > they happen to connect to a newer compositor supporting version >= 5 > of wl_seat will not continue supporting the old behaviour. Was that the > conclusion drawn? don't you get to pick which version you support? so if a client v1 connects to a compositor supporting v5 you still run v1 of the protocol on that connection and the compositor needs to be backwards compatible. This is what the wording was supposed to convey, anyway. Maybe better to reword this as "If client and compositor use version 5 or later ...". Cheers, Peter > If so is the case, the text sounds correct to me, but I think it could be > made to sound more obvious that the behaviour is not supported any more. > > In some compositors only supporting version 4 or less of the > wl_seat, if a seat regains the pointer capability and a client > has a pointer object obtained previously, that object may start > sending pointer events. This behaviour is considered a > misinterpretation and must not be relied upon by the client. A > compositor implementing version 5 or later of the wl_seat or > wl_pointer interface must not send events to a wl_pointer object > created before the most recent event notifying the client of an > added pointer capability. > > That way its more up front that its old unsupported behaviour. > > > Jonas > > > + > > + The above behavior also applies to wl_keyboard and wl_touch with the > > + keyboard and touch capabilities, respectively. > > > > > > > > @@ -1406,7 +1430,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. > > > > > > > > @@ -1417,7 +1443,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. > > > > > > > > @@ -1428,7 +1456,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.
Re: [PATCH v2 wayland] protocol: specify behavior of get_pointer when capabilities change
This seems more complex than is needed. My impression is that there are a non-zero set of version<5 compositors that implement the new behaviour. Therefore a client that relies on the incorrect behavior is broken even if it requests a version < 5, as it will fail with some compositors. I think you should completely remove any text about "it may act this way" as it is just confusing. I also think that any such text will encourage *some* compositor to work the old way, irregardless of what version number is claims. This will then lead to some clients relying on the old behaviour. If these clients are at all popular it will pretty much force all compositors to implement the old behavior, making all this text irrelevant. On Thu, Dec 3, 2015 at 5:01 PM, Jonas Ådahl wrote: > On Fri, Dec 04, 2015 at 10:34:34AM +1000, Peter Hutterer wrote: > > Also applies to touch/keyboard > > > > Signed-off-by: Peter Hutterer > > --- > > Changes to v1: > > - make it clear that from the next version onwards sending events to an > > earlier wl_pointer object is a no-no. > > > > protocol/wayland.xml | 36 +--- > > 1 file changed, 33 insertions(+), 3 deletions(-) > > > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > > index 7ca5049..471c1fe 100644 > > --- a/protocol/wayland.xml > > +++ b/protocol/wayland.xml > > @@ -1396,6 +1396,30 @@ > > 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 was implemented in some compositors > supporting > > + version 5 or less of the wl_seat interface and is considered a > > 5 -> 4 > > > + misinterpretation of the intended behavior. > > tricycleshed: This newline will be ignored when displayed as HTML, so I > don't think it that good to rely on such formatting. > > > + This behavior must not be relied upon by the client. A compositor > > + implementing version 6 or later of the wl_seat or wl_pointer > > 6 -> 5 > > > + interface must not send events to a wl_pointer object created > > + before the most recent event notifying the client of an added > > + pointer capability. > > > This to me reads like we are now aiming to break those clients, as if > they happen to connect to a newer compositor supporting version >= 5 > of wl_seat will not continue supporting the old behaviour. Was that the > conclusion drawn? > > If so is the case, the text sounds correct to me, but I think it could be > made to sound more obvious that the behaviour is not supported any more. > > In some compositors only supporting version 4 or less of the > wl_seat, if a seat regains the pointer capability and a client > has a pointer object obtained previously, that object may start > sending pointer events. This behaviour is considered a > misinterpretation and must not be relied upon by the client. A > compositor implementing version 5 or later of the wl_seat or > wl_pointer interface must not send events to a wl_pointer object > created before the most recent event notifying the client of an > added pointer capability. > > That way its more up front that its old unsupported behaviour. > > > Jonas > > > + > > + The above behavior also applies to wl_keyboard and wl_touch with > the > > + keyboard and touch capabilities, respectively. > > > > > > > > @@ -1406,7 +1430,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. > > > > > > > > @@ -1417,7 +1443,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. > > > > > >
Re: [PATCH v2 wayland] protocol: specify behavior of get_pointer when capabilities change
On Fri, Dec 04, 2015 at 10:34:34AM +1000, Peter Hutterer wrote: > Also applies to touch/keyboard > > Signed-off-by: Peter Hutterer > --- > Changes to v1: > - make it clear that from the next version onwards sending events to an > earlier wl_pointer object is a no-no. > > protocol/wayland.xml | 36 +--- > 1 file changed, 33 insertions(+), 3 deletions(-) > > diff --git a/protocol/wayland.xml b/protocol/wayland.xml > index 7ca5049..471c1fe 100644 > --- a/protocol/wayland.xml > +++ b/protocol/wayland.xml > @@ -1396,6 +1396,30 @@ > 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 was implemented in some compositors supporting > + version 5 or less of the wl_seat interface and is considered a 5 -> 4 > + misinterpretation of the intended behavior. tricycleshed: This newline will be ignored when displayed as HTML, so I don't think it that good to rely on such formatting. > + This behavior must not be relied upon by the client. A compositor > + implementing version 6 or later of the wl_seat or wl_pointer 6 -> 5 > + interface must not send events to a wl_pointer object created > + before the most recent event notifying the client of an added > + pointer capability. This to me reads like we are now aiming to break those clients, as if they happen to connect to a newer compositor supporting version >= 5 of wl_seat will not continue supporting the old behaviour. Was that the conclusion drawn? If so is the case, the text sounds correct to me, but I think it could be made to sound more obvious that the behaviour is not supported any more. In some compositors only supporting version 4 or less of the wl_seat, if a seat regains the pointer capability and a client has a pointer object obtained previously, that object may start sending pointer events. This behaviour is considered a misinterpretation and must not be relied upon by the client. A compositor implementing version 5 or later of the wl_seat or wl_pointer interface must not send events to a wl_pointer object created before the most recent event notifying the client of an added pointer capability. That way its more up front that its old unsupported behaviour. Jonas > + > + The above behavior also applies to wl_keyboard and wl_touch with the > + keyboard and touch capabilities, respectively. > > > > @@ -1406,7 +1430,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. > > > > @@ -1417,7 +1443,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. > > > > @@ -1428,7 +1456,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
[PATCH v2 wayland] protocol: specify behavior of get_pointer when capabilities change
Also applies to touch/keyboard Signed-off-by: Peter Hutterer --- Changes to v1: - make it clear that from the next version onwards sending events to an earlier wl_pointer object is a no-no. protocol/wayland.xml | 36 +--- 1 file changed, 33 insertions(+), 3 deletions(-) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index 7ca5049..471c1fe 100644 --- a/protocol/wayland.xml +++ b/protocol/wayland.xml @@ -1396,6 +1396,30 @@ 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 was implemented in some compositors supporting + version 5 or less of the wl_seat interface and is considered a + misinterpretation of the intended behavior. + This behavior must not be relied upon by the client. A compositor + implementing version 6 or later of the wl_seat or wl_pointer + interface must not send events to a wl_pointer object created + before the most recent event notifying the client of an added + pointer capability. + + The above behavior also applies to wl_keyboard and wl_touch with the + keyboard and touch capabilities, respectively. @@ -1406,7 +1430,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. @@ -1417,7 +1443,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. @@ -1428,7 +1456,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
