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

[Dan Nicholson]

Sorry for the slow reply. This was interesting to read, but I got busy.

On Fri, Jul 13, 2012 at 7:50 AM, Daniel Stone <daniel at fooishbar.org> wrote:
> 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.

Yeah, I remember my disappointment when I discovered all the protocol
for modifying an existing keymap rather than just starting a new one.
A couple things came to mind which may be crack since I still only
have a rudimentary understanding of XKB.

1. Would it be possible to just drop support for all the "on-the-fly"
protocol and fix the major clients like xmodmap to just build a new
keymap and send it to the server? It would kind of suck, but maybe it
could be coordinated for a katamari.

2. Could the server still use xkbcommon for keymap creation and other
utilities below its current piles of XKB code?

3. If 2. doesn't work because it needs more access to xkbcommon
internals, could a separate compat library live in the xkbcommon tree
that would be solely for supporting XKB1?

Just some ideas.

> 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.

It seems like you guys are doing the right thing with xkbcommon to
make it a useful project. At least if XKB2 ever comes along you'll
have a solid idea of what's actually needed and some of the esoteric
bits can be dropped.

> 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!

No, no. It was and is your project. I just got interested long enough
to smash some code together and am happy enough to have this effort
recorded in git.

--
Dan