Moving xkbcomp into the server

[Dan Nicholson]

On Tue, Nov 18, 2008 at 4:28 AM, Peter Hutterer
<peter.hutterer at who-t.net> wrote:
> 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, I took a look at this, and it was fairly easy to write an
(untested) patch that checks if RMLVO has been changed and bailing out
early from XkbInitKeyboardDeviceStruct if it hasn't. However, I think
this still leaves you with two xkbcomps during the startup in the
common configuration. XkbInitKeyboardDeviceStruct will be called first
via InitCoreDevices with the default ruleset ("base", "pc105", "us",
NULL, NULL). Then the driver will call XkbInitKeyboardDeviceStruct
again with a ruleset that is probably different (most likely rules ==
"evdev"). So, you're going to get two keymap conversions in most
cases, anyway, but at least totally gratuitous conversions can be
removed. I'll send that patch after I test it a bit.

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

But, why not "oh, same RMLVO, do nothing"? Oh, that's because you have
to do it for each device. I guess then you probably want to keep the
xkm file in that case, and only unlink during CloseDownDevices or
something. Unfortunately, the xkm file is immediately deleted right
now. This really only helps if you have multiple keyboards or you're
hotplugging them, though.

--
Dan