Re: [RFC PATCH 1/9] leds: Load trigger modules on-demand if used as hw control trigger

[Rong Zhang]

Hi Andrew,

On Wed, 2026-03-11 at 19:44 +0100, Andrew Lunn wrote:
> > While I agree that the current policy makes its own sense and works
> > well on most devices, it leads to out-of-sync software states on recent
> > laptops.
> > 
> > When the LED's hardware autonomously put itself into hw control mode,
> > it is offloaded to the hardware per se -- we *can't* prevent this from
> > happening.
> 
> If you cannot control the hardware, why are you trying to control the
> hardware?

We can control the hardware. We can set brightness, enable or disable
auto mode freely.

We just can't prevent the EC from responding to the Fn+Space shortcut.
So it's essentially user's choice to switch to the hw control trigger
and make it offloaded to hardware (sorry if my cover letter and replies
didn't express this well).

> 
> > The series is about how to update software state to reflect the
> > hardware state change. Blindly keeping the software state despite the
> > hardware state is hardly meaningful and makes software out-of-sync.
> 
> Since you cannot control the hardware, just don't register the
> LED. That gives a truer picture. Something else than Linux is
> controlling it.

As my previous reply said, it's common that an LED driver can't prevent
hardware from changing its state autonomously. Prior to the
introduction of auto brightness mode, brightness_hw_changed is enough
to handle this. The issue only emerges when recent models start to
provide an auto brightness mode based on the ALS sensor.

> 
> Do you get a notification when that something else takes control? ACPI
> event or something?

Yes, and the event is used in the series to change software state.

> If you do, can just re-impose the software state
> back on the hardware.
> 
> > As shown above, this series doesn't change the LED's hardware state and
> > it just updates the software state to notify user about that. If you'd
> > like to enforce software state's priority, we would have to explicitly
> > undo the hardware state change immediately after the LED's hardware has
> > autonomously activated/deactivated hw control mode.
> 
> Yes, if you decide Linux is driving the hardware, the Linux state
> should always be imposed back on the hardware. Just consider it flaky
> hardware which needs hitting over the head every so often to make
> work.

I don't think we should re-impose the software state back on the
hardware. We never do this for brightness and decided to introduce
brightness_hw_changed. That's should also applies to hw control
trigger.

Moreover, re-imposing the software state breaks the shortcut by
changing the brightness cycle from

  1 => 2 => 0 => auto => 1 ...

to

  1 => 2 => 0 => (auto => 0) => (auto => 0) => ...

> 
> But maybe we should take a step back here. What are your real use
> cases here? Why do you want Linux to control this hardware, when
> something else already is controlling it? Is /sys/class/led even the
> right API? That will depend on what your use cases are.

FYI, desktop environments (e.g., GNOME, KDE) can control the backlight
brightness of keyboards through sliders and heavily depend on
brightness_hw_changed to update the sliders and display OSD once the
shortcut is pressed. This matches the experience on Windows, where
utilities from manufacturers provide brightness sliders and display
OSD.

The shortcut itself doesn't send any keyboard events to the OS. Ths OS
only sees an event notifying that keyboard backlight has changed. We
want the event of turning on/off auto brightness reaches userspace like
what brightness_hw_changed does for brightness changes. Also we don't
want the auto brightness mode to have interference to other triggers or
the brightness attribute and vice versa, so making it a hw control
trigger is an approach to make them mutually exclusive.

Thanks,
Rong

> 
> 	Andrew