Hans de Goede <hdegoede@xxxxxxxxxx> 於 2023年6月8日 週四 下午5:16寫道： > > Hi AceLan, > > On 6/8/23 05:04, AceLan Kao wrote: > > 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 why 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. > > Thank you for testing. I have updated the commit message > to reflect that this impacts both RPL and MTL platforms > and submitted the fix upstream: > > https://lore.kernel.org/linux-acpi/20230608091258.7963-1-hdegoede@xxxxxxxxxx/ > > Regards, > > Hans > Hi Hans, I got another issue on the same platform. The first issue was that when set to DSC graphics only in the BIOS, I encountered the issue I reported here, dell_laptop creates dell_backlight and then nvidia creates nvidia_0 later. Now, set to hybrid mode in the BIOS, I found I still got 2 backlight interfaces $ ls /sys/class/backlight/ acpi_video0 intel_backlight acpi_video0 is redundant and non-working. Do you think should I set this platform to the dmi quirk? Or is there anything I could try to get rid of this? Thanks.
