Hi, On 10 November 2016 at 05:19, Peter Hutterer <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
