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

[Daniel Stone]

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.

>        <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.

Cheers,
Daniel