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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <94321807-31e5-c1e3-1e79-5abf3bf2e554@redhat.com>
Date:   Thu, 17 Nov 2016 23:12:57 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Jacek Anaszewski <j.anaszewski@...sung.com>,
        Jacek Anaszewski <jacek.anaszewski@...il.com>,
        Tony Lindgren <tony@...mide.com>, linux-leds@...r.kernel.org,
        linux-omap@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-kernel@...r.kernel.org, Darren Hart <dvhart@...radead.org>
Subject: Re: LEDs that change brightness "itself" -- that's a trigger. Re: PM
 regression with LED changes in next-20161109

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
>>