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]

Date:   Fri, 25 Jun 2021 11:18:35 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     Pavel Machek <pavel@....cz>
Cc:     Jafar Akhondali <gigelaknak@...il.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Mauro Carvalho Chehab <mchehab+huawei@...nel.org>,
        mauro.chehab@...wei.com,
        Linux LED Subsystem <linux-leds@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: LEDs with hardware-accelerated patterns, suspend indication

Hi,

On 6/23/21 10:39 PM, Pavel Machek wrote:
> Hi!
> 
>>> Sorry for the late reply.
>>> there are two categories of keyboard lighting modes:
>>> 1. static
>>> 2. dynamic
>>>
>>> In static mode, any of 4 zones can be configured to show specific color,
>>> independently.
>>>
>>> In dynamic mode, there is no control over specific zones.
>>> It's only possible to set some: color, speed, direction
>>> and: [R]ed,[G]reen, [B]lue
>>>
>>> so in dynamic mode, the user can't control zones,
>>> the dynamic effects take care of that.
>>
>> So we have 4 zones, which are individual controllable, so which should
>> probably be modeled as individual LED class devices. But when we enable
>> the hardware effects, then the individual addressing goes away and we
>> set one effect which applies to all zones.
>>
>> Jafar, do I understand this correctly?
>>
>> Pavel, how should this be mapped to the led-class API?
> 
> Fun :-).
> 
>> Some ideas:
>>
>> a) Only add the new lpattern to the main zone?
>> 2) Add the new lpattern to all zones, but only make it
>> writable in the main zone ?
> 
> Require lpattern in all zones to be same and active before actually
> enabling the pattern?

That seems less user friendly / a cumbersome interface I prefer
one of my 2 initial ideas.

Or maybe add lpattern symlinks to the other zones to the main zone,
I think that is actually best because it clearly shows how things
work, all 4 LED (zones) support a lpattern, but it is a single
shared lpattern.

> Decide lpattern is not suitable for this and figure out what to with
> multi-LED triggers? Someone wanted them for "meters" (CPU load 25% 50%
> 75% 100% LED bar)...

I think true multi-led triggers are overkill here, in essence this
is just a standard lpattern, except that it is shared between the
zones. 

> Skip this hardware feature for now. We don't have to support
> everything?

Although it is true that we don't have to support everything not
supporting this would give Linux a feature disparity with the
Windows utility for controlling the keyboard which IMHO is
undesirable.

Regards,

Hans