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 22:29 +0100, Andrew Lunn wrote:
> > 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).
> 
> Do you have any control over the EC?
> 
> You have a two bosses dilemma. You need to eliminate one of the
> bosses. Either the EC controls the LED, or Linux does. Having both
> controlling it is just going to work out badly.

I agree that the manufacturers designed the interface poorly :-/

I am not affiliated with any laptop manufacturers so I am just speaking
for myself:

IMO the real boss is the user. Both the shortcut (Fn+Space) and the
ACPI interface are just "message channels" for the EC to know about the
user's choice.

Being able to press such a shortcut always implies that the user is
physically in front of the device. In this case it no longer about
whether Linux or the EC controls the LED, but both should respect
user's choice. That was why brightness_hw_changed was introduced to
respect user's choice and pass it to the userspace. So far there has
been ~10 drivers utilizing the brightness_hw_changed interface.

> 
> > 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 have a software driven brightness mode based on an ALS? What
> API do you use to control this? Can you use that API, and accelerate
> it?

All devices I've seen implement an EC driven auto brightness mode based
on an ALS.

@Mark, do you know any device implementing a software driven auto
brightness mode?

> 
> > 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.
> 
> Hold up. Terminology problem. I'm a networking guy, i know networking
> terms. By slider, do you mean a software scroll bar sort of thing? 

Yes. See
https://blogs.kde.org/2024/09/04/brightness-controls-for-all-your-displays/

(it was about display backlight but it also showed the keyboard one in
the same image)

> I'm
> an XFCE users. I can control the display backlight with a slider on
> the battery charge applet. And i can use Fn F4/F5. I've not seen a
> software scroll bar for the keyboard backlight, but i think
> <CTRL><SPC> allows me to change the keyboard backlight.
> 
> So we have a slider, which is purely software, Linux. And we have key
> presses, which you are calling shortcut, which the EC acts on, and
> might tell Linux, maybe, but not about the key press, but the action
> the EC took because of the key press.

"might tell", "maybe"

It always tells the OS that the state of keyboard backlight has
changed.

> 
> You have some API to the EC to ask it nicely to act on the software
> slide, but it is the EC which really controls the LED, not Linux.
> 
> To me a Linux LED is a poor fit for what you want, and i think a
> trigger is even worse. The problems you have are because the
> LED+trigger model, plus using the hardware for acceleration, does not
> fit with the EC actually controlling the hardware.
> 
> I would suggest you look at the API the EC exports and find a better
> model for it.

An LED classdev may be unable to perfectly fit this, but nothing is
perfect and so far it's the best thing we have. It's a fortunate to
have the LED subsystem. Windows, without a similar interface, ends up
being filled with disgusting software pre-installed by the
manufacturer.

IMO the presence of brightness_hw_changed proves that an LED classdev,
as long as appropriate interfaces are provided, can work well with such
hardware. And I don't think there is too much difference between EC
setting a static brightness value due to a shortcut being pressed and
EC turning on/off the auto brightness mode due to the same shortcut --
if we can handle the former well, we can also implement a similar
mechanism for the latter.


Do you have any recommendations for a "better model"?

Did you mean do not register LED classdevs at all? This isn't really
viable and will break userspace. Some drivers has been using LED
classdevs for keyboard backlight for over a decade. And many
`*::kbd_backlight' LEDs rely on brightness_hw_changed, so it's very
common that we can't take 100% control over EC. LED classdevs and EC-
controlled keyboard backlight have lived in harmony for a long time.

If we still register the keybaord backlight as an LED classdev but use
a custom attribute to report/set the auto brightness mode. IMO this is
even uglier than LED+trigger, as writing to such a non-brightness
attribute will interfere with the brightness attribute and the active
trigger and vice versa. Even if we rule out the EC's action, such
interference still exists as long as users use the attribute.


As for the software-vs-hardware priority issue, how about adding an
attribute "hw_change_policy" so that users can select if the software
state should be always reimposed to hardware?

- If the policy is reimpose, calling
led_trigger_notify_hw_control_changed() or
led_classdev_notify_brightness_hw_changed() results in the software
state to be reimposed to the hardware and no event should reach
userspace.

- Otherwise calling led_trigger_notify_hw_control_changed() or
led_classdev_notify_brightness_hw_changed() updates software state and
notifies userspace.

Thanks,
Rong

> 
> 	Andrew