Hi all,

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

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 [李琼斯]

On Tue, Mar 10, 2026 at 12:10:24PM +0000, Lee Jones wrote:
> I'd like for the netdev folks to take a look at this please.

Before i get the rational of these patches....

Have they been tested with CONFIG_PROVE_LOCKING enabled? My experience
with networking is that it is very easy to get tied up in AB-BA
deadlocks. You need the LED to be as dumb as possible, it is always
logically 'below' the trigger. Having the LED calling up into the
trigger generally gets you into trouble.

	Andrew

Hi Andrew,

On Tue, 2026-03-10 at 20:04 +0100, Andrew Lunn wrote:
> On Tue, Mar 10, 2026 at 12:10:24PM +0000, Lee Jones wrote:
> > I'd like for the netdev folks to take a look at this please.
> 
> Before i get the rational of these patches....
> 
> Have they been tested with CONFIG_PROVE_LOCKING enabled? My experience
> with networking is that it is very easy to get tied up in AB-BA
> deadlocks. You need the LED to be as dumb as possible, it is always
> logically 'below' the trigger. Having the LED calling up into the
> trigger generally gets you into trouble.

I will test it. Thanks for your reminder.

Thanks,
Rong

> 
> 	Andrew

Hi Rong,

On Fri, Feb 27, 2026, at 2:05 PM, Rong Zhang wrote:
> Hi all,
>
> 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

Thanks for your work on this.

For the series: As it's a RFC, I'm not bothering with notes on any typo's or grammer stuff.

Overall I think the implementation works and I understand it better from our initial discussions. Thank you for putting this together.

I'm not a huge fan of the term offloaded - I would lean towards just calling it hw_control (or similar). But I see it was used in the ledtrig-netdev driver so I don't feel strongly about this.

Vishnu - can you check out how this would work with the Thinkpad implementation that you've been working on, please? I think that will be helpful to highlight any design issues.

Mark

> I'm not a huge fan of the term offloaded

In networking, 'offload' is key to the whole concept. We take what the
network stack is doing in software and try to offload it to the
hardware.

See my reply to patch 0/42 for more details.

	Andrew

Hi Mark,

On Wed, 2026-03-04 at 15:05 -0500, Mark Pearson wrote:
> Hi Rong,
> 
> On Fri, Feb 27, 2026, at 2:05 PM, Rong Zhang wrote:
> > Hi all,
> > 
> > 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
> 
> Thanks for your work on this.
> 
> For the series: As it's a RFC, I'm not bothering with notes on any typo's or grammer stuff.
> 
> Overall I think the implementation works and I understand it better from our initial discussions. Thank you for putting this together.
> 
> I'm not a huge fan of the term offloaded - I would lean towards just calling it hw_control (or similar). But I see it was used in the ledtrig-netdev driver so I don't feel strongly about this.
> 

