[RFC] Automatic modifier update of slave devices

[Daniel Stone]

Hi,

On 24 February 2014 22:56, James Cloos <cloos at jhcloos.com> wrote:
> So hitting compose on one keyboard would light the compose led on all
> associated keyboards but only intitiate a compose sequence on the one?
>
> Or caps-lock?  Or level shifts?  Or group toggles?
>
> If I read that right, that seems even worse.

Depends.  Every key press generates two events - one for the slave and
another for the master, and both are processed totally differently.
So if you had Num Lock being set in this manner (actually locked on
the master, but only updating the LED for the slave), then pressing 4
would result in a KP_4 keypress on the master, and a KP_Left press on
the slave.  Still not present, but as Peter says, don't listen to
slaves which are attached to masters and expect sensible results ...

> I'd want indicator state on a phisical kbd always to match what that kbd
> will do.
>
> I'm not certain about the other two options, though.
>
> Given that I use a keyboard which shows up as two usb endpoints, and
> each endpoint is a separate slave kbd to the shared master, I'd prefer
> that shift, et alia states for one slave apply to all.
>
> But that may not be right for everyone's setup.
>
> Perhaps xinput(1) should be able to configure whether given slaves share
> such state with their brethren?

Ugh, that sounds like the worst of all possible worlds, if I'm honest:
this is one place we really, really, don't need more complexity and
unexpected behaviour.  I'd prefer us to just make a decision one way
or another - go all-out and forcibly harmonise keymaps, or one of the
compromises along the way - and stick with that to the bitter end.

Cheers,
Daniel