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

[Hans de Goede]

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