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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ xorg mailing list xorg@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/xorg