On 21 August 2014 13:17, Giulio Camuffo wrote:
> 2014-08-21 15:06 GMT+03:00 Daniel Stone :
> > On 21 August 2014 08:58, Giulio Camuffo wrote:
> >> 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
> >>
2014-08-21 15:06 GMT+03:00 Daniel Stone :
> Hi,
>
> On 21 August 2014 08:58, Giulio Camuffo wrote:
>>
>> 2014-08-21 10:34 GMT+03:00 Daniel Stone :
>> > 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
Hi,
On 21 August 2014 08:58, Giulio Camuffo wrote:
> 2014-08-21 10:34 GMT+03:00 Daniel Stone :
> > 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 mi
2014-08-21 10:34 GMT+03:00 Daniel Stone :
> Hi,
>
>
> On Wednesday, August 20, 2014, Giulio Camuffo
> wrote:
>>
>> When a new keyboard is found (including during startup) sync its leds
>> with the internal state of the xkb map.
>> It appears that by setting them immediately when getting the new de
Hi,
On Wednesday, August 20, 2014, Giulio Camuffo
wrote:
> When a new keyboard is found (including during startup) sync its leds
> with the internal state of the xkb map.
> It appears that by setting them immediately when getting the new device
> we're racing with the kernel or something, which
When a new keyboard is found (including during startup) sync its leds
with the internal state of the xkb map.
It appears that by setting them immediately when getting the new device
we're racing with the kernel or something, which wants to turn all the
leds off, so we use a timer.
---
I can't say
