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