From: Lee Jones <lee@kernel.org>
To: Rong Zhang <i@rong.moe>, Andrew Lunn <andrew+netdev@lunn.ch>,
Jakub Kicinski <kuba@kernel.org>,
netdev@vger.kernel.org
Cc: "Pavel Machek" <pavel@kernel.org>,
"Thomas Weißschuh" <linux@weissschuh.net>,
"Benson Leung" <bleung@chromium.org>,
"Guenter Roeck" <groeck@chromium.org>,
"Marek Behún" <kabel@kernel.org>,
"Mark Pearson" <mpearson-lenovo@squebb.ca>,
"Derek J. Clark" <derekjohn.clark@gmail.com>,
"Hans de Goede" <hansg@kernel.org>,
"Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>,
"Ike Panhc" <ikepanhc@gmail.com>,
"Vishnu Sankar" <vishnuocv@gmail.com>,
vsankar@lenovo.com, linux-kernel@vger.kernel.org,
linux-leds@vger.kernel.org, chrome-platform@lists.linux.dev,
platform-driver-x86@vger.kernel.org
Subject: Re: [RFC PATCH 0/9] leds: Add support for hw initiated hw control trigger transition
Date: Tue, 10 Mar 2026 12:10:24 +0000 [thread overview]
Message-ID: <20260310121024.GJ183676@google.com> (raw)
In-Reply-To: <20260227190617.271388-1-i@rong.moe>
I'd like for the netdev folks to take a look at this please.
> Some laptops can tune their keyboard backlight according to ambient
> light sensors (auto mode). This capability is essentially a hw control
> trigger. Meanwhile, such laptops also offer a shrotcut for cycling
> through brightness levels and auto mode. For example, on ThinkBook,
> pressing Fn+Space cycles keyboard backlight levels in the following
> sequence:
>
> 1 => 2 => 0 => auto => 1 ...
>
> Recent ThinkPad models should have similar sequence too.
>
> However, there are some issues preventing us from using hw control
> trigger:
>
> 1. We want a mechanism to tell userspace which trigger is the hw control
> trigger, so that userspace can determine if auto mode is on/off or
> turing it on/off programmatically without obtaining the hw control
> trigger's name via other channels
> 2. Turing on/off auto mode via the shortcut cannot activate/deactivate
> the hw control trigger, making the software state out-of-sync
> 3. Even with #1 resolved, deactivating the hw control trigger after
> receiving the event indicating "auto => 1" has a side effect of
> emitting LED_OFF, breaking the shortcut cycle
>
> This RFC series tries to demonstrate a path on solving these issues:
>
> - Introduce an attribute called trigger_may_offload, so that userspace
> can determine:
> - if the LED device supports hw control (supported => visible)
> - which trigger is the hw control trigger
> - if the hw control trigger is selected
> - if the hw control trigger is in hw control (i.e., offloaded)
> - A callback offloaded() is added so that LED triggers can report
> their hw control state
> - Add led_trigger_notify_hw_control_changed() interface, so that LED
> drivers can notify the LED core about hardware initiated hw control
> state transitions. The LED core will then determine if the transition
> is allowed and turning on/off the hw control trigger accordingly
> - Tune the logic of trigger deactivation so that it won't emit LED_OFF
> when the deactivation is triggered by hardware
>
> The last two patches are included into the RFC series to demonstrate how
> to utilize these interfaces to add support for auto keyboard backlight
> to ThinkBook. They will be submitted separately once the dust settles.
>
> Currently no Kconfig entry is provided to disable either interface. If
> needed, I will add one later.
>
> [ Summary of other approaches ]
>
> < custom attribute >
>
> Pros:
> - simplicity, KISS
> - no need to touch the LED core
> - extensible as long as it has a sensor-neutral name
> - a sensor-related name could potentially lead to a mess if a future
> device implements auto mode based on multiple different sensors
>
> Cons:
> - must have zero influence on brightness_set[_blocking] callbacks
> in order not to break triggers
> - potential interference with triggers and the brightness attribute
> - weird semantic (an attribute other than "brightness" and "trigger"
> changes the brightness)
>
> < hw control trigger (this series) >
>
> Pros:
> - mutually exclusive with other triggers (hence less chaos)
> - semantic correctness
> - acts as an aggregate switch to turn on/off auto mode even a future
> device implements auto mode based on multiple different sensors
> - extensibility (through trigger attributes)
>
> Cons:
> - complexity
>
> [ Previous discussion threads ]
>
> https://lore.kernel.org/r/08580ec5-1d7b-4612-8a3f-75bc2f40aad2@app.fastmail.com
>
> https://lore.kernel.org/r/1dbfcf656cdb4af0299f90d7426d2ec7e2b8ac9e.camel@rong.moe
>
> Thanks,
> Rong
>
> Rong Zhang (9):
> leds: Load trigger modules on-demand if used as hw control trigger
> leds: Add callback offloaded() to query the state of hw control
> trigger
> leds: cros_ec: Implement offloaded() callback for trigger
> leds: turris-omnia: Implement offloaded() callback for trigger
> leds: trigger: netdev: Implement offloaded() callback
> leds: Add trigger_may_offload attribute
> leds: trigger: Add led_trigger_notify_hw_control_changed() interface
> platform/x86: ideapad-laptop: Decouple HW & cdev brightness for kbd
> backlight
> platform/x86: ideapad-laptop: Fully support auto kbd backlight
>
> .../obsolete/sysfs-class-led-trigger-netdev | 15 ++
> Documentation/ABI/testing/sysfs-class-led | 22 ++
> .../testing/sysfs-class-led-trigger-netdev | 13 --
> Documentation/leds/leds-class.rst | 72 ++++++-
> drivers/leds/led-class.c | 23 +++
> drivers/leds/led-triggers.c | 176 +++++++++++++++-
> drivers/leds/leds-cros_ec.c | 6 +
> drivers/leds/leds-turris-omnia.c | 7 +
> drivers/leds/leds.h | 3 +
> drivers/leds/trigger/ledtrig-netdev.c | 10 +
> drivers/platform/x86/lenovo/Kconfig | 1 +
> drivers/platform/x86/lenovo/ideapad-laptop.c | 194 ++++++++++++++----
> include/linux/leds.h | 6 +
> 13 files changed, 492 insertions(+), 56 deletions(-)
> create mode 100644 Documentation/ABI/obsolete/sysfs-class-led-trigger-netdev
>
>
> base-commit: a75cb869a8ccc88b0bc7a44e1597d9c7995c56e5
> --
> 2.51.0
>
--
Lee Jones [李琼斯]
next parent reply other threads:[~2026-03-10 12:10 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260227190617.271388-1-i@rong.moe>
2026-03-10 12:10 ` Lee Jones [this message]
2026-03-10 19:04 ` [RFC PATCH 0/9] leds: Add support for hw initiated hw control trigger transition Andrew Lunn
2026-03-11 18:18 ` Rong Zhang
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=20260310121024.GJ183676@google.com \
--to=lee@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=bleung@chromium.org \
--cc=chrome-platform@lists.linux.dev \
--cc=derekjohn.clark@gmail.com \
--cc=groeck@chromium.org \
--cc=hansg@kernel.org \
--cc=i@rong.moe \
--cc=ikepanhc@gmail.com \
--cc=ilpo.jarvinen@linux.intel.com \
--cc=kabel@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-leds@vger.kernel.org \
--cc=linux@weissschuh.net \
--cc=mpearson-lenovo@squebb.ca \
--cc=netdev@vger.kernel.org \
--cc=pavel@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
--cc=vishnuocv@gmail.com \
--cc=vsankar@lenovo.com \
/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