LEDs with hardware-accelerated patterns, suspend indication

LEDs with hardware-accelerated patterns, suspend indication

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]

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

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

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.

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.

Best regards,
								Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: LEDs with hardware-accelerated patterns, suspend indication

[Hans de Goede]

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

Re: LEDs with hardware-accelerated patterns, suspend indication

[Hans de Goede]

<I accidentally dropped the Cc list when mailing Jafar, I'm restoring it now>

Hi All,

On 6/12/21 10:21 PM, Jafar Akhondali wrote:
> Hi Hans,
> 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?

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 ?

Regards,

Hans




> On Mon, Jun 7, 2021 at 11:58 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi,
>>
>> On 6/4/21 10:57 PM, Jafar Akhondali wrote:
>>> Hi Hans,
>>>
>>> On Sat, Jun 5, 2021 at 12:58 AM Hans de Goede <hdegoede@redhat.com> wrote:
>>>>
>>>> Hi Pavel,
>>>>
>>>> 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 ?
>>> Sure, Acer predator helios 300 got a 4-zone RGB keyboard.
>>> Some of the mentioned modes like "wave" accept less configurable
>>> parameters, such as color.
>>> This is because the effect itself changes the color. So yes, there is
>>> no per-key rgb at least in this model,
>>> and the lowest possible change is to change each zone.
>>> You can watch a video of keyboard demo here(check after 2:05):
>>> https://www.youtube.com/watch?v=eAfAwNiIWbA
>>> Above uses PredatorSense, which is Acer's official gaming control app.
>>> Also, my patch provides only support for effects, and not static coloring.
>>> As a workaround for static coloring, it's possible to use a effect
>>> with zero speed,
>>> so it looks like static coloring til I can figure how static coloring
>>> is implemented.
>>>
>>> The whole config for my patch accepts 16 bytes which configures different modes.
>>> I've also created a CLI interface for configuring this steps, so you
>>> can check required params
>>> from there too:
>>> https://github.com/JafarAkhondali/acer-helios-300-rgb-keyboard-linux-module/blob/main/facer_rgb.py
>>>
>>> Hope this helps, and thanks for adding me.
>>
>> Thank you for the extra info, looking at the video it seems that the
>> wave effect is cycling through the colors of the rainbow, but at the
>> same time it also seems that say starts in zone 1 and then moves to
>> zone 2 (while zone 1 becomes say purple) and then after that the red
>> moves to zone 3 and then zone 2 becomes purple. Did I see that
>> correct ? And is this just caused by the software not starting the
>> cycle effect in the different zones at the same time, or is this actual
>> the intended wave effect ?
>>
>> What I'm trying to ask here is if the 4 zones are fully independent,
>> e.g. one could be in wave effect while the other 3 zones do something
>> else, or are certain effects multi-zone effects?
>>
>> Regards,
>>
>> Hans
>>
> 

Re: LEDs with hardware-accelerated patterns, suspend indication

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 1464 bytes --]

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?

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

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

Best regards,
							Pavel
-- 
http://www.livejournal.com/~pavelmachek

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: LEDs with hardware-accelerated patterns, suspend indication

[Hans de Goede]

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