On Tuesday, November 22, 2016, Peter Hutterer <<a href="mailto:peter.hutterer@who-t.net">peter.hutterer@who-t.net</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, Nov 22, 2016 at 09:03:52AM -0800, Ping Cheng wrote:<br>
> On Tuesday, November 22, 2016, Daniel Stone <<a href="javascript:;" onclick="_e(event, 'cvml', 'daniel@fooishbar.org')">daniel@fooishbar.org</a>> wrote:<br>
><br>
> > Hey,<br>
> ><br>
> > On 21 November 2016 at 23:13, Peter Hutterer <<a href="javascript:;" onclick="_e(event, 'cvml', 'peter.hutterer@who-t.net')">peter.hutterer@who-t.net</a><br>
> > <javascript:;>> wrote:<br>
> > > On Mon, Nov 21, 2016 at 12:42:36PM +0000, Daniel Stone wrote:<br>
> > >> Concretely though, reusing BTN_* codes where possible would make it<br>
> > >> easier for clients to transition between the two.<br>
> > ><br>
> > > I disagree here. The kernel only has BTN_STYLUS and BTN_STYLUS2, after<br>
> > that<br>
> > > we overlap with DOUBLETAP range and later buttons that are completely<br>
> > > different (e.g. BTN_GEAR_DOWN). I think this would only make it worse.<br>
> > > This protocol is still unstable, every client needs updates once we mark<br>
> > it<br>
> > > stable anyway, making the enums *values* mean something is<br>
> > counterproductive<br>
> > > IMO.<br>
> ><br>
> > Shrug, once in an enum they're totally arbitrary values (so which<br>
> > BTN_* they overlap doesn't make a difference), and it does make it a<br>
> > little harder to screw it up, as well as easier to stay compatible<br>
><br>
><br>
> I see pros and cons for both suggestions. I was into Peter's idea of<br>
> generic numbering since it is easier to implement and<br>
> offers some flexibility for client to decide how to translate those events.<br>
><br>
> However, I am kinda convinced by Daniel's point now. If the BTN_ has a<br>
> preferred default action/feature, kernel should report that information to<br>
> userland. Client should translate that default setting accordingly.<br>
<br>
I'm not sure I understand your point here. The only change would be that<br>
compositors need to have a switch statement to convert from BTN_STYLUS<br>
into the wayland enum. Beyond that, no conversation should be done.<br>
<br>
The benefit Daniel mentions would be that clients don't have to be switched<br>
over immediately because the ABI stays the same for BTN_STYLUS(2) and<br>
BTN_LEFT-RIGHT.</blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers,</div><div>Ping</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
   Peter<br>
<br>
><br>
> That's just my 2 cents. It's still your call, Peter ;-).<br>
><br>
> Cheers,<br>
> Ping<br>
><br>
> between multiple versions. But, your call.<br>
> ><br>
> > Cheers,<br>
> > Daniel<br>
> ><br>
</blockquote>