linux-kernel - Re: LEDs with hardware-accelerated patterns, suspend indication

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: <5fbbab4f-3e22-5a4a-eea8-2531ee165cc4@redhat.com>
Date:   Fri, 4 Jun 2021 22:28:48 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     Pavel Machek <pavel@....cz>,
        kernel list <linux-kernel@...r.kernel.org>,
        andy.shevchenko@...il.com, mchehab+huawei@...nel.org,
        mauro.chehab@...wei.com, linux-leds@...r.kernel.org,
        Jafar Akhondali <jafar.akhoondali@...il.com>
Subject: Re: LEDs with hardware-accelerated patterns, suspend indication

Hi Pavel,

On 5/26/21 5:30 PM, Pavel Machek wrote:
> Hi!
> 
> We have hardware trigger for arbitrary patterns... but then we have
> common hardware that can do few simple patterns but not arbitrary
> ones.
> 
> Proposal:
> 
> Have a new hardware trigger "lpattern" that will allow selection of
> patterns hardware can commonly provide. I guess that is "off", "on",
> "blinking", "breathing". Maybe with variations like "slow" and "fast".

Adding Jafar, who has been working on adding support for the hardware
patterns on the Acer Helios 300 RGB keyboard.

Quoting from his patch for this:

Backlight modes:
1: Breath
2: Neon
3: Wave
4: Shifting
5: Zoom

So it looks like we need some more patterns for this to also be
usable for his case, although patterns like wave, shifting and zoom
sound like they are multi-LED patterns.

Jafar can you explain how this works in a bit more detail. I get
the feeling that from a hardware-API pov there are no individual
addressable LEDs, yet some effects do program individual LEDs
differently then their neighbors ?  Or am I just misunderstanding
what some of the effects do ?

> It should provide software fallbacks, so we have reference how the
> patterns should look like and behave.

I think that we should probably define a couple of standard
patterns with sw-fallbacks but also allow drivers to add
driver specific pattern names, which won't have a sw fallback,
this could then be combined with a lpatterns_available sysfs
file or some such which lists the standard patterns + the
driver specific patterns.

This could then e.g. be used by the Acer Helios 300 RGB keyboard
case.

> It is quite common to provide LED with charging activity.
> 
> Proposal:
> 
> Have a trigger called "charging" which would provide three
> subdirectories "charged", "charging" and "discharging" with interface
> similar to the new "lpattern" trigger.

When you say similar, you mean that each dir will have a lpattern
file which can have one of the (standard) lpattern values ?

This sounds good to me (this should work well for the whiskey-cove
PMIC case which we discussed a while ago.

> It is very common to have combined LED for power and suspend.
> 
> Proposal:
> 
> Have a trigger called "sysstate" with three subdirectories "off", "on"
> and "suspended", with interfaces similar to the "lpattern" trigger.

Regards,

Hans