FYI, "hw control" is a historical and internal term. I used it because
it's used a lot in the documentation to the doc consistent. Otherwise
"offload(ed)" should be used. See commit 44f0fb8dfe26 ("leds: trigger:
netdev: rename 'hw_control' sysfs entry to 'offloaded'").

I admit that I was somewhat lost in the terminological soup and there
may be some room for rephrasing in my documentation and commit
messages.

Thanks,
Rong

> Vishnu - can you check out how this would work with the Thinkpad implementation that you've been working on, please? I think that will be helpful to highlight any design issues.
> 
> Mark

On Thu, Mar 5, 2026, at 7:37 AM, Rong Zhang wrote:
> Hi Mark,
>
> On Wed, 2026-03-04 at 15:05 -0500, Mark Pearson wrote:
>> Hi Rong,
>> 
>> On Fri, Feb 27, 2026, at 2:05 PM, Rong Zhang wrote:
>> > Hi all,
>> > 
>> > 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
>> 
>> Thanks for your work on this.
>> 
>> For the series: As it's a RFC, I'm not bothering with notes on any typo's or grammer stuff.
>> 
>> Overall I think the implementation works and I understand it better from our initial discussions. Thank you for putting this together.
>> 
>> I'm not a huge fan of the term offloaded - I would lean towards just calling it hw_control (or similar). But I see it was used in the ledtrig-netdev driver so I don't feel strongly about this.
>> 
>
> FYI, "hw control" is a historical and internal term. I used it because
> it's used a lot in the documentation to the doc consistent. Otherwise
> "offload(ed)" should be used. See commit 44f0fb8dfe26 ("leds: trigger:
> netdev: rename 'hw_control' sysfs entry to 'offloaded'").
>
> I admit that I was somewhat lost in the terminological soup and there
> may be some room for rephrasing in my documentation and commit
> messages.
>
Fair enough :) I think that overrides my mild preferences.

Mark

Hi Rong and Mark,

On Thu, Mar 5, 2026 at 5:05 AM Mark Pearson <mpearson-lenovo@squebb.ca> wrote:
>
> Hi Rong,
>
> On Fri, Feb 27, 2026, at 2:05 PM, Rong Zhang wrote:
> > Hi all,
> >
> > 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
>
> Thanks for your work on this.
>
> For the series: As it's a RFC, I'm not bothering with notes on any typo's or grammer stuff.
>
> Overall I think the implementation works and I understand it better from our initial discussions. Thank you for putting this together.
>
> I'm not a huge fan of the term offloaded - I would lean towards just calling it hw_control (or similar). But I see it was used in the ledtrig-netdev driver so I don't feel strongly about this.
>
> Vishnu - can you check out how this would work with the Thinkpad implementation that you've been working on, please? I think that will be helpful to highlight any design issues.

I will use this patch and do the changes needed for the Thinkpad and
let you know soon.


>
> Mark



-- 

Regards,

      Vishnu Sankar

On Sat, Feb 28, 2026 at 03:05:57AM +0800, Rong Zhang wrote:
> Hi all,
> 
> 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.

With networking, we consider the hardware as an accelerator for what
the Linux network stack can already do in software. We let the user
configure the network stack however they want it, and then we ask the
hardware, can you accelerate this, so we don't need to do it in
software? It might say -EOPNOTSUPP, so it is left in software. It
might say 0, and we never see the packets, because the hardware is
doing the work. The user is not really aware acceleration is
happening, because they just configure the network stack how they
want, independent of acceleration or not.

For PHY and MAC LEDs it is exactly the same. Generally, the LEDs in
RJ45 connectors, or on the front panel can be turned on/off. The
netdev LED trigger knows if the link is 10M, 100M, 1G etc. It knows if
packets are being transmitted or received. It can make the LEDs show
the link speed, or blink for packet activity, in software, using
simple set_brightness calls. It will also ask the LED, can you
accelerate this? Can you get the state directly from the PHY/MAC? The
LED in my keyboard shift lock will say -EOPNOTSUPP, and the netdev
trigger will keep blinking it in software. The LED driver by the PHY
might say 0, and blink the LED itself. Or it might say -EOPNOTSUPP,
because the vendor decided to only support RX+TX, not only RX.

My preference is this model of accelerating what Linux can already do
should be used everywhere.

You know how many levels the LED supports, so the trigger can easily
implement the steps, 0, 1, 2, 0, 1, 2, based on receiving some event
from somewhere.  You can also accelerate this, you can ask the LED,
can you directly receive the event? -EOPNOTSUPP, keep controlling it
from software. 0, stop driving it from software, the hardware will
accelerate it.

If the system has access to a light sensor, the trigger can also
decide on 0, 1, or 2, based on polling the light sensor every
second. It can then ask the LED, do you have direct access to the
light sensor, can you accelerate this?

The experience from networking is, once you get into the mindset of
the hardware is there to accelerate what Linux can already do, a lot
of problems just disappear. It might you first need to implement the
software version, but once you have that, acceleration is easy.

Does Linux already have a software version of what you want? Can you
accelerate it?

	Andrew

Hi Andrew,

Thanks for your review.

On Tue, 2026-03-10 at 20:57 +0100, Andrew Lunn wrote:
> On Sat, Feb 28, 2026 at 03:05:57AM +0800, Rong Zhang wrote:
> > Hi all,
> > 
> > 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.
> 
> With networking, we consider the hardware as an accelerator for what
> the Linux network stack can already do in software. We let the user
> configure the network stack however they want it, and then we ask the
> hardware, can you accelerate this, so we don't need to do it in
> software? It might say -EOPNOTSUPP, so it is left in software. It
> might say 0, and we never see the packets, because the hardware is
> doing the work. The user is not really aware acceleration is
> happening, because they just configure the network stack how they
> want, independent of acceleration or not.
> 
> For PHY and MAC LEDs it is exactly the same. Generally, the LEDs in
> RJ45 connectors, or on the front panel can be turned on/off. The
> netdev LED trigger knows if the link is 10M, 100M, 1G etc. It knows if
> packets are being transmitted or received. It can make the LEDs show
> the link speed, or blink for packet activity, in software, using
> simple set_brightness calls. It will also ask the LED, can you
> accelerate this? Can you get the state directly from the PHY/MAC? The
> LED in my keyboard shift lock will say -EOPNOTSUPP, and the netdev
> trigger will keep blinking it in software. The LED driver by the PHY
> might say 0, and blink the LED itself. Or it might say -EOPNOTSUPP,
> because the vendor decided to only support RX+TX, not only RX.
> 
> My preference is this model of accelerating what Linux can already do
> should be used everywhere.

Well, there's a thing Linux can't do -- it can't prevent the keyboard
to autonomously activate/deactivate auto brightness after the shortcut
is pressed. The shortcut is processed by EC with zero OS involvement.
That's why brightness_hw_changed exists -- we can't prevent the
hardware to change the brightness on its own, so the best thing we can
do is to notify userspace about the event.

Now the same situation happens on a special brightness control mode
(auto brightness), which is essentially a hw control trigger. Hence I
figured out this series. 

> 
> You know how many levels the LED supports, so the trigger can easily
> implement the steps, 0, 1, 2, 0, 1, 2, based on receiving some event
> from somewhere.  You can also accelerate this, you can ask the LED,
> can you directly receive the event? -EOPNOTSUPP, keep controlling it
> from software. 0, stop driving it from software, the hardware will
> accelerate it.
> 
> If the system has access to a light sensor, 

At least on my device (ThinkBook) I can access the als sensor through
iio bus (driver: hid-sensor-als). But I am unsure if ThinkPad also
exposes it to the OS.

> the trigger can also
> decide on 0, 1, or 2, based on polling the light sensor every
> second. 

I hardly see the advantages of a kernel mode trigger with 1s polling
interval compared to a trigger implemented in userspace, especially
when considering the inconvenience of configuring brightness curves.

AFAIK, KDE already implement a userspace trigger for screen backlight.
So that's also another issue: even if we implement a als-based software
trigger, it can't be used by video backlight and vice versa.

> It can then ask the LED, do you have direct access to the
> light sensor, can you accelerate this?

No, ThinkBook/ThinkPad doesn't report the curve or accept custom curves
so we can't really determine whether a specific curve can be offloaded.

> 
> The experience from networking is, once you get into the mindset of
> the hardware is there to accelerate what Linux can already do, a lot
> of problems just disappear. It might you first need to implement the
> software version, but once you have that, acceleration is easy.
> 
> Does Linux already have a software version of what you want? Can you
> accelerate it?

Such a trigger doesn't exist yet.

If some day in the future we have a als-based software trigger, this
series also provides a migration path thanks to the trigger_may_offload
attribute. Userspace are supposed to query it for the hw control
trigger's name.

Thanks,
Rong

> 
> 	Andrew