[PATCH xserver] xkb: after changing the keymap, force an indicator update

[Daniel Stone]

On 4 May 2016 at 11:36, Peter Hutterer <peter.hutterer at who-t.net> wrote:
> When NumLock is on and a new keymap is applied, the next modifier state change
> will turn off that LED (but leave the state enabled). The cause for this is a
> bit convoluted:
> * the SLI explicitState is copied from the current state in
>   ProcXkbGetKbdByName. Thus, if NumLock is on, that state is 0x2.
> * on the next modifier key press (e.g. Shift), XkbApplyState() calls into
>   XkbUpdateIndicators() -> XkbUpdateLedAutoState() to update SLIs (if any) for
>   the currently changed modifier. But it does so with a mask only for the
>   changed modifier (i.e. for Shift).
> * XkbUpdateLedAutoState() calculates the state based on this mask and
>   ends up with 0 because we don't have a Shift LED and we masked out the
>   others.
> * XkbUpdateLedAutoState() compares that state with the previous state (which
>   is still 0x2) and then proceeds to turn the LED off
>
> This doesn't happen in the normal case because either the mask encompasses all
> modifiers or the state matches of the masked-out modifiers matches the old
> state.
>
> Avoid this issue by forcing an SLI update after changing the keymap. This
> updates the sli->effectiveState and thus restores everything to happy working
> order.
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1047151
>
> Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>

Reviewed-by: Daniel Stone <daniels at collabora.com>

Cheers,
Daniel