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