On Thu, Nov 10, 2016 at 10:22:41AM +0000, Daniel Stone wrote: > Hi, > > On 10 November 2016 at 05:19, Peter Hutterer <peter.hutte...@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.
Maybe it'd make it easier for RDP based compositors, but it'd make it harder for clients who don't care about keymaps and just wants keycodes (think WASD using games). Such clients doesn't care if it's actually <AOE, or if QWERTY or QWERTZ, and by not defining this in any way would make such clients rely on undefined behaviour. Jonas > > Cheers, > Daniel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
