Moving xkbcomp into the server
peter.hutterer at who-t.net
Tue Nov 18 04:28:39 PST 2008
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
More information about the xorg