<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 21 August 2014 08:58, Giulio Camuffo <span dir="ltr"><<a href="mailto:giuliocamuffo@gmail.com" target="_blank">giuliocamuffo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2014-08-21 10:34 GMT+03:00 Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>>:<br>
<div><div class="h5">> Ugh. If you've your own kernel to hand, I'd hack it to WARN_ON(1) on LED<br>
> updates, so you can track where the rogue update is coming from. My guess is<br>
> that switching VT breaks it, so it might work if you instead trigger an<br>
> update of all LED state on every VT enter?<br>
<br>
</div></div>Switching VT is another matter, because all the keyboard devices are<br>
removed so the xkb state is lost, so when returning to weston's vt we<br>
don't know anymore which leds are supposed to be on.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This patch just fixes keyboard hotplugging, besides turning the leds<br>
off at startup.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>Cheers,</div><div>Daniel </div></div></div></div>