Hans de Goede <hdegoede@xxxxxxxxxx> 於 2023年6月8日 週四 上午3:16寫道： > > Hi, > > On 6/7/23 09:47, Matthew Garrett wrote: > > On Wed, Jun 07, 2023 at 03:39:33PM +0800, AceLan Kao wrote: > > > >> What do you think if we unregister backlight devices if the backlight type > >> is larger than the current registered one. > >> Do this check in backlight_device_register() and unregister backlight > >> devices by the order raw(1) > platform(2) > firmware(3) > >> And maybe introduce a sticky bit into the backlight device if the backlight > >> driver doesn't want to be removed. > > > > Hans looked at doing this, but there were some awkward corner cases. > > When we first introduced this functionality, firmware was preferred to > > platform was preferred to raw - but on Intel, at least, this behaviour > > changed with later versions of Windows. I don't think there's a single > > static policy that works, I think you need to pay attention to the hints > > the platform gives you. How does Windows know which interface to use on > > this platform? The simplest solution may actually just be for > > dell-laptop to refuse to register a backlight if the platform claims to > > be Windows 8 or later. > > I like that idea. > > AceLan, I guess that you hit this easy while testing on a (development) > Meteor Lake platform ? > > I have had other/similar reports about Meteor Lake platforms. > > On hw from the last 10 years dell-laptop will not register > its vendor-type backlight class device because > acpi_video_get_backlight_type() will return acpi_backlight_video > there (1) so it does not matter if the GPU driver shows up only > later (2). > > But it seems that on Meteor Lake the ACPI tables will no longer > contain acpi_video backlight control support which causes > acpi_video_get_backlight_type() to return acpi_backlight_vendor (2). > triggering the issue you are seeing. > > Can you give the attached patch a try please ? > > Regards, > > Hans > > > 1) Starting with kernel >= 6.2 acpi_video.c will only register > the /sys/class/backlight/acpi_video# node after a drm/kms drivers > asks it to register it. > > 2) The native GPU driver will tell the drivers/acpi/video_detect.c > code that native backlight control is available changing > the return of acpi_video_get_backlight_type() to native, which > is what loading the native GPU driver first also fixes this issue. Hi Hans, Yes, this patch works for me, thanks. BTW, I encountered this issue on the RPL platform.
