Hi, On 10 March 2014 17:54, Keith Packard <[email protected]> wrote: > Peter Hutterer <[email protected]> writes: >> tbh, at this point I'm in preference of 3 (i.e. mirroring locking modifiers), >> mainly because it seems the most obvious and intuitive solution. > > I concur -- the locking modifier state should match the master, and the > LED state should reflect those. Simple and consistent.
Ack from me - either 3 (mirror locks) or 4 (mirror all state). The main downside is that people listening for XKB state change events on slaves might see multiple events, but eh, don't do that really. I think there's a good argument to be made for 4 in that the master and slave state would then be totally coherent; it would also help the footpedal case. If I was doing anything at all with allowExplicit and LEDDrivesKB, it'd be to purge support for them entirely. The only way xkbcommon eventually got some form of tractability was dropping support for things like this, including binning mutable keymaps entirely: this meant abandoning the idea of ever using it in the server, but oh well. Cheers, Daniel _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
