Re: [ibm-acpi-devel] [PATCH] thinkpad_acpi: Add Auto mode support with dynamic max_brightness

From: Rong Zhang

Date: Mon Nov 09 2026 - 11:22:44 EST


Hi Qiling,

On Mon, 2026-11-09 at 11:47 +0800, Qiling Zhu wrote:
> Hi Andrea,
>
> Thanks for the detailed report! I actually noticed that the keyboard
> backlight OSD started working in KDE after applying my patches,
> whereas it hadn't appeared at all before. I didn't look into it
> at the time, so thanks for pointing out the likely reason behind
> this behavior.
>
>
>
> On Sat, Nov 07, 2026 at 11:11:08PM +0800, Rong Zhang wrote:
> > Hi Andrea,
> >
> > ...
> >
> > +CC Qiling
> >
> > Oops, this indeed needs a fix patch for backporting.
> >
> > Qiling, while you series will fix this, it may be better to add a fix
> > patch CC'ing stable@xxxxxxxxxxxxxxx to the very beginning of the series,
> > so that the fix can be easily backported.
> >
>
> Thanks, Rong. I'll split out a minimal, self-contained bug fix
> before the refactoring and feature addition, as you suggested.
>
> I'm still learning the upstream and stable backporting process,
> so I'm wondering whether it would be better to 
>

> submit the fix separately or 
>

This is preferred when:

- you have to postpone the full series for a long time (say, a month or
so)
- the fix is very urgent
- the series is far from being ready, i.e., still needs a lot of review
and revisions

> keep it as the first patch of the next revision.

This is preferred as long as the next revision will soon be available.

> Submitting it separately could get the fix merged and backported
> sooner, though I'm not sure how urgent this particular fix is.

I don't think it's urgent or far from being ready. Thus, as long as you
don't need to postpone the series, you can take the second approach.

Thanks,
Rong

>
> I'd appreciate your guidance on which approach would be more
> appropriate, and I'm happy to follow your suggestion.
>
> >
> > My opinion:
> >
> > If auto mode disables keyboard backlight most of the time, it should
> > report 0. For example, when the auto mode if backed by an ALS sensor, it
> > should disable keyboard backlight most of the time, because most users
> > seldom use the laptop in dark environments.
> >
> > Same for proximity- or activity-based control, as it only illuminates
> > when the user touches the keyboard.
> >
> > The ideapad-laptop driver and Qiling's series have already taken this
> > strategy.
> >
> > Thanks,
> > Rong
> >
>
> I agree that mapping Auto mode to 0 makes more sense. Besides
> the reasons you mentioned, the Fn+Space cycle on my ThinkPad
> is 0 -> 3 -> 1 -> 2 -> 0, as Andrea also observed on the X9.
>
> Mapping Auto (3) to 2 would make the reported brightness jump
> from 0 to 2, then back to 1 and up to 2 again, which seems
> rather misleading, especially since Auto mode does not represent
> the maximum fixed brightness level.
>
> Regards,
> Qiling Zhu