Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1522620

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

From Hans de Goede <hdegoede@redhat.com>
Newsgroups linux.kernel
Subject Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM regression with LED changes in next-20161109
Date 2016-11-15 13:10 +0100
Message-ID <sDKIO-4KT-33@gated-at.bofh.it> (permalink)
References (6 earlier) <sDJjH-3JZ-9@gated-at.bofh.it> <sDJD4-3QU-37@gated-at.bofh.it> <sDJWp-4cu-5@gated-at.bofh.it> <sDK65-4fE-7@gated-at.bofh.it> <sDKps-4m6-17@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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.

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
>

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2016-11-12 11:30 +0100
  Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-12 11:50 +0100
    Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2016-11-12 20:20 +0100
      Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-12 22:20 +0100
        Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <jacek.anaszewski@gmail.com> - 2016-11-13 12:50 +0100
          Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-13 15:00 +0100
            Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-11-14 10:20 +0100
              Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-14 14:00 +0100
                Re: PM regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-15 11:10 +0100
                Re: PM regression with LED changes in next-20161109 Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-11-15 11:10 +0100
                LEDs that change brightness "itself" -- that's a trigger. Re: PM  regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-15 11:40 +0100
                Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM  regression with LED changes in next-20161109 Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-11-15 12:00 +0100
                Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM  regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-15 12:20 +0100
                Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM  regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-15 12:20 +0100
                Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM  regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-15 12:30 +0100
                Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM  regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-15 12:50 +0100
                Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM  regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-15 13:10 +0100
                Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM  regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-15 13:20 +0100
                Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM  regression with LED changes in next-20161109 Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-11-15 14:30 +0100
                Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM  regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-15 14:50 +0100
                Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM  regression with LED changes in next-20161109 Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-11-15 15:10 +0100
                Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM  regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-15 15:40 +0100
                Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM  regression with LED changes in next-20161109 Jacek Anaszewski <j.anaszewski@samsung.com> - 2016-11-15 15:50 +0100
                Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM  regression with LED changes in next-20161109 Hans de Goede <hdegoede@redhat.com> - 2016-11-17 23:20 +0100
        Re: PM regression with LED changes in next-20161109 Pavel Machek <pavel@ucw.cz> - 2016-11-14 09:40 +0100

csiph-web