[PATCH weston 1/3] evdev/libinput: sync the leds of keyboards with the xkb state

[Giulio Camuffo]

2014-08-21 15:06 GMT+03:00 Daniel Stone <daniel at fooishbar.org>:
> Hi,
>
> On 21 August 2014 08:58, Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
>>
>> 2014-08-21 10:34 GMT+03:00 Daniel Stone <daniel at fooishbar.org>:
>> > Ugh. If you've your own kernel to hand, I'd hack it to WARN_ON(1) on LED
>> > updates, so you can track where the rogue update is coming from. My
>> > guess is
>> > that switching VT breaks it, so it might work if you instead trigger an
>> > update of all LED state on every VT enter?
>>
>> Switching VT is another matter, because all the keyboard devices are
>> removed so the xkb state is lost, so when returning to weston's vt we
>> don't know anymore which leds are supposed to be on.
>
>
> Sure we do: the usual way is to release all keys on VT leave, resetting
> latches but leaving locks as they are. So when they came back, just apply
> the state that occurred as a result of that, rather than trying to maintain
> a totally unknown state from whilst you were switched away, or reset it
> completely.

I mean the current weston code doesn't know the state anymore. Sure
that can be fixed, but I think it should be another patch.

>
>>
>> This patch just fixes keyboard hotplugging, besides turning the leds
>> off at startup.
>
>
> Sure. I really, really don't like that timer though ... I'd rather just sit
> this one out whilst we work out the correct thing to do though. If you've
> got some time on your hands, looking at the VT-enter path would be good I
> think; even if it doesn't make the first release, I think it'd make a good
> stable-branch candidate.

I agree the timer is ugly, but I have other priorities at the moment
honestly, so I'm not going to spend big amount of time on this, at
least yet. I'm fine with leaving this one be and getting only the
other two in.



Thanks,
Giulio


>
> Cheers,
> Daniel