Ruminations on XKB configuration

[Daniel Stone]

Hi,
I've been working on some XKB code lately, and I've come across some
problems which I think I've elegantly solved, but wanted to run it past
you guys first.

Firstly, evdev.  As far as I can tell, this really can't be expressed
properly as a model (think of geometry, for example), and should almost
certainly be a ruleset, with different models under that.  Does this
make any sense?  Right now, we lose all geometry and possibility of
per-model settings; much though I agree with the HAL idea of making the
kernel send useful events, I'm not sure it covers all the ground we
need.

The second main problem I'm hitting is configuration.  Ideally, I think
the preference list would look something like this, in descending order:
  * User setting for that keyboard
  * User setting for core keyboard/admin-specified default _for that
    keyboard_ (not sure of the desired order here)
  * Admin-specified system default
  * Fallback system default (i.e. us)

This would require that we rejig the HAL configuration code in a pretty
inelegant way to add a system default layout the admin can override (for
instance, setting a default of fr if they know French keyboards will be
plugged in).  Per-keyboard admin-specified defaults are easy: that's
exactly how our HAL code works today.  User settings for that keyboard
are pretty obvious too.  User settings for the core keyboard would just
be from XkbSetRulesDflts (and potentially inheriting from master devices
in an MPX world).

Has anyone got any objections to doing this?

Aside from that, I'd like to ditch a few things we aren't using at the
moment, such as server-internal modifiers, some of the more insane XKB
server flags, and also potentially overlays.  This would make the code
infinitely more simple.  Also, I'd like to avoid actions where possible
(use the modmap for setting/latching/locking modifiers, in particular),
and extend it a bit so we can run the VT switches from actions, instead
of keysyms, and restore some sanity to our Fx mappings.  Is there
anything you guys know you aren't using that I could throw away, or
anything here you'd like to keep?

I think that's it for the moment.

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