[RFC] Automatic modifier update of slave devices

[Daniel Stone]

Hi,

On 24 February 2014 22:28, Keith Packard <keithp at keithp.com> wrote:
> Peter Hutterer <peter.hutterer at who-t.net> writes:
>> 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?
>
> That seems even weirder to me -- you've got a NumLock light on, and yet
> your keyboard doesn't have NumLock pressed when seen as a slave?

Yeah, this is exactly my problem: the disjoint state.  Although it
would do the right thing as a master ...

I think we should just synchronise locking state always.  XKB makes
this easy (for once!) and you don't have to guess: every keyboard has
separate state for base (physically pressed down, e.g. Shift), latched
(next press carries and resets state, e.g. phone keyboard Shift), and
locked (e.g. Caps Lock).  These all get combined into the effective
state, from which the core state is derived.

So all you have to do is copy
device->key->xkbInfo->state.locked_{mods,group} from master to slave,
and then call XkbUpdateDerivedState() on each device.

I think the only real long-term solution is to bite the bullet and
ensure master and slaves always have the same keymap (i.e. changing
the keymap on any, changes all in the group), and then synchronise the
state between them all on every keypress.  Slaves joining would then
inherit the master's keymap.  The only real problem with this is how
this would work with xorg.conf, where people might be setting
XkbOptions that would take effect on the slave: when you start the
server, you want these options to take effect and change the whole
group.  But when you have a desktop environment which has changed the
keymap, you don't want a hotplugged keyboard to reset from your DE's
chosen keymap, to the one you put in xorg.conf.

Ultimately this would make things a lot more simple and eliminate a
whole class of problems, but I fear that it's a lot more effort than
anyone would be willing to put into XKB these days ...

Cheers,
Daniel