What's wrong with xkbcomp?
peter.hutterer at who-t.net
Tue Sep 23 19:11:40 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
> |____ xkb_types
> |____ xkb_compatibility
> |____ xkb_symbols
> |____ xkb_geometry
There's two stages involved.
Step 1: is to go from the RMLVO in setxkbmap into a xkb_keymap. This includes
trawling through rules files, etc.
Step 2: is to parse the xkb_keymap into the server's internal format.
For Step 1:
- leave the xkb_keymap around instead of regenerating it.
- connect RMLVO and Ktcsg so you can get the former from the latter. This
way you can check if an xkb_keymap is correct for a given RMLVO.
For Step 2:
- don't go through the fork, let the server parse it.
- xkb_geometry isn't used by the server until a client actually requests it
(AFAIK). maybe parsing can be deferred?
- the xkb_XXX could be split into several files, only requiring reparsing
e.g. xkb_symbols if the symbols change.
More information about the xorg