lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <17cc74d6-2e49-4370-ae37-39cddfe67d7d@kernel.org>
Date: Fri, 12 Sep 2025 10:59:21 +0200
From: Hans de Goede <hansg@...nel.org>
To: Zihuan Zhang <zhangzihuan@...inos.cn>
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

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




Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