[RFC,0/2] ACPI: video: prefer native over vendor

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.

Note this applies on top of my series with fixes for 6.1:
https://lore.kernel.org/linux-acpi/20221104212108.73537-1-hdegoede@redhat.com/

So we need to be a bit careful with merging this to avoid
non trivial conflicts. Assuming that series gets send to Linus
for 6.1 through the pdx86 tree, it might be best for me to
rebase pdx86/for-next on top of the fixes and then this can
(also) be merged through pdx86/for-next without conflicts.

Regards,

Hans

p.s.

Matthew, this should keep your custom coreboot laptop working since
acpi_video_backlight_use_native() will return true there now.


Hans de Goede (2):
  ACPI: video: Simplify __acpi_video_get_backlight_type()
  ACPI: video: prefer native over vendor

 drivers/acpi/video_detect.c | 52 ++++++++++++++-----------------------
 1 file changed, 19 insertions(+), 33 deletions(-)

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

Regards,

Hans

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, even though I'm not
sure if the assumption that the Windows 8 hardware certification
requirements were always followed is not overly optimistic.

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

On Wed, Nov 9, 2022 at 3:38 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> 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.

Fair enough.