Moving xkbcomp into the server
daniel at fooishbar.org
Tue Nov 18 17:23:17 PST 2008
On Tue, Nov 18, 2008 at 11:08:36AM -0800, Dan Nicholson wrote:
> On Tue, Nov 18, 2008 at 4:28 AM, Peter Hutterer
> <peter.hutterer at who-t.net> wrote:
> >> 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.
I'd rather ditch the XKM completely, and go from RMLVO to KcCGST (this
part of the conversion isn't hideously painful, though I'm sure the
rules parsing could be made faster and more efficient) to XkbDescRec.
This basically just means shoving xkbcomp into the server and deleting
all the code that deals with XKM: just delivering the XkbDescRec it
I haven't profiled this, so I'm likely to be wrong, but my money's on
having to create a new file, wait while our fork()ed process writes it
out, waiting for it to bail, then reading back and deserialising the
very same file into the exact same format, being a reasonable part of
the performance problem. That and the actual lexer/etc is crap.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 197 bytes
Desc: Digital signature
More information about the xorg