What's wrong with xkbcomp?

[Daniel Stone]

On Wed, Sep 24, 2008 at 02:42:29AM +0100, Simos Xenitellis wrote:
> The next step in replacing xkbcomp would be to list any of the
> structures we many want to eliminate or reduce some of the fields.
> 
> xkb_keymap
>     |____ xkb_keycodes

Required, mostly invariant.

>     |____ xkb_types

Required.

>     |____ xkb_compatibility

Required.

>     |____ xkb_symbols

Required.

>     |____ xkb_geometry

Not really required.

> Then, write a library using either the existing grammar/code or
> rewrite it, that parses the configuration files and fills in an
> XkbDescRec structure. This can then be added to Xorg.

I'd suggest a new one.  I don't see that the lexing is inherently
difficult[0], nor that there's any intrinsic property that should make
the parsing take so long.  My money's on the overhead of:
   * forking in the first place
   * having to lex stdin instead of just getting five components as
     arguments
   * serialising to XKM and writing out to a real file
   * deserialising from XKM

Fix those and you've probably got a very quick xkbcomp now.

It is possible that the descriptions could be a coalesced a little such
that we had a few larger files, rather than lots of tiny files in some
instances, particularly as I don't know of anything that includes
anything other than 'complete' for types and compat.

> In this process of creating a library, what I see is that there will
> always be time spent in parsing again and again. If we can cache some
> part of the configuration that does not change often, we can save
> time.

Just cache the entire keymap and you can save loads of time.  Maybe
fine-grained caching (one per component) would really help, but I'm
inclined to guess that you'd spend more time managing the cache than
you'd actually save.

> Additionally, when a user changes a setting in the keyboard layouts
> dialog box and chooses to Apply/Save, the UI app could simply do the
> necessary parsing while showing an hourglass, and produce an
> optimized, maybe binary format, file, that can be de-serialised fast
> by the X server.

Actually, this is what GNOME does now, but this means that both the
client and the server have to have access to the exact same keyboard
definitions.  Ugh.

> In this workflow, X.org would simply need to add
> support to read the configuration from an optimised file format and
> construct an XkbDescRec structure.

Um, that's XKM.

All this sounds like a pretty elaborate end-run around xkbcomp being
slow, when there's no reason at all it should be that slow ...

Cheers,
Daniel

[0]: I've been avoiding it as I've not written a lexer before.  I don't
     have anything against the idea, but the current xkbcomp is
     definitely My First Lexer, and we don't need another of those.
-------------- 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/20080924/53cf321d/attachment.pgp>