What's wrong with xkbcomp?
daniel at fooishbar.org
Wed Sep 24 01:14:16 PDT 2008
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_keycodes
Required, mostly invariant.
> |____ xkb_types
> |____ xkb_compatibility
> |____ xkb_symbols
> |____ 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, 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
* 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
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
> 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 ...
: 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...
Size: 197 bytes
Desc: Digital signature
More information about the xorg