[PATCH wayland] protocol: spell out that we're using linux/input-event-codes.h key codes
Peter Hutterer
peter.hutterer at who-t.net
Wed Nov 16 23:51:18 UTC 2016
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 ... ?
>
> 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.
mind you, the issue there was that the doc said "undefined" and it wasn't
intepreted that way so when undefined changed to
undefined-but-something-else, happy times ensued.
The goal here would be to change "undefined" to "defined", so any conversion
would have to be done on the server side. But I fully agree with you
otherwise.
Cheers,
Peter
More information about the wayland-devel
mailing list