Re: [RFC PATCH 0/9] leds: Add support for hw initiated hw control trigger transition

[Rong Zhang]

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