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

[Jonas Ådahl]

On Wed, Nov 16, 2016 at 04:00:23PM +0000, Daniel Stone wrote:
> Hi,
> 
> On 15 November 2016 at 09:42, Jonas Ådahl <jadahl at gmail.com> wrote:
> > On Thu, Nov 10, 2016 at 10:22:41AM +0000, Daniel Stone wrote:
> >> 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.
> 
> Those clients can trivially introspect the keymap, then ... ?

Instrospect how? I don't see how I can get anything resembling a
physical position on a keyboard from a xkb_keycode_t and a struct
xkb_keymap.

> 
> We can't always guarantee that we even _have_ a map to KEY_*, and I
> really don't want to encourage the line of thinking that keycodes are
> somehow special and usable in and of themselves. GNOME did that a long
> time ago with AT keycodes, and it took literal years to unpick when we
> tried to move to evdev. Keymaps exist for a reason, and I don't want
> to encourage people to route around them.

At least don't leave it undefined then, but define it to "useless
anywhere other than xkbcommon" or something. Having it completely
undocumented as it is now doesn't seem like a good thing.


Jonas

> 
> Cheers,
> Daniel