From: Hans de Goede <hdegoede@redhat.com>
To: AceLan Kao <acelan.kao@canonical.com>
Cc: "Matthew Garrett" <mjg59@srcf.ucam.org>,
"Pali Rohár" <pali@kernel.org>,
"Mark Gross" <markgross@kernel.org>,
platform-driver-x86@vger.kernel.org,
linux-kernel@vger.kernel.org,
"Kai-Heng Feng" <kai.heng.feng@canonical.com>
Subject: Re: [PATCH] platform/x86: dell-laptop: Add drm module soft dependency
Date: Thu, 8 Jun 2023 11:16:17 +0200 [thread overview]
Message-ID: <f27f0d06-0b18-06bb-cb1f-042527c1ca31@redhat.com> (raw)
In-Reply-To: <CAFv23QmVP4ZFAhAFBSx6ty-4fcQ-u9+uZb0xaD2gCJPCdpPvQg@mail.gmail.com>
Hi AceLan,
On 6/8/23 05:04, AceLan Kao wrote:
> Hans de Goede <hdegoede@redhat.com> 於 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@redhat.com/
Regards,
Hans
next prev parent reply other threads:[~2023-06-08 9:17 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-07 3:43 AceLan Kao
2023-06-07 4:20 ` Matthew Garrett
2023-06-07 5:19 ` AceLan Kao
2023-06-07 5:27 ` Matthew Garrett
2023-06-07 6:13 ` AceLan Kao
2023-06-07 6:23 ` Matthew Garrett
2023-06-07 6:56 ` Pali Rohár
2023-06-07 7:39 ` AceLan Kao
2023-06-07 7:47 ` Matthew Garrett
2023-06-07 19:16 ` Hans de Goede
2023-06-08 3:04 ` AceLan Kao
2023-06-08 9:16 ` Hans de Goede [this message]
2023-06-13 7:30 ` AceLan Kao
2023-06-13 8:54 ` Hans de Goede
2023-06-15 1:53 ` AceLan Kao
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=f27f0d06-0b18-06bb-cb1f-042527c1ca31@redhat.com \
--to=hdegoede@redhat.com \
--cc=acelan.kao@canonical.com \
--cc=kai.heng.feng@canonical.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markgross@kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=pali@kernel.org \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®