Moving xkbcomp into the server

[Peter Hutterer]

On Tue, Nov 18, 2008 at 03:44:32AM -0800, Dan Nicholson wrote:
> 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.

I think it'd be less effort to leave the converter as-is and remove the need
for calling it, but that's a guess only too.
 
> > 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.

right, you'd go from "oh, same RMLVO" to xkmRead() directly. In theory, you
could just memcpy the structs from another device but that's not a task for
the faint-hearted.

Cheers,
  Peter