xkbcommon in the server (was: Re: [PATCH] Cache xkbcomp output)

[Daniel Stone]

Hi,

On 13 July 2012 13:34, Dan Nicholson <dbn.lists at gmail.com> wrote:
> 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? Either the compat code
> could live in the server or it could be an optional extra library
> shipped in xkbcommon. I'm not sure if the changes in xkbcommon are too
> deep to be able to build a keymap for current XKB or not. What do you
> think? It seems silly not to be making use of xkbcommon in X.

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!

Cheers,
Daniel