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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).