[RFC] Automatic modifier update of slave devices

[Peter Hutterer]

On Mon, Mar 10, 2014 at 10:10:40PM +0100, Daniel Stone wrote:
> Hi,
> 
> On 10 March 2014 17:54, Keith Packard <keithp at keithp.com> wrote:
> > Peter Hutterer <peter.hutterer at who-t.net> 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