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

[Jonas Ådahl]

On Fri, Nov 18, 2016 at 12:25:21PM +1000, Peter Hutterer wrote:
> On Thu, Nov 17, 2016 at 10:42:41AM +0800, Jonas Ådahl wrote:
> > 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.
> 
> coincidentally, that actually outlines the problem Daniel was talking about.
> The physical position of KEY_W is not guaranteed. It could be in a different
> postcode and no-one would notice as long as it sends the same key code.
> So by relying on KEY_W to be where you think it is, you're contributing to
> exactly that problem we had switching to evdev.
> 
> The only thing that could've provided actual physical positioning for the
> key was the geometry stuff but that was discarded in libxkbcommon, for
> a number of good reasons.

So lets assume we define wl_keyboard.key to be useless by itself, and
that its meaning only depends on the keymap_format enum value.

If the keymap_format is 'xkb_v1', the keycode can only be offset by 8
then passed to a libxkbcommon state set up with the keymap passed via
wl_keyboard.keymap. The client will AFAICS have no information about the
keymap; it'll just feed it key-up/down events. Would it be possible to
add API to libxkbcommon to provide enough information about the passed
keyboard layout so the client can create its own variant (such as
xkb_rule_names::model,rules, so that the client can create its own
layout but with the known layout). That would at least give something
resembling a key position.

If 'no_keymap' is the enum value used, which says the keycode should be
interpreted directly, how could that be possible if it's undefined?
Should we then instead define it to only be valid in a tightly
integrated system (where a certain software only ever runs on a specific
hardware/software setup)? This is awkward by itself btw, the server
seems to be required to send a useless fd just to have something to
pass. I guess that can be avoided by having 'no_keymap' as default,
assuming one never goes xkb_v1 -> no_keymap.


Jonas

> 
> Cheers,
>    Peter
> 
> > > 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