Moving xkbcomp into the server
Paulo Cesar Pereira de Andrade
pcpa at mandriva.com.br
Tue Nov 18 07:36:47 PST 2008
Peter Hutterer 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.
A bit offtopic, but I think xkb really lacks a tool like xkeycaps
Xkb configuration is not something trivial, and a program like that
would be very useful.
But I think the right path should be not move xkbcomp to the X Server,
at least not without a major xkb redesign, instead, have an external
tool (xkbcomp) generate pre compiled keymaps based on a brief description.
> 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
>>> -> XkbDDXNamesFromRules:xkb/ddxLoad.c
>>> this is where all the rules parsing happens, skipping that may save
>>> -> 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.
More information about the xorg