Re: [RFC v2 wayland-protocols] tablet: define our own enum for tablet tool buttons

[Ping Cheng]

On Tuesday, November 22, 2016, Peter Hutterer 
wrote:

> On Tue, Nov 22, 2016 at 09:03:52AM -0800, Ping Cheng wrote:
> > On Tuesday, November 22, 2016, Daniel Stone  > wrote:
> >
> > > Hey,
> > >
> > > On 21 November 2016 at 23:13, Peter Hutterer  
> > > > wrote:
> > > > On Mon, Nov 21, 2016 at 12:42:36PM +, Daniel Stone wrote:
> > > >> Concretely though, reusing BTN_* codes where possible would make it
> > > >> easier for clients to transition between the two.
> > > >
> > > > I disagree here. The kernel only has BTN_STYLUS and BTN_STYLUS2,
> after
> > > that
> > > > we overlap with DOUBLETAP range and later buttons that are completely
> > > > different (e.g. BTN_GEAR_DOWN). I think this would only make it
> worse.
> > > > This protocol is still unstable, every client needs updates once we
> mark
> > > it
> > > > stable anyway, making the enums *values* mean something is
> > > counterproductive
> > > > IMO.
> > >
> > > Shrug, once in an enum they're totally arbitrary values (so which
> > > BTN_* they overlap doesn't make a difference), and it does make it a
> > > little harder to screw it up, as well as easier to stay compatible
> >
> >
> > I see pros and cons for both suggestions. I was into Peter's idea of
> > generic numbering since it is easier to implement and
> > offers some flexibility for client to decide how to translate those
> events.
> >
> > However, I am kinda convinced by Daniel's point now. If the BTN_ has a
> > preferred default action/feature, kernel should report that information
> to
> > userland. Client should translate that default setting accordingly.
>
> I'm not sure I understand your point here. The only change would be that
> compositors need to have a switch statement to convert from BTN_STYLUS
> into the wayland enum. Beyond that, no conversation should be done.
>
> The benefit Daniel mentions would be that clients don't have to be switched
> over immediately because the ABI stays the same for BTN_STYLUS(2) and
> BTN_LEFT-RIGHT.


I guess I meant to make BTN_STYLUS and BTN_STYLUS2 as well as
BTN_LEFT/MIDDLE/RIGHT... into the new protocol since they were in
input-event-codes.h already. And anything (tbh I don't know if there is
anything relied on them) used those event types would not have to change.

I'm thinking in terms of the kernel. I am also assuming there are existing
stuff relied on those input-event-codes. Plus, Daniel's comments trigger my
reply ;). But, I am not familiar with Wayland. Sorry for my ignorance.

Cheers,
Ping



>
> Cheers,
>Peter
>
> >
> > That's just my 2 cents. It's still your call, Peter ;-).
> >
> > Cheers,
> > Ping
> >
> > between multiple versions. But, your call.
> > >
> > > Cheers,
> > > Daniel
> > >
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC v2 wayland-protocols] tablet: define our own enum for tablet tool buttons

[Peter Hutterer]

On Tue, Nov 22, 2016 at 09:03:52AM -0800, Ping Cheng wrote:
> On Tuesday, November 22, 2016, Daniel Stone  wrote:
> 
> > Hey,
> >
> > On 21 November 2016 at 23:13, Peter Hutterer  > > wrote:
> > > On Mon, Nov 21, 2016 at 12:42:36PM +, Daniel Stone wrote:
> > >> Concretely though, reusing BTN_* codes where possible would make it
> > >> easier for clients to transition between the two.
> > >
> > > I disagree here. The kernel only has BTN_STYLUS and BTN_STYLUS2, after
> > that
> > > we overlap with DOUBLETAP range and later buttons that are completely
> > > different (e.g. BTN_GEAR_DOWN). I think this would only make it worse.
> > > This protocol is still unstable, every client needs updates once we mark
> > it
> > > stable anyway, making the enums *values* mean something is
> > counterproductive
> > > IMO.
> >
> > Shrug, once in an enum they're totally arbitrary values (so which
> > BTN_* they overlap doesn't make a difference), and it does make it a
> > little harder to screw it up, as well as easier to stay compatible
> 
> 
> I see pros and cons for both suggestions. I was into Peter's idea of
> generic numbering since it is easier to implement and
> offers some flexibility for client to decide how to translate those events.
> 
> However, I am kinda convinced by Daniel's point now. If the BTN_ has a
> preferred default action/feature, kernel should report that information to
> userland. Client should translate that default setting accordingly.

