[PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes

[Peter Hutterer]

On Thu, Nov 10, 2016 at 10:22:41AM +0000, Daniel Stone wrote:
> Hi,
> 
> On 10 November 2016 at 05:19, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > A side-note here: my first version sent to Jonas privately had a reserved
> > range for any key with the highest bit set. The idea here was to have a
> > range defined that we'll never touch during protocol updates so that vendors
> > who need some custom key code have a place to escape to.
> >
> > Note that by custom key code I don't mean "gaming mouse sends custom key X"
> > but rather "this is an integrated compositor + client stack solution and the
> > key only makes sense in this context".
> >
> > I took it out of this version now, maybe it makes sense to add this though.
> >
> > Also, I think the DTD needs a <whoops-shouldve-defined-this-earlier> tag :)
> >
> >  protocol/wayland.xml | 18 ++++++++++++++++++
> >  1 file changed, 18 insertions(+)
> >
> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > index 6c6d078..dcc29fe 100644
> > --- a/protocol/wayland.xml
> > +++ b/protocol/wayland.xml
> > @@ -1893,6 +1893,14 @@
> >         enter event.
> >          The time argument is a timestamp with millisecond
> >          granularity, with an undefined base.
> > +
> > +       The button is a button code as defined in the Linux kernel's
> > +       linux/input-event-codes.h header file, e.g. BTN_LEFT.
> > +
> > +       Any 16-bit button code value is reserved for future additions to the
> > +       kernel's event code list. All other button codes above 0xFFFF are
> > +       currently undefined but may be used in future versions of this
> > +       protocol.
> 
> This bit is fine, though I'm not sure why we want to give ourselves
> the room to invent new buttons.

the evdev protocol is great because it gives a semantic value for every
button/key. It's terrible because it gives a semantic value for every
button/key :)

In the past I've had to deal with devices that were just devices with
numbered buttons (more than 10) and there is no way in the evdev protocol to
express this. Same with axes, we have an ABS_MISC range but it's
surprisingly narrow and has a tendency to leak into the MT range which is
why a concept of a fake multi-touch device exists.

I don't have a concrete example thought through, but I can imagine a
wayland-specific range for simple sequential buttons, without forcing every
wayland client into knowing that after BTN_9 there comes BTN_A, B, C, X, Y,
Z and then possibly something else random.


> >        <arg name="serial" type="uint" summary="serial number of the button event"/>
> > @@ -2154,6 +2162,16 @@
> >         A key was pressed or released.
> >          The time argument is a timestamp with millisecond
> >          granularity, with an undefined base.
> > +
> > +       The key is a key code as defined in the Linux kernel's
> > +       linux/input-event-codes.h header file, e.g. KEY_A. The key
> > +       represents a physical key on the keyboard and is unaffected by the
> > +       keyboard layout applied.
> > +
> > +       Any 16-bit key code value is reserved for future additions to the
> > +       kernel's event code list. All other key codes above 0xFFFF are
> > +       currently undefined but may be used in future versions of this
> > +       protocol.
> >        </description>
> 
> But this I'd prefer to drop. We need to describe the button codes, but
> the key codes are _already_ perfectly described in the keymap. Leaving
> this undefined opens the door to making life much easier for, e.g.,
> RDP-based compositors.

ok, makes sense. I'll drop this bit and/or reword it, thanks.

Cheers,
   Peter