Moving xkbcomp into the server

[Daniel Stone]

Hi,

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

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.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20081119/1498f65f/attachment.pgp>