[RFC] Automatic modifier update of slave devices

[Peter Hutterer]

On Mon, Feb 24, 2014 at 05:56:41PM -0500, James Cloos wrote:
> >>>>> "PH" == Peter Hutterer <peter.hutterer at who-t.net> writes:
> 
> PH> the less-intrusive alternative would be to force only the indicator state
> PH> down to the slaves. won't change keyboard behaviour as seen by the client
> PH> and still has the effect that most people expect from their keyboards.
> PH> comments?
> 
> 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.
> 
> 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?

the event processing in the server treats slave and master device
separately, even when attached. So if you hit capslock on your physical
keyboard, you'll toggle the lock on that slave device. The same event is
then processed throught he master device, where it will also toggle the
lock. The physical keyboard will have the LED on, the virtual-only master
keyboard too but you obviously can't see that.

Now, when you press caps on your second keyboard, you'll enable it on that
keyboard, the event passes through the master and caps lock will be disabled
on the master, despite being enabled on both slave devices, and both LEDs
being on.

The master copies the keyboard, so you can have two physical keyboards with
two different layouts. So in the case where you have compose:caps on one
keyboard, if you it caps first, then compose on the other keyboard, you'll
get an uppercase compose sequence on the master, regardless which keyboard
you now type on.

This is the current state. It's not ideal...

> I'd want indicator state on a phisical kbd always to match what that kbd
> will do.

that's the problem here, it's really hard to tell in some circumstances, but
one thing is sure: we're not doing that at the moment.

Cheers,
   Peter