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

[Daniel Stone]

Hi,

On 19 July 2012 14:07, Dan Nicholson <dbn.lists at gmail.com> wrote:
> Yeah, I remember my disappointment when I discovered all the protocol
> for modifying an existing keymap rather than just starting a new one.

I've been coming across fresh disappointment every week for the last
eight years. ;)

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

Nope - not now, not ever. :( Way too many clients rely on the legacy
calls, and we can't just dramatically break protocol like that, nice
though it'd be.

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

Yes-ish.

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

I'm pretty sure that isn't possible with the current codebase anymore.
 We've been able to make a lot of comprehensibility gains by pushing
out support for being able to alter keymaps on the fly, so we'd have
to go back and add a lot of the support code to make that happen, as
well as freeze our entire ABI while we're still changing large chunks
of it.

It might be possible, but it'd definitely be a great deal easier and
to be honest probably not much less beneficial to start with xkbcomp
(or old xkbcommon), push that into the server, and poke that until it
works.

One of the main benefits you'd get from sharing the parser is the
ability to load keymaps from a future (haha OK, hypothetical) XKB2.
The problem with that though is that you then have to define semantics
for XKB2 compatibility with both core keymaps and XKB1, in both
directions.  I think you'd be hard-pressed to get that right,
especially given that we're still having some trouble with core<->XKB1
compatibility ...

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

We're getting there. :)

Cheers,
Daniel