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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Arm (vger)]     [ARM Kernel]     [ARM MSM]     [Linux Tegra]     [Linux WPAN Networking]     [Linux Wireless Networking]     [Maemo Users]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux