Hi,
On 15-11-16 13:06, Hans de Goede wrote:
Hi,
On 15-11-16 12:48, Pavel Machek wrote:
Hi!
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.
Thanks.
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?
Trigger exposes a file in sysfs, with poll() working on that file
Hmm, a new file would give the advantage of making it easy for
userspace to see if the trigger is poll-able, this is likely
better then my own proposal I just send.
Good.
(and
probably read exposing the current brightness).
If we do this, can we please make it mirror brightness, iow
also make it writable, that will make it easier for userspace
to deal with it. We can simply re-use the existing show / store
methods for brightness for this.
Actually, echo 0 > brightness disables the trigger, IIRC. I'd avoid
that here, you want to be able to turn off the backlight but still
keep the trigger (and be notified of future changes).
True, that is easy to do the store method will just need to call
led_set_brightness_nosleep instead of led_set_brightness, this
will skip the checks to stop blinking in led_set_brightness and
otherwise is equivalent.
I suggest we call it:
trigger_brightness
And only register it when a poll-able trigger is present.
I'd call it 'current_brightness', but that's no big deal. Yes, only
registering it for poll-able triggers makes sense.
current_brightness works for me. I will take a shot a patch-set
implementing this.
Done, this actually turned out pretty nice, the trigger also helps
in propagating the change events from dell-wmi to the led-classdev
in dell-laptop without needing the ugly hacks I needed before.
v5 coming up.
Regards,
Hans
Key difference is that only triggers where this makes sense (keyboard
backlight) expose it and carry the overhead. CPU trigger would
definitely not do this.
Ack only having some triggers pollable is important.
Thanks,
Pavel
--
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
