[RFC] Automatic modifier update of slave devices

[Daniel Stone]

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.

Cheers,
Daniel