Hi, On 14 June 2013 17:42, Rob Bradford <[email protected]> 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
