Moving xkbcomp into the server

[Dan Nicholson]

On Mon, Nov 17, 2008 at 8:54 PM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> On Mon, Nov 17, 2008 at 11:25:25AM -0800, Dan Nicholson wrote:
>> I decided to take a crack at moving xkbcomp into the server so it's
>> not popen'd whenever a keymap is loaded. For the first crack, I'm
>> trying to just leave xkbcomp pretty much unchanged except for the
>> interface. What's causing me the most difficulty is converting to
>> server API. One snag I've hit is XStringToKeysym. Here's an example
>> usage in the xkbcomp parser:
>
> As much as I'd like to see it in the server - is the popen the painful bit?
> AFAIU, the current approach goes from RMLVO to Kkcstg to xkb to xkm, every
> time we call InitKeyboardDeviceStruct.

I agree completely. As soon as I looked at the path taken in
XkbDDXNamesFromRules, I realized how insane it was that there were all
these conversions. I'm just moving one step at a time here, with the
first one being: leave the retarded conversion path in place, but move
the converter into the server. The next step would be to actually
start removing parts of the conversion process, but that will take a
little more effort.

> Ideally, we'd like to cache and re-use as much as possible. Usually, all
> keyboards come up with the same map anyway and compiling it again is
> redundant. Just doing that might already save a significant chunk of time.
> This should also be much easier to achieve, and if it provides a relevant
> speedup it would be great as interim solution.

I'll try to look at that.

> So the path is
> XkbInitKeyboardDeviceStruct:xkb/xkbInit.c
>  -> XkbDDXNamesFromRules:xkb/ddxLoad.c
>        this is where all the rules parsing happens, skipping that may save
>        time.
>  -> XkbDDXLoadKeymapByNames:xkb/ddxLoad.c
>        this is where xkbcomp is called with the Kcstg format. xkbcomp now
>        parses that into an xkm format
>  -> XkmReadFile:xkb/xkmread.c
>        here we read in the compiled keymap and basically copy it into the
>        internal structs.

Right. So, ideally what would happen is:

1. Skip parsing completely if the rules haven't changed.

2. Go directly from RMLVO->internal structs. Or at least make the
intra-conversion states not involve reading/writing/parsing files.

Seem reasonable?

--
Dan