在 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