From: Pavel Machek <pavel@ucw.cz>
To: Hans de Goede <hdegoede@redhat.com>
Cc: Jafar Akhondali <gigelaknak@gmail.com>,
Andy Shevchenko <andy.shevchenko@gmail.com>,
Mauro Carvalho Chehab <mchehab+huawei@kernel.org>,
mauro.chehab@huawei.com,
Linux LED Subsystem <linux-leds@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: LEDs with hardware-accelerated patterns, suspend indication
Date: Wed, 23 Jun 2021 22:39:25 +0200 [thread overview]
Message-ID: <20210623203925.GI8540@amd> (raw)
In-Reply-To: <17ec2040-24e9-4090-e64b-8048f0b4005b@redhat.com>
[-- 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 --]
next prev parent reply other threads:[~2021-06-23 20:39 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-26 15:30 LEDs with hardware-accelerated patterns, suspend indication Pavel Machek
2021-06-04 20:28 ` Hans de Goede
[not found] ` <CAMW3L+19tP_9=+8j8LLjqCGDaaVZ86UMm9NwLbbpA77zOYnr1Q@mail.gmail.com>
[not found] ` <79988fe2-7b3d-7485-131c-4f654ec6d8b8@redhat.com>
[not found] ` <CAMW3L+13O4jXyp1LVtuxhpXP_fkfWXi9JoNS8FYUAMHaJBGKZg@mail.gmail.com>
2021-06-15 12:17 ` Hans de Goede
2021-06-23 20:39 ` Pavel Machek [this message]
2021-06-25 9:18 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210623203925.GI8540@amd \
--to=pavel@ucw.cz \
--cc=andy.shevchenko@gmail.com \
--cc=gigelaknak@gmail.com \
--cc=hdegoede@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=mauro.chehab@huawei.com \
--cc=mchehab+huawei@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.