Re: [RFC PATCH 0/1] platform/x86: thinkpad_acpi: Add support for auto keyboard backlight
From: Rong Zhang
Date: Sun Nov 01 2026 - 13:03:34 EST
Hi Qiling,
Thanks for working on this.
On Sun, 2026-11-01 at 18:01 +0800, Qiling Zhu wrote:
> Hi Mark, Ilpo, Rong,
>
> Recent ThinkPads with an ambient light sensor (ALS) support an auto
> mode for the keyboard backlight: the EC picks the backlight level
> according to ambient light. The mode is EC keyboard backlight level 3,
> above the two fixed levels exposed so far, and it is reachable only
> through the Fn+Space shortcut, which is handled entirely by the
> firmware. Userspace can neither select the mode nor observe whether it
> is active.
>
> This series wires the auto mode up as a private hardware control
> trigger, "tpacpi-kbd-auto", on top of the hw control trigger framework
> that recently landed in mainline [1]. With it:
>
> - selecting the trigger writes EC level 3 (auto mode on); writing
> "none" turns the backlight off
> - the trigger state (bracketed in the trigger sysfs attribute, and
> the new trigger_may_offload_to_hw attribute) is the userspace
> view of auto mode; reading brightness returns -ENODATA while
> auto mode is active, per the framework semantics
> - Fn+Space keeps cycling through levels and auto mode as before,
> and the trigger state now follows hardware-initiated transitions
> automatically
>
> This is the thinkpad_acpi counterpart of the ideapad-laptop wiring
> from the same framework series, which is still queued; this patch
> depends only on the LED core parts already in mainline and can be
> applied independently.
>
> For background: the February discussion settled that auto mode must
> not be exposed as a brightness value [2], but no agreement was
> reached back then on how to expose it instead; the hardware control
> trigger approach was established later by the framework series [1].
>
> Tested on a ThinkPad X1 Carbon Gen 14 (MT 21V8) running linux-next
> next-20261030: 61 scripted user-visible assertions covering the
> software paths, the Fn+Space event chain and the unchanged legacy
> behavior, plus manual exercising of both the Fn+Space cycling and
> desktop-environment brightness controls; checkpatch --strict clean.
>
> Deliberately unchanged (details in the commit message):
>
> - max_brightness stays 2; auto mode is not multiplexed into the
> brightness value
> - writing 3 to /proc/acpi/ibm/kbdlight keeps returning -EINVAL
> - module unload still turns the keyboard backlight off
>
> Two open questions, the main reason for the RFC tag:
>
> 1. MLCG returns capability bits in the upper 16 bits; does one of
> them indicate auto mode support? If yes, I would gate trigger
> registration on it. Mark, does the EC documentation say?
> 2. On models without an ALS, the EC behavior when asked for level 3
> via MLCS is unknown to me. If it is undefined rather than
> rejected, optimistic registration would need a rethink (e.g.
> DMI whitelisting).
>
> Rong, happy to rebase this on top of your series or fold it in, if
> you prefer to keep both wirings together.
(+CC Vishnu)
AFAIK, Vishnu is also working on adding the same support using the hw
control trigger framework. Maybe they can answer your questions or
integrate your patch into theirs.
Thanks,
Rong
>
> Comments welcome.
>
> Regards,
> Qiling Zhu
>
> This patch was developed with LLM assistance; I reviewed every design
> decision against the framework sources and validated the behavior on
> real hardware myself.
>
> [1] https://lore.kernel.org/r/20260618-leds-trigger-hw-changed-v2-0-c28c44053cf3@xxxxxxxx/
> [2] https://lore.kernel.org/r/20260203232219.11683-1-vishnuocv@xxxxxxxxx/
>
> Qiling Zhu (1):
> platform/x86: thinkpad_acpi: Add support for auto keyboard backlight
>
> drivers/platform/x86/lenovo/Kconfig | 1 +
> drivers/platform/x86/lenovo/thinkpad_acpi.c | 104 ++++++++++++++++----
> 2 files changed, 88 insertions(+), 17 deletions(-)