[PATCH weston 2/3] input: Add support for making libxkbcommon optional

[Daniel Stone]

Hi,

On 14 June 2013 17:42, Rob Bradford <robert.bradford at intel.com> wrote:
> In embedded environments, devices that appear as evdev "keyboards" often
> have no resemblence to PC-style keyboards.  It is not uncommon for such
> environments to have no concept of modifier keys and no need for XKB key
> mapping; in these cases libxkbcommon initialization becomes unnecessary
> startup overhead.  On some SOC platforms, xkb keymap compilation can
> account for as much as 1/3 - 1/2 of the total compositor startup time.

There's definitely some specific approaches we've discussed which
could lessen the pain for xkbcommon: firstly, if you're using the
standard xkeyboard-config dataset, it's a _huge_ dataset which takes
ages to compile.  Shipping a custom slimmed-down dataset (as we did
for, e.g. the N9) can drastically lessen the compilation pain.
Secondly, a binary format is definitely achievable and as of 0.3.0,
xkbcommon is internally in a state where doing so makes a lot of
sense.

Embedded environments have been in a 'wild west' mode for input for
ages where everyone does their own thing, and the divergence makes it
pretty painful to work with.  I accept that there are situations where
you genuinely don't need xkbcommon, but just worry that putting this
in will encourage people to take the easy way out.  As Xfbdev and
their ilk have shown, this isn't damage that can be easily unpicked:
once you've (even implicitly) encouraged people down this route,
they'll take it no matter what.

I accept that I'm perhaps speaking from a position of a little bias
here, but on the other hand, part of that bias is our clients who get
themselves into these terrible positions for no good reason and then
look for creeping improvements on what they have, where everyone ends
up building a half-arsed version of what was already there. *shrug*

Cheers,
Daniel