On Mon, Mar 10, 2014 at 10:10:40PM +0100, Daniel Stone wrote: > 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.
The second patch-set is available here: http://lists.x.org/archives/xorg-devel/2014-March/040835.html I'd appreciate a review so I can push this. I can drop 2/4, 1/4 has a v3. Cheers, Peter _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
