[RFC] Automatic modifier update of slave devices

[Peter Hutterer]

On Mon, Feb 24, 2014 at 09:32:57PM +0000, Daniel Stone wrote:
> Hi,
> 
> On 24 February 2014 21:28, Keith Packard <keithp at keithp.com> wrote:
> > Daniel Stone <daniel at fooishbar.org> writes:
> >> whilst not doing anything surprising like having a base modifier down
> >> which was never pressed on that device.
> >
> > Are you saying that we should only mirror the locking modifier state
> > From master to slaves? That seems plausible, but seems more complicated
> > and not all that useful to me, as now the slave will report some, but
> > not all, of the master modifier state.
> 
> I'm suggesting the minimal change possible to solve the stated problem
> (which is essentially that new slaves don't inherit the LED - i.e.
> lock - state of their masters). I'm pretty wary of the full push to
> always push master state down to slaves, especially given the fact
> that slaves may have wholly disjoint keymaps to their masters.  The
> latter was an incredibly dumb idea in hindsight and can almost never
> produce meaningful results in practice, but hey, what can you do.

yeah, I agree, I'm a bit wary of pushing down the state too, it was the
simplest approach though. but I'm sure 2 years down the track we'll hear
from someone whose workflow relied on the current behaviour...

the less-intrusive alternative would be to force only the indicator state
down to the slaves. won't change keyboard behaviour as seen by the client
and still has the effect that most people expect from their keyboards.
comments?

Cheers,
   Peter