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

Submitted by Peter Hutterer on Nov. 20, 2016, 5:14 a.m.

Details

Message ID 20161120051452.GA27380@jelly
State New
Headers show
Series "tablet: specify the tool button numbers are simply sequentially numbered" ( rev: 2 ) in Wayland

Not browsing as part of any series.

Commit Message

Peter Hutterer Nov. 20, 2016, 5:14 a.m.
Rather than relying on input-event-codes, define our own enum that is tailored
towards the tablet interface.

Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
---
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(-)

Patch hide | download patch | download mbox

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 @@ 
       <arg name="clicks" type="int" summary="The wheel delta in discrete clicks"/>
     </event>
 
+    <enum name="button">
+      <description summary="physical button name">
+	Describes the physical button that produced the button event.
+      </description>
+      <entry name="unknown" value="0" summary="An unknown button"/>
+      <entry name="stylus1" value="1" summary="The primary button on a stylus-like tool"/>
+      <entry name="stylus2" value="2" summary="The secondary button on a stylus-like tool"/>
+      <entry name="stylus3" value="3" summary="The third button on a stylus-like tool"/>
+      <entry name="stylus4" value="4" summary="The forth button on a stylus-like tool"/>
+      <entry name="stylus5" value="5" summary="The fifth button on a stylus-like tool"/>
+      <entry name="stylus6" value="6" summary="The sixth button on a stylus-like tool"/>
+      <entry name="stylus7" value="7" summary="The seventh button on a stylus-like tool"/>
+      <entry name="stylus8" value="8" summary="The eighth button on a stylus-like tool"/>
+      <entry name="stylus9" value="9" summary="The ninth button on a stylus-like tool"/>
+      <entry name="left" value="10" summary="The left button on a mouse-like tool"/>
+      <entry name="right" value="11" summary="The right button on a mouse-like tool"/>
+      <entry name="middle" value="12" summary="The middle button on a mouse-like tool"/>
+      <entry name="thumb" value="13" summary="The thumb button on a mouse-like tool"/>
+    </enum>
+
     <enum name="button_state">
       <description summary="physical button state">
 	Describes the physical state of a button that produced the button event.
@@ -558,7 +578,7 @@ 
       </description>
 
       <arg name="serial" type="uint"/>
-      <arg name="button" type="uint" summary="The button whose state has changed"/>
+      <arg name="button" type="uint" enum="button" summary="The button whose state has changed"/>
       <arg name="state" type="uint" enum="button_state" summary="Whether the button was pressed or released"/>
     </event>
 

Comments

Hi,

On 20 November 2016 at 05:14, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> Rather than relying on input-event-codes, define our own enum that is tailored
> towards the tablet interface.
>
> Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
> ---
> 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 @@
>        <arg name="clicks" type="int" summary="The wheel delta in discrete clicks"/>
>      </event>
>
> +    <enum name="button">
> +      <description summary="physical button name">
> +       Describes the physical button that produced the button event.
> +      </description>
> +      <entry name="unknown" value="0" summary="An unknown button"/>
> +      <entry name="stylus1" value="1" summary="The primary button on a stylus-like tool"/>
> +      <entry name="stylus2" value="2" summary="The secondary button on a stylus-like tool"/>
> +      <entry name="stylus3" value="3" summary="The third button on a stylus-like tool"/>
> +      <entry name="stylus4" value="4" summary="The forth button on a stylus-like tool"/>
> +      <entry name="stylus5" value="5" summary="The fifth button on a stylus-like tool"/>
> +      <entry name="stylus6" value="6" summary="The sixth button on a stylus-like tool"/>
> +      <entry name="stylus7" value="7" summary="The seventh button on a stylus-like tool"/>
> +      <entry name="stylus8" value="8" summary="The eighth button on a stylus-like tool"/>
> +      <entry name="stylus9" value="9" summary="The ninth button on a stylus-like tool"/>
> +      <entry name="left" value="10" summary="The left button on a mouse-like tool"/>
> +      <entry name="right" value="11" summary="The right button on a mouse-like tool"/>
> +      <entry name="middle" value="12" summary="The middle button on a mouse-like tool"/>
> +      <entry name="thumb" value="13" summary="The thumb button on a mouse-like tool"/>
> +    </enum>

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 <daniels@collabora.com>

