Message-ID: <365c42f5-56a1-4a2c-9244-7943c3600fa2@kylinos.cn>
Date: Fri, 12 Sep 2025 09:11:04 +0800
From: Zihuan Zhang <zhangzihuan@...inos.cn>
To: Hans de Goede <hansg@...nel.org>
Cc: lenb@...nel.org, linux-acpi@...r.kernel.org,
 linux-kernel@...r.kernel.org, mario.limonciello@....com, rafael@...nel.org,
 stable@...r.kernel.org
Subject: Re: [PATCH v1] ACPI: video: Fix missing backlight node creation on


在 2025/9/11 18:38, Hans de Goede 写道:
> 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.


Thank you for the very detailed explanation!

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?


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

  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?

Thanks again for your insights!


> Regards,
>
> Hans
>
>
>

Powered by blists - more mailing lists