From: Hans de Goede <hdegoede@redhat.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Matthew Garrett <mjg59@srcf.ucam.org>,
Len Brown <lenb@kernel.org>,
linux-acpi@vger.kernel.org
Subject: Re: [RFC 0/2] ACPI: video: prefer native over vendor
Date: Wed, 9 Nov 2022 15:37:53 +0100 [thread overview]
Message-ID: <dd95fc25-6b46-b244-2ca6-954ba5ba129c@redhat.com> (raw)
In-Reply-To: <CAJZ5v0hJx4GX-0Ny17LgbBZGXRDG+bnfmhDQeKpBDusQ+j1g6A@mail.gmail.com>
Hi,
On 11/9/22 14:51, Rafael J. Wysocki wrote:
> On Sat, Nov 5, 2022 at 4:17 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi,
>>
>> On 11/5/22 15:52, Hans de Goede wrote:
>>> Hi Rafael, Matthew,
>>>
>>> Here is a second attempt at always registering only a single
>>> /sys/class/backlight device per panel.
>>>
>>> This first round of testing has shown that native works well even on
>>> systems so old that the don't have acpi_video backlight control support.
>>>
>>> This patch series makes native be preferred over vendor, which should
>>> avoid the problems seen with the 6.1 changes before the fixes.
>>>
>>> ATM there is one known model where this will cause a regression,
>>> the Sony Vaio PCG-FRV3 from 2003. I plan to add a DMI quirk for that
>>> in the next version of this series, but I'm waiting for some more
>>> testing (to check that the vendor interface does actually work) first.
>>>
>>> I will also do another blogpost, focussing on asking users to see
>>> if they have a laptop which provides a combination of vendor + native
>>> backlight interfaces, which may be impacted by this series. This is
>>> the main reason why this is a RFC for now.
>>
>> The blogpost requesting testing of laptops with a combination
>> of vendor + native backlight interfaces can be found here:
>>
>> https://hansdegoede.dreamwidth.org/27024.html
>
> The patches in this series look reasonable to me,
Thanks.
> even though I'm not
> sure if the assumption that the Windows 8 hardware certification
> requirements were always followed is not overly optimistic.
After the second patch in the series the only remaining
prefer_native_over_acpi_video() and thus the only acpi_osi_is_win8()
call is guarded by a (video_caps & ACPI_VIDEO_BACKLIGHT) check as before:
if ((video_caps & ACPI_VIDEO_BACKLIGHT) &&
!(native_available && prefer_native_over_acpi_video()))
return acpi_backlight_video;
So even if the assumption is wrong, there is no behavior change
other then the intended behavior change already caused by the second
patch.
The last part of __acpi_video_get_backlight_type() which contains
the basic (non special case) heuristics looks like this after
this series:
/* Use ACPI video if available, except when native should be preferred. */
if ((video_caps & ACPI_VIDEO_BACKLIGHT) &&
!(native_available && prefer_native_over_acpi_video()))
return acpi_backlight_video;
/* Use native if available */
if (native_available)
return acpi_backlight_native;
/* No ACPI video/native (old hw), use vendor specific fw methods. */
return acpi_backlight_vendor;
Which is also a bit more KISS / easier to follow then before and
I hope that this will work well.
Regards,
Hans
next prev parent reply other threads:[~2022-11-09 14:38 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-05 14:52 [RFC 0/2] ACPI: video: prefer native over vendor Hans de Goede
2022-11-05 14:52 ` [RFC 1/2] ACPI: video: Simplify __acpi_video_get_backlight_type() Hans de Goede
2022-11-05 14:52 ` [RFC 2/2] ACPI: video: Prefer native over vendor Hans de Goede
2022-11-05 15:17 ` [RFC 0/2] ACPI: video: prefer " Hans de Goede
2022-11-09 13:51 ` Rafael J. Wysocki
2022-11-09 14:37 ` Hans de Goede [this message]
2022-11-09 14:41 ` Rafael J. Wysocki
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=dd95fc25-6b46-b244-2ca6-954ba5ba129c@redhat.com \
--to=hdegoede@redhat.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=mjg59@srcf.ucam.org \
--cc=rafael@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