I'm not sure I understand your point here. The only change would be that
compositors need to have a switch statement to convert from BTN_STYLUS
into the wayland enum. Beyond that, no conversation should be done.

The benefit Daniel mentions would be that clients don't have to be switched
over immediately because the ABI stays the same for BTN_STYLUS(2) and
BTN_LEFT-RIGHT.

Cheers,
   Peter

> 
> That's just my 2 cents. It's still your call, Peter ;-).
> 
> Cheers,
> Ping
> 
> between multiple versions. But, your call.
> >
> > Cheers,
> > Daniel
> >
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC v2 wayland-protocols] tablet: define our own enum for tablet tool buttons

[Ping Cheng]

On Tuesday, November 22, 2016, Daniel Stone  wrote:

> Hey,
>
> On 21 November 2016 at 23:13, Peter Hutterer  > wrote:
> > On Mon, Nov 21, 2016 at 12:42:36PM +, Daniel Stone wrote:
> >> Concretely though, reusing BTN_* codes where possible would make it
> >> easier for clients to transition between the two.
> >
> > I disagree here. The kernel only has BTN_STYLUS and BTN_STYLUS2, after
> that
> > we overlap with DOUBLETAP range and later buttons that are completely
> > different (e.g. BTN_GEAR_DOWN). I think this would only make it worse.
> > This protocol is still unstable, every client needs updates once we mark
> it
> > stable anyway, making the enums *values* mean something is
> counterproductive
> > IMO.
>
> Shrug, once in an enum they're totally arbitrary values (so which
> BTN_* they overlap doesn't make a difference), and it does make it a
> little harder to screw it up, as well as easier to stay compatible


I see pros and cons for both suggestions. I was into Peter's idea of
generic numbering since it is easier to implement and
offers some flexibility for client to decide how to translate those events.

However, I am kinda convinced by Daniel's point now. If the BTN_ has a
preferred default action/feature, kernel should report that information to
userland. Client should translate that default setting accordingly.

That's just my 2 cents. It's still your call, Peter ;-).

Cheers,
Ping

between multiple versions. But, your call.
>
> Cheers,
> Daniel
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC v2 wayland-protocols] tablet: define our own enum for tablet tool buttons

[Daniel Stone]

Hey,

On 21 November 2016 at 23:13, Peter Hutterer  wrote:
> On Mon, Nov 21, 2016 at 12:42:36PM +, Daniel Stone wrote:
>> Concretely though, reusing BTN_* codes where possible would make it
>> easier for clients to transition between the two.
>
> I disagree here. The kernel only has BTN_STYLUS and BTN_STYLUS2, after that
> we overlap with DOUBLETAP range and later buttons that are completely
> different (e.g. BTN_GEAR_DOWN). I think this would only make it worse.
> This protocol is still unstable, every client needs updates once we mark it
> stable anyway, making the enums *values* mean something is counterproductive
> IMO.

Shrug, once in an enum they're totally arbitrary values (so which
BTN_* they overlap doesn't make a difference), and it does make it a
little harder to screw it up, as well as easier to stay compatible
between multiple versions. But, your call.

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

Re: [RFC v2 wayland-protocols] tablet: define our own enum for tablet tool buttons

[Peter Hutterer]