Cheers,
Daniel
On Mon, Nov 21, 2016 at 12:42:36PM +0000, Daniel Stone wrote:
> Hi,
> 
> On 20 November 2016 at 05:14, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> > Rather than relying on input-event-codes, define our own enum that is tailored
> > towards the tablet interface.
> >
> > Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
> > ---
> > 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 @@
> >        <arg name="clicks" type="int" summary="The wheel delta in discrete clicks"/>
> >      </event>
> >
> > +    <enum name="button">
> > +      <description summary="physical button name">
> > +       Describes the physical button that produced the button event.
> > +      </description>
> > +      <entry name="unknown" value="0" summary="An unknown button"/>
> > +      <entry name="stylus1" value="1" summary="The primary button on a stylus-like tool"/>
> > +      <entry name="stylus2" value="2" summary="The secondary button on a stylus-like tool"/>
> > +      <entry name="stylus3" value="3" summary="The third button on a stylus-like tool"/>
> > +      <entry name="stylus4" value="4" summary="The forth button on a stylus-like tool"/>
> > +      <entry name="stylus5" value="5" summary="The fifth button on a stylus-like tool"/>
> > +      <entry name="stylus6" value="6" summary="The sixth button on a stylus-like tool"/>
> > +      <entry name="stylus7" value="7" summary="The seventh button on a stylus-like tool"/>
> > +      <entry name="stylus8" value="8" summary="The eighth button on a stylus-like tool"/>
> > +      <entry name="stylus9" value="9" summary="The ninth button on a stylus-like tool"/>
> > +      <entry name="left" value="10" summary="The left button on a mouse-like tool"/>
> > +      <entry name="right" value="11" summary="The right button on a mouse-like tool"/>
> > +      <entry name="middle" value="12" summary="The middle button on a mouse-like tool"/>
> > +      <entry name="thumb" value="13" summary="The thumb button on a mouse-like tool"/>
> > +    </enum>
> 
> 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 <daniels@collabora.com>
> 
> Cheers,
> Daniel
Hey,

On 21 November 2016 at 23:13, Peter Hutterer <peter.hutterer@who-t.net> wrote:
> On Mon, Nov 21, 2016 at 12:42:36PM +0000, 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
On Tuesday, November 22, 2016, Daniel Stone <daniel@fooishbar.org> wrote:

> Hey,
>
> On 21 November 2016 at 23:13, Peter Hutterer <peter.hutterer@who-t.net
> <javascript:;>> wrote:
> > On Mon, Nov 21, 2016 at 12:42:36PM +0000, 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
>
On Tue, Nov 22, 2016 at 09:03:52AM -0800, Ping Cheng wrote:
> On Tuesday, November 22, 2016, Daniel Stone <daniel@fooishbar.org> wrote:
> 
> > Hey,
> >
> > On 21 November 2016 at 23:13, Peter Hutterer <peter.hutterer@who-t.net
> > <javascript:;>> wrote:
> > > On Mon, Nov 21, 2016 at 12:42:36PM +0000, 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
> >
On Tuesday, November 22, 2016, Peter Hutterer <peter.hutterer@who-t.net>
wrote:

> On Tue, Nov 22, 2016 at 09:03:52AM -0800, Ping Cheng wrote:
> > On Tuesday, November 22, 2016, Daniel Stone <daniel@fooishbar.org
> <javascript:;>> wrote:
> >
> > > Hey,
> > >
> > > On 21 November 2016 at 23:13, Peter Hutterer <peter.hutterer@who-t.net
> <javascript:;>
> > > <javascript:;>> wrote:
> > > > On Mon, Nov 21, 2016 at 12:42:36PM +0000, 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
> > >
>