From: "Marek Behún" <kabel@kernel.org>
To: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Cc: Pavel Machek <pavel@ucw.cz>,
linuxarm@huawei.com, mauro.chehab@huawei.com,
gregkh@linuxfoundation.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-leds@vger.kernel.org
Subject: Re: [PATCH v2 00/17] Adding support for controlling the leds found on Intel NUC
Date: Thu, 20 May 2021 18:19:19 +0200 [thread overview]
Message-ID: <20210520181919.608568b2@thinkpad> (raw)
In-Reply-To: <20210520010720.32265ad4@coco.lan>
On Thu, 20 May 2021 01:07:20 +0200
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> wrote:
> So, the first thing that the API needs is a way to tell what LED
> is monitoring the device's power state.
If a LED can monitor the device's power state in HW, register a LED
private trigger for this LED. If the LED is configured into this state
by default, you can set this trigger to be the default_trigger prior
registering the LED. The name of this private trigger can be
"hw:powerstate" or something like that (I wonder what others will
think about this name).
> Then, for each power state (S0, S3, S5), define if the LED will
> be ON all the times or not.
>
> The "slowing breathing" is one of the possible blink patterns.
> The driver supports 4 other blink patterns
>
> - Solid - the LED won't blink;
> - Breathing - it looks like a sinusoidal wave pattern;
> - Pulsing - it looks like a square wave pattern;
> - Strobing - it turns ON suddenly, and then it slowly turns OFF.
>
> The speed of the blink is also adjustable, ranging from 0.1 Hz to 1 Hz,
> on 0.1 Hz steps.
Is the speed of breathing/strobing also adjustable? Or only when
pulsing?
When this "hw:powerstate" trigger is enabled for this LED,
only then another sysfs files should appear in this LED's sysfs
directory.
> ---
>
> Let me explain this specific part of the API from my original proposal.
>
> Those are the led names from the datasheets (NUC 8 and above),
> and my proposal for the sysfs class directory name:
>
> ============= ===============================
> LED name sysfs
> ============= ===============================
> Skull ``/sys/class/leds/nuc::skull``
> Skull eyes ``/sys/class/leds/nuc::eyes``
> Power ``/sys/class/leds/nuc::power``
> HDD ``/sys/class/leds/nuc::hdd``
> Front1 ``/sys/class/leds/nuc::front1``
> Front2 ``/sys/class/leds/nuc::front2``
> Front3 ``/sys/class/leds/nuc::front3``
> ============= ===============================
>
> For each of the above, there's the need to identify what
> hardware function is monitored (if any).
>
> My proposal were to add an "indicator" node (the name came from
> the Intel datasheets) that shows what led will monitor the power state.
>
> Then, one blink_behavior and one blink_frequency per power state,
> e. g.:
>
> /sys/class/leds/nuc::front1
> |-- indicator
> |-- s0_blink_behavior
> |-- s0_blink_frequency
> |-- s3_blink_behavior
> |-- s3_blink_frequency
> |-- s5_blink_behavior
> `-- s5_blink_frequency
I'd rather use one file for frequencies and one for intervals, and map
in to an array, but that is just my preference...
>
> PS.: I don't care much about what names we'll use. Feel free to
> rename them, if you think the above is not clear or generic enough.
>
> -
>
> To make part of the API complete, there's also the need of a node
> to control the max brightness that the leds will achieve at the
> ON state, and another one to control the color on each state,
> as one could define, let's say, "white" when powered on, "blue"
> when suspended and "yellow" when hibernating. The colors at the
> NUC I have are RGB (but other models can use an enum for the
> supported colors).
>
> /sys/class/leds/nuc::front1
> |-- s0_brightness
> |-- s0_color # only shown on colored leds
> |-- s3_brightness
> |-- s3_color # only shown on colored leds
> |-- s0_brightness
> `-- s5_color # only shown on colored leds
If the BIOS reports a LED being full RGB LED, you should register it
via multicolor framework. Regarding the enum with 8 colors: are these
colors red, yellow, green, cyan, blue, magenta? Because if so, then
this is RGB with each channel being binary :) So you can again use
multicolor framework.
next prev parent reply other threads:[~2021-05-20 16:19 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-18 15:08 [PATCH v2 00/17] Adding support for controlling the leds found on Intel NUC Mauro Carvalho Chehab
2021-05-18 15:08 ` [PATCH v2 01/17] docs: describe the API used to set NUC LEDs Mauro Carvalho Chehab
2021-05-18 15:08 ` [PATCH v2 02/17] leds: add support for NUC WMI LEDs Mauro Carvalho Chehab
2021-05-18 15:08 ` [PATCH v2 03/17] leds: leds-nuc: detect WMI API detection Mauro Carvalho Chehab
2021-05-18 15:08 ` [PATCH v2 04/17] leds: leds-nuc: add support for changing S0 brightness Mauro Carvalho Chehab
2021-05-18 15:08 ` [PATCH v2 05/17] leds: leds-nuc: add all types of brightness Mauro Carvalho Chehab
2021-05-18 15:08 ` [PATCH v2 06/17] leds: leds-nuc: allow changing the LED colors Mauro Carvalho Chehab
2021-05-18 15:08 ` [PATCH v2 07/17] leds: leds-nuc: add support for WMI API version 1.0 Mauro Carvalho Chehab
2021-05-18 15:08 ` [PATCH v2 08/17] leds: leds-nuc: add basic support for NUC6 WMI Mauro Carvalho Chehab
2021-05-18 15:08 ` [PATCH v2 09/17] leds: leds-nuc: add brightness and color for NUC6 API Mauro Carvalho Chehab
2021-05-18 15:08 ` [PATCH v2 10/17] leds: leds-nuc: Add support to blink behavior for NUC8/10 Mauro Carvalho Chehab
2021-05-19 7:58 ` Marek Behun
2021-05-19 10:09 ` Mauro Carvalho Chehab
2021-05-18 15:09 ` [PATCH v2 11/17] leds: leds-nuc: get rid of an unused variable Mauro Carvalho Chehab
2021-05-18 15:09 ` [PATCH v2 12/17] leds: leds-nuc: implement blink control for NUC6 Mauro Carvalho Chehab
2021-05-18 15:09 ` [PATCH v2 13/17] leds: leds-nuc: better detect NUC6/NUC7 devices Mauro Carvalho Chehab
2021-05-18 15:09 ` [PATCH v2 14/17] leds: leds-nuc: add support for HDD activity default Mauro Carvalho Chehab
2021-05-18 15:09 ` [PATCH v2 15/17] leds: leds-nuc: fix software blink behavior logic Mauro Carvalho Chehab
2021-05-18 15:09 ` [PATCH v2 16/17] leds: leds-nuc: add support for changing the ethernet type indicator Mauro Carvalho Chehab
2021-05-19 8:02 ` Marek Behún
2021-05-19 10:18 ` Mauro Carvalho Chehab
2021-05-19 12:11 ` Marek Behún
2021-05-19 14:24 ` Mauro Carvalho Chehab
2021-05-19 15:55 ` Marek Behún
2021-05-19 18:30 ` Mauro Carvalho Chehab
2021-05-20 11:00 ` Marek Behún
2021-05-20 16:00 ` Mauro Carvalho Chehab
2021-05-20 16:36 ` Marek Behún
2021-05-20 18:59 ` Mauro Carvalho Chehab
2021-05-20 20:07 ` Marek Behún
2021-05-21 9:14 ` Mauro Carvalho Chehab
2021-05-26 14:51 ` Pavel Machek
2021-05-28 11:33 ` Mauro Carvalho Chehab
2021-05-26 14:47 ` Pavel Machek
2021-05-28 11:24 ` Mauro Carvalho Chehab
2021-05-18 15:09 ` [PATCH v2 17/17] leds: leds-nuc: add support for changing the power limit scheme Mauro Carvalho Chehab
2021-05-19 11:11 ` [PATCH v2 00/17] Adding support for controlling the leds found on Intel NUC Pavel Machek
2021-05-19 12:15 ` Mauro Carvalho Chehab
2021-05-19 19:41 ` Pavel Machek
2021-05-19 23:07 ` Mauro Carvalho Chehab
2021-05-20 16:19 ` Marek Behún [this message]
2021-05-20 19:16 ` Mauro Carvalho Chehab
2021-05-20 19:43 ` Marek Behún
2021-05-21 9:57 ` Mauro Carvalho Chehab
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=20210520181919.608568b2@thinkpad \
--to=kabel@kernel.org \
--cc=gregkh@linuxfoundation.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=mauro.chehab@huawei.com \
--cc=mchehab+huawei@kernel.org \
--cc=pavel@ucw.cz \
/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).