On Mon, Nov 21, 2016 at 12:42:36PM +, Daniel Stone wrote:
> Hi,
> 
> On 20 November 2016 at 05:14, Peter Hutterer  wrote:
> > Rather than relying on input-event-codes, define our own enum that is 
> > tailored
> > towards the tablet interface.
> >
> > Signed-off-by: Peter Hutterer 
> > ---
> > Because it's usually easier to pick holes into a patch proposal than come up
> > with ideas elsewhere, here's a quick-and-dirty patch.
> >
> > Advantage: we control the button names/numbers and clients don't have to
> > know about cases where linux/input.h isn't enough.
> > Obvious drawback: adding new buttons requires a new protocol. Given this
> > hardware hasn't really changed much in quite a while, this may not be much
> > of an issue.
> 
> Conceptually, I don't see why not.
> 
> > @@ -539,6 +539,26 @@
> >
> >  
> >
> > +
> > +  
> > +   Describes the physical button that produced the button event.
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +  
> > +
> 
> Concretely though, reusing BTN_* codes where possible would make it
> easier for clients to transition between the two. 

I disagree here. The kernel only has BTN_STYLUS and BTN_STYLUS2, after that
we overlap with DOUBLETAP range and later buttons that are completely
different (e.g. BTN_GEAR_DOWN). I think this would only make it worse.
This protocol is still unstable, every client needs updates once we mark it
stable anyway, making the enums *values* mean something is counterproductive
IMO.

> Also, 9 stylus buttons seems like an oddly specific number.

was supposed to be 10 [0-9], I just have an index offset error here, sorry :)

Cheers,
   Peter

> Anyway, if you switch these values to the current BTN_* equivalents:
> Acked-by: Daniel Stone 
> 
> Cheers,
> Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [RFC v2 wayland-protocols] tablet: define our own enum for tablet tool buttons

[Daniel Stone]

Hi,

On 20 November 2016 at 05:14, Peter Hutterer  wrote:
> Rather than relying on input-event-codes, define our own enum that is tailored
> towards the tablet interface.
>
> Signed-off-by: Peter Hutterer 
> ---
> Because it's usually easier to pick holes into a patch proposal than come up
> with ideas elsewhere, here's a quick-and-dirty patch.
>
> Advantage: we control the button names/numbers and clients don't have to
> know about cases where linux/input.h isn't enough.
> Obvious drawback: adding new buttons requires a new protocol. Given this
> hardware hasn't really changed much in quite a while, this may not be much
> of an issue.

Conceptually, I don't see why not.

> @@ -539,6 +539,26 @@
>
>  
>
> +
> +  
> +   Describes the physical button that produced the button event.
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +  
> +

Concretely though, reusing BTN_* codes where possible would make it
easier for clients to transition between the two. Also, 9 stylus
buttons seems like an oddly specific number.

Anyway, if you switch these values to the current BTN_* equivalents:
Acked-by: Daniel Stone 

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

[RFC v2 wayland-protocols] tablet: define our own enum for tablet tool buttons

[Peter Hutterer]

Rather than relying on input-event-codes, define our own enum that is tailored
towards the tablet interface.

Signed-off-by: Peter Hutterer 
---
Because it's usually easier to pick holes into a patch proposal than come up
with ideas elsewhere, here's a quick-and-dirty patch.

Advantage: we control the button names/numbers and clients don't have to
know about cases where linux/input.h isn't enough.
Obvious drawback: adding new buttons requires a new protocol. Given this
hardware hasn't really changed much in quite a while, this may not be much
of an issue.

 unstable/tablet/tablet-unstable-v2.xml | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/unstable/tablet/tablet-unstable-v2.xml 
b/unstable/tablet/tablet-unstable-v2.xml
index 728a3df..88aed83 100644
--- a/unstable/tablet/tablet-unstable-v2.xml
+++ b/unstable/tablet/tablet-unstable-v2.xml
@@ -539,6 +539,26 @@
   
 
 
+
+  
+   Describes the physical button that produced the button event.
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+  
+
+
 
   
Describes the physical state of a button that produced the button event.
@@ -558,7 +578,7 @@
   
 
   
-  
+  
   
 
 
-- 
2.9.3

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