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

[Peter Hutterer]

On Fri, Nov 18, 2016 at 11:29:53AM +0800, Jonas Ådahl wrote:
> 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.

the xkb key names are that. e.g. 

    struct xkb_context  *ctx = xkb_context_new(0);
    struct xkb_rule_names names = { "evdev", "pc104", "us", "", "" };
    struct xkb_keymap *keymap = xkb_keymap_new_from_names(ctx, &names, 0);
    xkb_keycode_t min = xkb_keymap_min_keycode(keymap),
                  max = xkb_keymap_max_keycode(keymap);
    for (int i = min; i < max; i++)
        printf("key name for %d: %s\n", i, xkb_keymap_key_get_name(keymap, i));
    xkb_context_unref(ctx);

this prints out e.g. "AE01" which is "row E, key 01" and refers to F1, A is
AC01, etc.  These names are semi-standard in that xkb has been using them
for decades but they're technically freeform (e.g. LALT or I147 and new
xkb models may define anything)

xkb also gives you the syms for each key code per level, so you should be
able to reconstruct everything you need this way. One problem is that XKB
is largely uni-directional, i.e. keycode->keysym is defined but
keysym->keycode is not always unique. but afaict the tools are already there
to re-build the layout on the client side, albeit without exact position
information.

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

isn't no_keymap the default anyway, merely by the wl_keyboardf.keymap being
an event that may or may not be sent? It's not spelled out explicitly but
that's how we've been treating other interfaces. Technically, no_keymap
isn't even necessary if the event is skipped altogether.

As for "how could that be possible if it's undefined", I guess there's a
slight difference between the technical term "undefined" and the more blurry
term "not defined". Having no keymap means the latter and as the doc says
"client must understand how to interpret the raw keycode".

Cheers,
   Peter

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