Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109

[Jacek Anaszewski]

On 11/15/2016 11:31 AM, Pavel Machek wrote:
> Hi!
>
> > > Hmm, v4 still calls led_notify_brightness_change(led_cdev)
> > >from both __led_set_brightness() and __led_set_brightness_blocking().
> >
> > Ugh, I see I accidentally send a v4 twice, instead of
> > calling the version which dropped those called v5 as
> > I should have, sorry.
> >
> > The v4 which I would like to see merged, the one with
> > those calls dropped, is here:
> >
> > https://patchwork.kernel.org/patch/9423093/
>
> Please, lets fix this properly.
>
> The LED you are talking about _has_ a trigger, implemented in
> hardware. That trigger can change LED brightness behind kernel's (and
> userspace's) back. Don't pretend the trigger does not exist, it does.
>
> And when you do that, you'll have nice place to report changes to
> userspace -- trigger can now export that information, and offer poll()
> interface.

Well, that sounds interesting. It is logically justifiable.
I initially proposed exactly this solution, with recently
added userspace LED being a trigger listener. It seems a bit
awkward though. How would you listen to the trigger events?

--
Best regards,
Jacek Anaszewski