[RFC] libxkbcommon: the xkbcomp killer

[Kristian Høgsberg]

On Thu, Apr 23, 2009 at 9:31 AM, Dan Nicholson <dbn.lists at gmail.com> wrote:
> Right now there are a couple difficult XKB tasks that the server forks
> xkbcomp to accomplish. The main reason for this is that xkbcomp contains a
> parser for XKB files and code to do intelligent things with the definitions
> in them. However, these interactions are awful and are an endless source of
> headaches for users and developers.

Awesome, this is so cool.  I'd like to use this in Wayland, so the
comments below are with that in mind, but there's nothing Wayland
specific to the comments, they're generally just pushing for a bit
stronger separation of the modules.

> Since a discussion with Daniel a few months back, I've been working on
> moving the guts of xkbcomp into a library, libxkbcommon, which exposes
> appropriate interfaces to the server (blame Daniel if you hate the name
> :). A secondary goal of libxkbcommon is to move XKB code duplicated in
> the server and client libraries into a reusable location. A few repos
> encompass the work I've done.
>
> http://cgit.freedesktop.org/~dbn/libxkbcommon/
>
> The library itself. New interfaces are in <X11/extensions/XKBcommon.h>.
> Right now all that's really exposed are compiling keymaps and listing
> components (i.e., satisfy the server's requirements).

Looking at the configure.ac here, it looks like it requires xproto and
kbproto?  What's the dependency there?  Could we move anything it
needs from kbproto to libxkbcommon headers and move the Xlib specifics
from kbproto into Xlib or libXKB?  Of course older Xlibs won't be able
to build against the newer kbproto, but that's why we have version
numbers.  I see you pulled in the keyname->keysym map to avoid the
libX11 dependency, nice.

> http://cgit.freedesktop.org/~dbn/kbproto/
>
> Refactored XKB headers. I needed to split the generic datatypes away from
> the client side datatypes to avoid pulling in Xlib.h and friends. Should
> remain API compatible as the headers just go from XKBstr.h to XKBstr.h +
> XKBstrcommon.h (generic types). It's not pretty, but the XKB headers never
> were, and I didn't want to have to make a full internal copy of them like
> in the server.

When the server was modularized a lot of implementation headers ended
up in proto modules and we're still dragging that around.  I think
it'd be great to see that cleaned up to, even if we have to bump the
kbproto major.  In some cases it wasn't possible to split the headers
properly, since they had structs that were used in the implementation
on both the client and server side.  But libxkbcommon fills that gap,
and as I see it, with kbproto (protocol tokens and structs),
libxkbcommon (server and client shared implementation and headers),
libXCB/libX11 (client side) and xserver (server side), we can now move
things around to where they should be.

> This is just scratching the surface, though. There is currently a full XKB
> stack in the server and a lot of it could just be reused from xkbcommon. A
> ton of code is there to support writing a XKB keymap file. Sadly, I can't
> kill this yet as it's what makes XkbGetKeyboardByName possible.
>
> On the positive side, the server is now fork-free and xkbcomp is a thing of
> the past.
>
> http://cgit.freedesktop.org/~dbn/libxkbfile/
>
> Not really needed, but I moved a couple generic headers to kbproto. This
> version just requires a newer kbproto so there aren't header conflicts.
>
> Things still to do:
>  - There's a bug somewhere in the keymap compiling that exposed a floating
>   point exception in the server xkb code, but my keyboard seems to be
>   working correctly
>  - Figure out how to do all the "merge new components into current keymap"
>   thing required by X_kbGetKbdByName without resorting to generating a
>   whole custom keymap file.
>  - Refactor more XKB code into xkbcommon and actually start using it in
>   xserver, xlib and xkbfile. This work increases the number of full XKB
>   stacks to 3. :)

To this last point, what can libxkbcommon do now and what's currently missing?

> Let me know what you think. I'm open to changing names or interfaces or
> whatever, but I think the major direction of the code is a good thing.

I think this is really great work, getting that fork out of the server
is excellent.  Again, my pipe dream is that I can eventally compile
libxkbcommon with as few X11 dependencies as possible and then 1)
parse an xkb keymap, 2) feed it an evdev keycode, 3) get the resulting
keysym.  I can dream ;)

thanks,
Kristian