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

[Ping Cheng]

On Tuesday, November 22, 2016, Peter Hutterer <peter.hutterer at 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 at fooishbar.org
> <javascript:;>> wrote:
> >
> > > Hey,
> > >
> > > On 21 November 2016 at 23:13, Peter Hutterer <peter.hutterer at 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
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20161122/d2cb0f4a/attachment-0001.html>