[PATCH] Cache xkbcomp output

[Daniel Stone]

Hi,

On 13 July 2012 16:55, Keith Packard <keithp at keithp.com> wrote:
> Dan Nicholson <dbn.lists at gmail.com> writes:
>
>> Not that I actually have the time to work on this, but I'd been
>> thinking about xkbcommon lately. Do you think it's possible to build a
>> compatibility layer around the current code?
>
> I don't know, but I'd be surprised if xkbcommon provided enough
> low-level information to support the existing XKB protocol. I hope
> Daniel can answer this question...

Here's what I sent earlier about this, but it appears to have been
lost in transit:

I realise it seems a bit counterintuitive, but yeah, I don't think we
can really support it.  The problem is that the server -- due to
wonderful things like xmodmap -- needs to be able to just obliterate
random parts of the keymap on the fly.  There's quite a bit of server
code to support this, which we've had to pull in to xkbcommon to have
it generate an even remotely coherent map (rather than just
half-complete) for clients.  Stuff like actually binding virtual
modifiers to real modifiers and thus having working types. :)  In
terms of what we need for the server, the API surface area is, well,
pretty much the entire source tree.  I don't think that's really
sustainable as a library.

My goal with xkbcommon's changed to be able to provide a useful and
easy keyboard handling library, with a clear, simple, and supportable
API.  One of the tradeoffs I had to make there was making the maps
immutable, which to be honest I'm completely fine with.  I'm also
hoping to use it to experiment with other, more comprehensible, file
formats, and I don't think that's doable if the entire library is wide
open to clients to mangle.

As a happy side effect of this, we can now see what clients are
actually _doing_ with the keymap and thus find out which bits we
really need to support.

I still think having (something like) xkbcommon in the library is a
really good idea, but I just don't see much benefit in sharing the
library, given the two wildly disparate usecases.  I'm hoping to fix
it up to at least import maps from an X connection, so we can have all
clients (be they X, Wayland, DirectFB, whatever) using xkbcommon, and
just the X server using its own special codebase for its own special
requirements.

I hope I haven't completely run your project into the ground!

>> What do you think? It seems silly not to be making use of xkbcommon in
>> X.
>
> That was the plan, but then the plan also included replacing XKB with
> XKB2, which was supposed to have vastly simplified XKB...

I realised that step one was working out what people were actually
using out of it.  Also, given that it was pretty much impossible to
use without copy and pasting (literally) thousands of lines of code
into your app, we needed something more self-contained where you could
say:
  - build me a keymap
  - I just pressed this key, what now?
and, err ... that's about it really.

Cheers,
Daniel