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

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

Hi,

On 12-Sep-25 3:11 AM, Zihuan Zhang wrote:
> 
> 在 2025/9/11 18:38, Hans de Goede 写道:
>> Hi Zihuan,
>>
>> On 11-Sep-25 9:45 AM,  Zhang wrote:

...

>>> 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?

...

>> 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.
> 
> Thank you for the very detailed explanation!

You're welcome.

> One concern, however, is that the current approach seems to assume the presence of a GPU driver, which may not always be the case. Would it be possible to consider a more generic fallback?

Well x86/ACPI laptops without a GPU are not really
something which exists anymore. A GPU is a must have
for a good user experience with modern OS-es.

And now a days we have in kernel drivers for all main
GPU vendors.

This new way of doing things has been around for
quite a while now without causing problems.

To me it seems the issue here is that GPU driver
for the (CPU/chipset integrated?) GPU on these
laptops is missing from the mainline kernel.

There are many good reasons to have a GPU driver
in the mainline kernel. So ideally this would be
fixed by mainlining the GPU driver for these
laptops.

> For example, if no GPU driver is available, we could still register the acpi_video backlight node.

The problem is how do we know that no GPU driver is
available ?

Note that the DMI quirk check happens before
setting *auto_detect = true; So besides doing
a CPU check another option would be to do
a DMI check. DMI checks can use substring matches
(they do a strstr match by default) so if there
is some common DMI string (part) on the affected
laptops which is not found on other laptops
then we can also just DMI quirk these.

As long as it does not end up being an ever
growing list then adding a bunch of DMI entries
for this should be fine.

> 
>  This way we can at least ensure that a backlight device is exposed to userspace instead of leaving the system without any backlight control interface.
> 
> Do you think such a fallback could be a reasonable option?

The problem is the kernel does not know if there
is a GPU driver for the GPU. If it is e.g. the
nvidia binary driver it may need to first get
build by dkms, so even using say a timeout is
tricky and a timeout is always racy so I would
like to avoid that.

My preferred way of handling this would be:

1. There must be a GPU driver for these laptops somewhere?
Even if out of tree using a laptop without a GPU these days
just does not give a good user experience. So fix the GPU
driver to call acpi_video_register_backlight().

Note acpi_video_register_backlight() is deliberately exported
without requiring the consuming out of tree kernel module to
be GPL to allow this.

Other options would be:

2. Add some special heuristics for Zhaoxin CPUs,
the kernel already has a CPUID match mechanism for
things like this. This could potentially be combined
with a DMI system-vendor check to only do this special
case handling on e.g. Lenovo and Inspur laptops.

3. Instead of adding the CPU-id based special case
just outright use DMI quirks. In this case lets try
to use substring matches to cover multiple models
with a single entry so as to not grow the quirk
table too much.

Regards,

Hans