Re: [PATCH v1] ACPI: video: Fix missing backlight node creation on

[Hans de Goede <hansg@kernel.org>]

Hi Zihuan,

On 11-Sep-25 9:45 AM,  Zhang wrote:

...

>>  So as you say the issue is that you have no native GPU driver calling
>>  acpi_video_register_backlight().
> 
> I'm very happy that you got it.
> 
>> First of all I assume that there is some sort of builtin GPU on these
>> Lenovo and Inspur machines with Zhaoxin CPUs. Even if the GPU driver
>> is not in the mainline kernel then I assume there is some out of tree
>> driver. Can that driver not call acpi_video_register_backlight() ?
> 
> We are currently working with Zhaoxin on this matter, and we expect to have some results in a few days.
> I will keep you updated once we have progress.

Ok.

...

> Thanks a lot for your patch and for looking into this issue.

You're welcome.

> At the moment, we are still confirming with Zhaoxin whether this behavior is consistent across all their platforms,
> so we are not sure if the special handling should always apply.
> 
> Also, on kernel 5.4 these machines seem to work fine without requiring a native GPU driver, while on 6.6+ the backlight node is missing. 
> Could you please clarify what design change or intention caused this behavioral difference between 5.4 and newer kernels?

The main problem is that on x86 laptops there are too much different
ways to control the backlight:

enum acpi_backlight_type {
        acpi_backlight_undef = -1,
        acpi_backlight_none = 0,
        acpi_backlight_video,
        acpi_backlight_vendor,
        acpi_backlight_native,
        acpi_backlight_nvidia_wmi_ec,
        acpi_backlight_apple_gmux,
        acpi_backlight_dell_uart,
};

With video, vendor and native all 3 being quite normal to have
around on a single laptop.

A long time ago the kernel just used to register all
backlight handlers for which there seemed to be support,
so "ls /sys/class/backlight" would e.g. output:

acpi_video0
intel_backlight
dell_laptop

And then userspace would pick one to use, typically
checking for different backlight types (raw/platform/firmware)
in descending order of preference and picking the first
backlight interface matching the highest preference type.

But even though multiple types may be advertised by
the firmware, they do not necessarily actually work.

So the simple userspace pick based on preferred type
solution did not work on all laptop models and
drivers/acpi/video_detect.c starting growing heuristics
+ quirks to let the kernel pick one and hide the others.

At first for acpi_video# backlights they would get
registered and then later if a native backlight
(e.g. intel_backlight) showed up and the heuristics /
quirks set that should be preferred then the
acpi_video# backlight would be unregistered again.

But this is racy (and ugly) and caused issues for userspace
trying to open the already unregistered backlight.

So the code was changed to delay registering the
acpi_video backlights till after the GPU driver has
loaded so that it is known if native backlight
control is supported or not.

Long story short: The design goal is to only
register 1 backlight handler, so that userspace
does not has to guess and to only register this
once and not do a register + unregister dance
of a potentially unwanted acpi_video backlight.

Regards,

Hans