| Message ID | 20220825143726.269890-3-hdegoede@redhat.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | drm/kms: Stop registering multiple /sys/class/backlight devs for a single display | expand |
25.08.2022 17:36, Hans de Goede пишет: > Before this commit when we want userspace to use the acpi_video backlight > device we register both the GPU's native backlight device and acpi_video's > firmware acpi_video# backlight device. This relies on userspace preferring > firmware type backlight devices over native ones. > > Registering 2 backlight devices for a single display really is > undesirable, don't register the GPU's native backlight device when > another backlight device should be used. > > Changes in v2: > - Use drm_info(drm_dev, ...) for log messages > > Reviewed-by: Jani Nikula <jani.nikula@intel.com> > Signed-off-by: Hans de Goede <hdegoede@redhat.com> > --- > drivers/gpu/drm/i915/display/intel_backlight.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c b/drivers/gpu/drm/i915/display/intel_backlight.c > index 681ebcda97ad..03c7966f68d6 100644 > --- a/drivers/gpu/drm/i915/display/intel_backlight.c > +++ b/drivers/gpu/drm/i915/display/intel_backlight.c > @@ -8,6 +8,8 @@ > #include <linux/pwm.h> > #include <linux/string_helpers.h> > > +#include <acpi/video.h> > + > #include "intel_backlight.h" > #include "intel_backlight_regs.h" > #include "intel_connector.h" > @@ -952,6 +954,11 @@ int intel_backlight_device_register(struct intel_connector *connector) > > WARN_ON(panel->backlight.max == 0); > > + if (!acpi_video_backlight_use_native()) { > + drm_info(&i915->drm, "Skipping intel_backlight registration\n"); > + return 0; > + } > + > memset(&props, 0, sizeof(props)); > props.type = BACKLIGHT_RAW; > This breaks backlight on Acer Chromebook Spin 713 because backlight isn't registered anymore. Any ideas how to fix it?
Hi Dmitry, On 9/26/22 01:39, Dmitry Osipenko wrote: > 25.08.2022 17:36, Hans de Goede пишет: >> Before this commit when we want userspace to use the acpi_video backlight >> device we register both the GPU's native backlight device and acpi_video's >> firmware acpi_video# backlight device. This relies on userspace preferring >> firmware type backlight devices over native ones. >> >> Registering 2 backlight devices for a single display really is >> undesirable, don't register the GPU's native backlight device when >> another backlight device should be used. >> >> Changes in v2: >> - Use drm_info(drm_dev, ...) for log messages >> >> Reviewed-by: Jani Nikula <jani.nikula@intel.com> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> drivers/gpu/drm/i915/display/intel_backlight.c | 7 +++++++ >> 1 file changed, 7 insertions(+) >> >> diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c b/drivers/gpu/drm/i915/display/intel_backlight.c >> index 681ebcda97ad..03c7966f68d6 100644 >> --- a/drivers/gpu/drm/i915/display/intel_backlight.c >> +++ b/drivers/gpu/drm/i915/display/intel_backlight.c >> @@ -8,6 +8,8 @@ >> #include <linux/pwm.h> >> #include <linux/string_helpers.h> >> >> +#include <acpi/video.h> >> + >> #include "intel_backlight.h" >> #include "intel_backlight_regs.h" >> #include "intel_connector.h" >> @@ -952,6 +954,11 @@ int intel_backlight_device_register(struct intel_connector *connector) >> >> WARN_ON(panel->backlight.max == 0); >> >> + if (!acpi_video_backlight_use_native()) { >> + drm_info(&i915->drm, "Skipping intel_backlight registration\n"); >> + return 0; >> + } >> + >> memset(&props, 0, sizeof(props)); >> props.type = BACKLIGHT_RAW; >> > > This breaks backlight on Acer Chromebook Spin 713 because backlight > isn't registered anymore. Any ideas how to fix it? Thank you for reporting this. Let me start with some background info on this change: As you may have noticed sometimes on laptops there are multiple backlights registered under /sys/class/backlight and we just let userspace figure out which one to use, which is quite bad. This patch is part of a series fixing this, this is also preparation for adding a new display brightness control API where the brightness is a property on the drm_connector object for the panel/display, which of course requires the kernel to know which backlight control method to use. If you are want to know more about the new userspace API see: https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86d2e@redhat.com/ What this series does is on x86/ACPI platforms make all the possible /sys/class/backlight providers call: acpi_video_get_backlight_type() (acpi_video_backlight_use_native() is a special wrapper) and only if that returns their type then have them register their backlight device. So to fix this we need to make acpi_video_get_backlight_type() return native on the Acer Chromebook Spin 713. The heuristics used in acpi_video_get_backlight_type() is explained by comments in the function: /* * The below heuristics / detection steps are in order of descending * presedence. The commandline takes presedence over anything else. */ /* DMI quirks override any autodetection. */ /* Special cases such as nvidia_wmi_ec and apple gmux. */ None of these apply here, so we end up in the core of this function: /* On systems with ACPI video use either native or ACPI video. */ if (video_caps & ACPI_VIDEO_BACKLIGHT) { /* * Windows 8 and newer no longer use the ACPI video interface, * so it often does not work. If the ACPI tables are written * for win8 and native brightness ctl is available, use that. * * The native check deliberately is inside the if acpi-video * block on older devices without acpi-video support native * is usually not the best choice. */ if (acpi_osi_is_win8() && native_available) return acpi_backlight_native; else return acpi_backlight_video; } /* No ACPI video (old hw), use vendor specific fw methods. */ return acpi_backlight_vendor; The acpi_video_backlight_use_native() wrappers causes native_available to be true, so one or both of these 2 conditions fail: 1. if (video_caps & ACPI_VIDEO_BACKLIGHT) 2. if (acpi_osi_is_win8()) I assume that 2. will actually likely fail on quite a few chromebooks. So to fix this you could do something like this: diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 0d9064a9804c..660ea46fbee8 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -75,6 +75,12 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv) return AE_OK; } +static bool is_chromebook(void) +{ + // FIXME return true when running under ChromeOS (coreboot) firmware + return false; +} + /* This depends on ACPI_WMI which is X86 only */ #ifdef CONFIG_X86 static bool nvidia_wmi_ec_supported(void) @@ -724,7 +730,7 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native) * block on older devices without acpi-video support native * is usually not the best choice. */ - if (acpi_osi_is_win8() && native_available) + if (native_available && (acpi_osi_is_win8() || is_chromebook())) return acpi_backlight_native; else return acpi_backlight_video; The ACPI video bus is a pretty standard thing (and part of the ACPI standard), still I would not be surprised if it is missing from the ACPI tables on some Chromebooks, so a slightly bigger hammer approach would be: diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 0d9064a9804c..ff950be472a7 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -75,6 +75,12 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv) return AE_OK; } +static bool is_chromeos_firmware(void) +{ + // FIXME return true when running under ChromeOS (coreboot) firmware + return false; +} + /* This depends on ACPI_WMI which is X86 only */ #ifdef CONFIG_X86 static bool nvidia_wmi_ec_supported(void) @@ -713,6 +719,10 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native) if (apple_gmux_present()) return acpi_backlight_apple_gmux; + /* On Chromebooks always use native if available */ + if (is_chromeos_firmware() && native_available) + return acpi_backlight_native; + /* On systems with ACPI video use either native or ACPI video. */ if (video_caps & ACPI_VIDEO_BACKLIGHT) { /* I assume you are more familiar with Chromebooks ACPI tables (or at least are better capable to sample a couple of them) so I will leave which approach to take is best up to you. Regards, Hans
On Tue, Sep 27, 2022 at 01:04:52PM +0200, Hans de Goede wrote: > So to fix this we need to make acpi_video_get_backlight_type() > return native on the Acer Chromebook Spin 713. Isn't the issue broader than that? Unless the platform is Windows 8 or later, we'll *always* (outside of some corner cases) return acpi_backlight_vendor if there's no ACPI video interface. This is broken for any platform that implements ACPI but relies on native video control, which is going to include a range of Coreboot platforms, not just Chromebooks. I think for this to work correctly you need to have the infrastructure be aware of whether or not a vendor interface exists, which means having to handle cleanup if a vendor-specific module gets loaded later.
Hi, On 10/24/22 22:30, Matthew Garrett wrote: > On Tue, Sep 27, 2022 at 01:04:52PM +0200, Hans de Goede wrote: > >> So to fix this we need to make acpi_video_get_backlight_type() >> return native on the Acer Chromebook Spin 713. > > Isn't the issue broader than that? Unless the platform is Windows 8 or > later, we'll *always* (outside of some corner cases) return > acpi_backlight_vendor if there's no ACPI video interface. This is broken > for any platform that implements ACPI but relies on native video > control, which is going to include a range of Coreboot platforms, not > just Chromebooks. That is a valid point, but keep in mind that this is only used on ACPI platforms and then only on devices with a builtin LCD panel and then only by GPU drivers which actually call acpi_video_get_backlight_type(), so e.g. not by all the ARM specific display drivers. So I believe that Chromebooks quite likely are the only devices with this issue. We could do something like the patch which I have pasted at the end of this email, but as its commit message notes there is a real good chance this will cause regressions on some laptops. So if we ever decide to go with something like the patch below, I think we should at a minimum wait for the next cycle with that, because 6.1 already significantly reworks the ACPI backlight detect handling and I don't want to throw this into the mix on top of those changes. > I think for this to work correctly you need to have > the infrastructure be aware of whether or not a vendor interface exists, > which means having to handle cleanup if a vendor-specific module gets > loaded later. Getting rid of the whole ping-ponging of which backlight drivers get loaded during boot was actually one of the goals of the rework which landed in 6.1 this actually allowed us to remove some quirks because some hw/firmware did not like us changing our mind and switching backlight interfaces after first poking another one. So we definitely don't want to go back to the ping-pong thing. Regards, Hans >From 67ee5d7163e33e65dca06887befd0639b0345883 Mon Sep 17 00:00:00 2001 From: Hans de Goede <hdegoede@redhat.com> Date: Tue, 25 Oct 2022 20:38:56 +0200 Subject: [PATCH] ACPI: video: Simplify __acpi_video_get_backlight_type() Simplify __acpi_video_get_backlight_type() removing a nested if which makes the flow harder to follow. Note this will cause a behavior change on devices which do not have ACPI video support but do have both a vendor and native backlight driver available. This change will cause these devices to switch from vendor to native. This may not be desirable in all cases, this is likely to happen on significantly older laptops, where there very well might be cases where the native driver does not work because the backlight is controlled by the EC. This removes the need for the special handling of Chromebooks, these will now hit the if (native_available) return acpi_backlight_native; path. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/acpi/video_detect.c | 36 +++++++++++------------------------- 1 file changed, 11 insertions(+), 25 deletions(-) diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c index 9cd8797d12bb..9bd85b159e02 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -668,11 +668,6 @@ static const struct dmi_system_id video_detect_dmi_table[] = { { }, }; -static bool google_cros_ec_present(void) -{ - return acpi_dev_found("GOOG0004"); -} - /* * Determine which type of backlight interface to use on this system, * First check cmdline, then dmi quirks, then do autodetect. @@ -718,30 +713,21 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native) if (apple_gmux_present()) return acpi_backlight_apple_gmux; - /* On systems with ACPI video use either native or ACPI video. */ - if (video_caps & ACPI_VIDEO_BACKLIGHT) { - /* - * Windows 8 and newer no longer use the ACPI video interface, - * so it often does not work. If the ACPI tables are written - * for win8 and native brightness ctl is available, use that. - * - * The native check deliberately is inside the if acpi-video - * block on older devices without acpi-video support native - * is usually not the best choice. - */ - if (acpi_osi_is_win8() && native_available) - return acpi_backlight_native; - else - return acpi_backlight_video; - } - /* - * Chromebooks that don't have backlight handle in ACPI table - * are supposed to use native backlight if it's available. + * Pre Windows 8, Windows uses ACPI video, so prefer that over native + * on pre-win8 systems (Windows 8+ no longer uses ACPI video). */ - if (google_cros_ec_present() && native_available) + if ((video_caps & ACPI_VIDEO_BACKLIGHT) && !acpi_osi_is_win8()) + return acpi_backlight_video; + + /* Use native backlight control if available */ + if (native_available) return acpi_backlight_native; + /* Use the ACPI video interface if available */ + if (video_caps & ACPI_VIDEO_BACKLIGHT) + return acpi_backlight_video; + /* No ACPI video (old hw), use vendor specific fw methods. */ return acpi_backlight_vendor; }
On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote: > That is a valid point, but keep in mind that this is only used on ACPI > platforms and then only on devices with a builtin LCD panel and then > only by GPU drivers which actually call acpi_video_get_backlight_type(), > so e.g. not by all the ARM specific display drivers. > > So I believe that Chromebooks quite likely are the only devices with > this issue. My laptop is, uh, weird, but it falls into this category. > > I think for this to work correctly you need to have > > the infrastructure be aware of whether or not a vendor interface exists, > > which means having to handle cleanup if a vendor-specific module gets > > loaded later. > > Getting rid of the whole ping-ponging of which backlight drivers > get loaded during boot was actually one of the goals of the rework > which landed in 6.1 this actually allowed us to remove some quirks > because some hw/firmware did not like us changing our mind and > switching backlight interfaces after first poking another one. > So we definitely don't want to go back to the ping-pong thing. Defaulting to native but then having a vendor driver be able to disable native drivers seems easiest? It shouldn't be a regression over the previous state of affairs since both drivers were being loaded already.
Hi Matthew, On 10/25/22 21:32, Matthew Garrett wrote: > On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote: > >> That is a valid point, but keep in mind that this is only used on ACPI >> platforms and then only on devices with a builtin LCD panel and then >> only by GPU drivers which actually call acpi_video_get_backlight_type(), >> so e.g. not by all the ARM specific display drivers. >> >> So I believe that Chromebooks quite likely are the only devices with >> this issue. > > My laptop is, uh, weird, but it falls into this category. > >>> I think for this to work correctly you need to have >>> the infrastructure be aware of whether or not a vendor interface exists, >>> which means having to handle cleanup if a vendor-specific module gets >>> loaded later. >> >> Getting rid of the whole ping-ponging of which backlight drivers >> get loaded during boot was actually one of the goals of the rework >> which landed in 6.1 this actually allowed us to remove some quirks >> because some hw/firmware did not like us changing our mind and >> switching backlight interfaces after first poking another one. >> So we definitely don't want to go back to the ping-pong thing. > > Defaulting to native but then having a vendor driver be able to disable > native drivers seems easiest? It shouldn't be a regression over the > previous state of affairs since both drivers were being loaded already. Part of the reason for the ACPI backlight detect refactor is because of a planned new backlight uAPI where the brightness control becomes a property on the drm connector object, for a RFC including the rationale behind this planned uAPI change see: https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86d2e@redhat.com/ These plans require that there is only 1 backlight device registered (per panel). Having the native driver come and then go and be replaced with the vendor driver would also be quite inconvenient for these planned changes. As such I would rather find a solution for your "weird" laptop so that acpi_video_get_backlight_type() just always returns vendor there. Note that drivers/acpi/video_detect.c already has a DMI quirk tables for models where the heuristics from acpi_video_get_backlight_type() don't work. In general we (mostly me) try to make it so that the heuristics work on most models, to avoid needing to add every model under the sun to the DMI quirk table, but if your laptop is somehow special then adding a DMI quirk for it should be fine ? Can you perhaps explain a bit in what way your laptop is weird ? Note that technically if the native backlight does not work, then the GPU driver really should not even try to register it. But sometimes the video-bios-tables claim the backlight pwm input is attached to the GPU while it is not and things have evolved in such a way that the DMI quirks for that live in acpi/video_detect.c rather then in the GPU driver. Regards, Hans
On 10/25/2022 15:25, Hans de Goede wrote: > Hi Matthew, > > On 10/25/22 21:32, Matthew Garrett wrote: >> On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote: >> >>> That is a valid point, but keep in mind that this is only used on ACPI >>> platforms and then only on devices with a builtin LCD panel and then >>> only by GPU drivers which actually call acpi_video_get_backlight_type(), >>> so e.g. not by all the ARM specific display drivers. >>> >>> So I believe that Chromebooks quite likely are the only devices with >>> this issue. >> >> My laptop is, uh, weird, but it falls into this category. >> >>>> I think for this to work correctly you need to have >>>> the infrastructure be aware of whether or not a vendor interface exists, >>>> which means having to handle cleanup if a vendor-specific module gets >>>> loaded later. >>> >>> Getting rid of the whole ping-ponging of which backlight drivers >>> get loaded during boot was actually one of the goals of the rework >>> which landed in 6.1 this actually allowed us to remove some quirks >>> because some hw/firmware did not like us changing our mind and >>> switching backlight interfaces after first poking another one. >>> So we definitely don't want to go back to the ping-pong thing. >> >> Defaulting to native but then having a vendor driver be able to disable >> native drivers seems easiest? It shouldn't be a regression over the >> previous state of affairs since both drivers were being loaded already. > > Part of the reason for the ACPI backlight detect refactor is > because of a planned new backlight uAPI where the brightness > control becomes a property on the drm connector object, for a > RFC including the rationale behind this planned uAPI change see: > https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fdri-devel%2Fb61d3eeb-6213-afac-2e70-7b9791c86d2e%40redhat.com%2F&data=05%7C01%7Cmario.limonciello%40amd.com%7C6380e44c87e447eedc3f08dab6c7180a%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638023263541559113%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=K4oMmVl51kT9V%2B4GAdx%2FS7tXWHPKyFe5WXZzC3CPeOU%3D&reserved=0 > > These plans require that there is only 1 backlight device > registered (per panel). > > Having the native driver come and then go and be replaced > with the vendor driver would also be quite inconvenient > for these planned changes. > > As such I would rather find a solution for your "weird" > laptop so that acpi_video_get_backlight_type() just always > returns vendor there. What exactly is this "weird" laptop? Is it something running coreboot that doesn't "normally" ship with coreboot perhaps? If that's the category it falls in, I think what we really need is something to land in coreboot source for indicating how it should behave and then also a change in the kernel to react to that. That's a similar approach to what was used fore the chromebook laptops that run coreboot. > > Note that drivers/acpi/video_detect.c already has a DMI > quirk tables for models where the heuristics from > acpi_video_get_backlight_type() don't work. In general > we (mostly me) try to make it so that the heuristics > work on most models, to avoid needing to add every model > under the sun to the DMI quirk table, but if your laptop > is somehow special then adding a DMI quirk for it should > be fine ? > > Can you perhaps explain a bit in what way your laptop > is weird ? > > Note that technically if the native backlight does not work, > then the GPU driver really should not even try to register > it. But sometimes the video-bios-tables claim the backlight > pwm input is attached to the GPU while it is not and things > have evolved in such a way that the DMI quirks for that > live in acpi/video_detect.c rather then in the GPU driver. > > Regards, > > Hans >
Hi (again), On 10/25/22 22:25, Hans de Goede wrote: > Hi Matthew, > > On 10/25/22 21:32, Matthew Garrett wrote: >> On Tue, Oct 25, 2022 at 08:50:54PM +0200, Hans de Goede wrote: >> >>> That is a valid point, but keep in mind that this is only used on ACPI >>> platforms and then only on devices with a builtin LCD panel and then >>> only by GPU drivers which actually call acpi_video_get_backlight_type(), >>> so e.g. not by all the ARM specific display drivers. >>> >>> So I believe that Chromebooks quite likely are the only devices with >>> this issue. >> >> My laptop is, uh, weird, but it falls into this category. >> >>>> I think for this to work correctly you need to have >>>> the infrastructure be aware of whether or not a vendor interface exists, >>>> which means having to handle cleanup if a vendor-specific module gets >>>> loaded later. >>> >>> Getting rid of the whole ping-ponging of which backlight drivers >>> get loaded during boot was actually one of the goals of the rework >>> which landed in 6.1 this actually allowed us to remove some quirks >>> because some hw/firmware did not like us changing our mind and >>> switching backlight interfaces after first poking another one. >>> So we definitely don't want to go back to the ping-pong thing. >> >> Defaulting to native but then having a vendor driver be able to disable >> native drivers seems easiest? It shouldn't be a regression over the >> previous state of affairs since both drivers were being loaded already. > > Part of the reason for the ACPI backlight detect refactor is > because of a planned new backlight uAPI where the brightness > control becomes a property on the drm connector object, for a > RFC including the rationale behind this planned uAPI change see: > https://lore.kernel.org/dri-devel/b61d3eeb-6213-afac-2e70-7b9791c86d2e@redhat.com/ > > These plans require that there is only 1 backlight device > registered (per panel). > > Having the native driver come and then go and be replaced > with the vendor driver would also be quite inconvenient > for these planned changes. > > As such I would rather find a solution for your "weird" > laptop so that acpi_video_get_backlight_type() just always > returns vendor there. I just realized that your have vendor driver unregister the native one is suggested as an alternative for the new behavior where the i915 driver no longer registers its native backlight in cases where acpi_video_get_backlight_type() does not return native, and that you probably actually want the native backlight device, right ? So the above should read: "so that acpi_video_get_backlight_type() just always returns native there." > Note that drivers/acpi/video_detect.c already has a DMI > quirk tables for models where the heuristics from > acpi_video_get_backlight_type() don't work. In general > we (mostly me) try to make it so that the heuristics > work on most models, to avoid needing to add every model > under the sun to the DMI quirk table, but if your laptop > is somehow special then adding a DMI quirk for it should > be fine ? > > Can you perhaps explain a bit in what way your laptop > is weird ? I guess it is weird in that it does not have the ACPI video, or at least does not offer ACPI video bus backlight control in its ACPI tables? Can you perhaps email me an acpidump of the laptop ? > Note that technically if the native backlight does not work, > then the GPU driver really should not even try to register > it. But sometimes the video-bios-tables claim the backlight > pwm input is attached to the GPU while it is not and things > have evolved in such a way that the DMI quirks for that > live in acpi/video_detect.c rather then in the GPU driver. And this bit can be ignored then because it certainly is not relevant if you actually want the native driver. Regards, Hans
On Tue, Oct 25, 2022 at 10:25:33PM +0200, Hans de Goede wrote: > Having the native driver come and then go and be replaced > with the vendor driver would also be quite inconvenient > for these planned changes. I understand that it would be inconvenient, but you've broken existing working setups. > Can you perhaps explain a bit in what way your laptop > is weird ? It's a Chinese replacement motherboard for a Thinkpad X201, running my own port of Coreboot. Its DMI strings look like an actual Thinkpad in order to ensure that thinkpad_acpi can bind for hotkey suport, so it's hard to quirk. It'll actually be fixed by your proposed patch to fall back to native rather than vendor, but that patch will break any older machines that offer a vendor interface and don't have the native control hooked up (pretty sure at least the Thinkpad X40 falls into that category).
Hi, On 10/25/22 22:40, Matthew Garrett wrote: > On Tue, Oct 25, 2022 at 10:25:33PM +0200, Hans de Goede wrote: > >> Having the native driver come and then go and be replaced >> with the vendor driver would also be quite inconvenient >> for these planned changes. > > I understand that it would be inconvenient, but you've broken existing > working setups. I fully acknowledge that I have broken existing working setups and I definitely want to see this fixed before say 6.1-rc6! I'm not convinced (at all) that any solutions which re-introduce acpi_video_get_backlight_type() return-s value changing half way the boot, with some backlight interface getting registered and then unregistered again later because it turns out to be the wrong one is a good fix here. The whole goal of the refactor was to leave these sorts of shenanigans behind us. >> Can you perhaps explain a bit in what way your laptop >> is weird ? > > It's a Chinese replacement motherboard for a Thinkpad X201, running my > own port of Coreboot. Its DMI strings look like an actual Thinkpad in > order to ensure that thinkpad_acpi can bind for hotkey suport, so it's > hard to quirk. It'll actually be fixed by your proposed patch to fall > back to native rather than vendor, but that patch will break any older > machines that offer a vendor interface and don't have the native control > hooked up (pretty sure at least the Thinkpad X40 falls into that > category). So looking at: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/mainboard/51nb/x210/acpi/graphics.asl this code should actually set the ACPI_VIDEO_BACKLIGHT flag: drivers/acpi/scan.c: static acpi_status acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context, void **return_value) { long *cap = context; if (acpi_has_method(handle, "_BCM") && acpi_has_method(handle, "_BCL")) { acpi_handle_debug(handle, "Found generic backlight support\n"); *cap |= ACPI_VIDEO_BACKLIGHT; /* We have backlight support, no need to scan further */ return AE_CTRL_TERMINATE; } return 0; } What does seem to be missing compared to a "normal" DSDT is a call to _OSI("Windows 2012") so I would expect this code in acpi_video_get_backlight_type(): /* On systems with ACPI video use either native or ACPI video. */ if (video_caps & ACPI_VIDEO_BACKLIGHT) { /* * Windows 8 and newer no longer use the ACPI video interface, * so it often does not work. If the ACPI tables are written * for win8 and native brightness ctl is available, use that. * * The native check deliberately is inside the if acpi-video * block on older devices without acpi-video support native * is usually not the best choice. */ if (acpi_osi_is_win8() && native_available) return acpi_backlight_native; else return acpi_backlight_video; } To enter the "return acpi_backlight_video" path since acpi_osi_is_win8() will return false. And then the ACPI backlight methods from: https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/master/src/mainboard/51nb/x210/acpi/graphics.asl should get called when changing the backlight brightness, so assuming that those methods work then things should work fine. What does "ls /sys/class/backlight" output on the X210 / NB51 board with a 6.0 kernel? And what does it output with the 6.1-rc? kernels? IOW which backlight device / control method is being selected and which one do you want / which one(s) do actually work? I have been thinking about maybe doing something with a dmi_get_bios_year() check (see below), but that will cause native to get prefered over vendor on old ThinkPads with coreboot (and thus a new enough year in DMI_BIOS_DATE), which will likely break backlight control there (if i915 offers backlight control on those that is). Also I wonder if it would be possible to set DMI_BIOS_VENDOR to "Coreboot" so that we can use that? Note that thinkpad_acpi does not care about the DMI_BIOS_VENDOR value, at least not on models which start their DMI_PRODUCT_VERSION with either "ThinkPad" or "Lenovo". ### Looking more at this I notice that coreboot has a drivers_intel_gma_displays_ssdt_generate() which seems to at least always generate ACPI video bus ASL including backlight control bits. So the only reason why the current heurstics are not returning native is the acpi_osi_is_win8() check. So maybe that beeds to become: if ((acpi_osi_is_win8() || dmi_get_bios_year() >= 2018) && native_available) return acpi_backlight_native; else return acpi_backlight_video; Although I think that will result in the same behavior as my patch below, and then my patch below would be cleaner... ### Also note that there actually already is a DMI quirk for the X201s, forcing ACPI video backlight control there. This is not strictly necessary, but when we first started using native by default on (back then) newer laptops some users of script everything yourself window-managers like i3 complained that they were relying on the in kernel handling of brightness key presses, which only works when using the acpi backlight control method... If that quirk matches your device then fixing the acpi_video_get_backlight_type() heuristics is not going to help. In that case we might decide to just drop the quirk though, since it was never really necessary in the first place; or change it to native, which may also help the X210 case? Regards, Hans
On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote: > this code should actually set the ACPI_VIDEO_BACKLIGHT flag: > drivers/acpi/scan.c: > > static acpi_status > acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context, > void **return_value) > { > long *cap = context; > > if (acpi_has_method(handle, "_BCM") && > acpi_has_method(handle, "_BCL")) { > acpi_handle_debug(handle, "Found generic backlight support\n"); > *cap |= ACPI_VIDEO_BACKLIGHT; > /* We have backlight support, no need to scan further */ > return AE_CTRL_TERMINATE; > } > return 0; > } Ah, yeah, my local tree no longer matches the upstream behaviour because I've hacked the EC firmware to remove the backlight trigger because it had an extremely poor brightness curve and also automatically changed it on AC events - as a result I removed the backlight code from the DSDT and just fell back to the native control. Like I said I'm a long way from the normal setup, but this did previously work. The "right" logic here seems pretty simple: if ACPI backlight control is expected to work, use it. If it isn't, but there's a vendor interface, use it. If there's no vendor interface, use the native interface. The problem you're dealing with is that the knowledge of whether or not there's a vendor interface isn't something the core kernel code knows about. What you're proposing here is effectively for us to expose additional information about whether or not there's a vendor interface in the system firmware, but since we're talking in some cases about hardware that's almost 20 years old, we're not realistically going to get those old machines fixed. So, it feels like there's two choices: 1) Make a default policy decision, but then allow that decision to be altered later on (eg, when a vendor-specific platform driver has been loaded) - you've said this poses additional complexities. 2) Move the knowledge of whether or not there's a vendor interface into the core code. Basically take every platform driver that exposes a vendor interface, and move the detection code into the core. I think any other approach is going to result in machines that previously worked no longer working (and you can't just make the vendor/native split dependent on the Coreboot DMI BIOS string, because there are some Coreboot platforms that implement the vendor interface for compatibility, and you also can't ask all Coreboot users to update their firmware to fix things)
Hi, On 10/26/22 01:40, Matthew Garrett wrote: > On Wed, Oct 26, 2022 at 01:27:25AM +0200, Hans de Goede wrote: > >> this code should actually set the ACPI_VIDEO_BACKLIGHT flag: >> drivers/acpi/scan.c: >> >> static acpi_status >> acpi_backlight_cap_match(acpi_handle handle, u32 level, void *context, >> void **return_value) >> { >> long *cap = context; >> >> if (acpi_has_method(handle, "_BCM") && >> acpi_has_method(handle, "_BCL")) { >> acpi_handle_debug(handle, "Found generic backlight support\n"); >> *cap |= ACPI_VIDEO_BACKLIGHT; >> /* We have backlight support, no need to scan further */ >> return AE_CTRL_TERMINATE; >> } >> return 0; >> } > > Ah, yeah, my local tree no longer matches the upstream behaviour because > I've hacked the EC firmware to remove the backlight trigger because it > had an extremely poor brightness curve and also automatically changed it > on AC events - as a result I removed the backlight code from the DSDT > and just fell back to the native control. Like I said I'm a long way > from the normal setup, but this did previously work. Ok, so this is a local customization to what is already a custom BIOS for a custom motherboard. There is a lot of custom in that sentence and TBH at some point things might become too custom for them to be expected to work OOTB. Note that you can always just override the choses made by the heuristisc/ quirks on the kernel commandline by adding: acpi_backlight=native (I think you want this one?) or if you want the old thinkpad_acpi module vendor/EC interface: acpi_backlight=vendor Asking you to pass this on the commandline does not seem like a huge stretch given the large amount of hw/firmware customization you have done ? > The "right" logic here seems pretty simple: if ACPI backlight control is > expected to work, use it. If it isn't, but there's a vendor interface, > use it. If there's no vendor interface, use the native interface. I'm afraid things are not that simple. I assume that with "if ACPI backlight control is expected to work" you mean don't use ACPI backlight control when (acpi_osi_is_win8() && native_available) evaluates to true because it is known to be broken on some of those systems because Windows 8 stopped using it ? Unfortunately something similar applies to vendor interfaces, When Windows XP started using (and mandating for certification IIRC) ACPI backlight control, vendors still kept their own vendor specific EC/smbios/ACPI/WMI backlight interfaces around for a long long time, except they were often no longer tested. So basically we have 3 major backlight control methods: 1. native GPU backlight control, which sometimes does not work on older laptops because the backlight is connected to the EC rather then the GPU there, yet often still enabled in the video-bios-tables so the GPU drivers will still try to use it. 2. ACPI -> known to be always present on recent Windows laptops because mandated by the hardware certification requirements (even on Windows 8+), but regularly broken on Windows 8+ because their backlight control was moved from the core-os to the GPU drivers and those typically use the native method. 3. Vendor specific EC/smbios/ACPI/WMI interfaces which work on older laptops, but are often present on newer laptops despite them no longer working and to get working backlight control either 1. or 2. should be used. So basically non of the 3 main backlight control methods can be trusted even if they are present. Which is why need to have a combination of heuristics + quirks. And I have been working on moving all this into a central place in drivers/acpi/video_detect.c because having the heuristics + quirks spread out all over the place does not help. > The > problem you're dealing with is that the knowledge of whether or not > there's a vendor interface isn't something the core kernel code knows > about. What you're proposing here is effectively for us to expose > additional information about whether or not there's a vendor interface > in the system firmware, but since we're talking in some cases about > hardware that's almost 20 years old, we're not realistically going to > get those old machines fixed. I don't understand why you keep talking about the old vendor interfaces, at least for the chromebook part of this thread the issue is that the i915 driver no longer registers the intel_backlight device which is a native device type, which is caused by the patch this email thread is about (and old vendor interfaces do not come into play at all here). So AFAICT this is a native vs acpi backlight control issue ? I really want to resolve your bug, but I still lack a lot of info, like what backlight interface you were actually using in 6.0 ? Can you please provide the following info for your laptop: 1. Output of "ls /sys/class/backlight" with 6.0 (working setup) 2. Output of "ls /sys/class/backlight" with 6.1 (non-working setup) 3. dmidecode output, so that I can check if this quirk: { .callback = video_detect_force_video, /* ThinkPad X201s */ .matches = { DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"), }, }, will trigger. 4. An acpidump. Although you already said that you have removed the ACPI video bus bits, so I guess I can just assume that the ACPI_VIDEO_BACKLIGHT flag won't get set. Regards, Hans p.s. This thread has made me wonder if the 6.1 changes don't cause regressions on other laptops flashed with a CoreOS BIOS, I will start a mail-thread asking for testing on the CoreOS mailinglist.
On Wed, Oct 26, 2022 at 11:59:28AM +0200, Hans de Goede wrote: > Ok, so this is a local customization to what is already a custom BIOS > for a custom motherboard. There is a lot of custom in that sentence and > TBH at some point things might become too custom for them to be expected > to work OOTB. But it *did* work OOTB before. You broke it. I accept that I'm a ludicrously weird corner case here, but there are going to be other systems that are also affected by this. > I'm afraid things are not that simple. I assume that with > "if ACPI backlight control is expected to work" you mean don't > use ACPI backlight control when (acpi_osi_is_win8() && native_available) > evaluates to true because it is known to be broken on some of > those systems because Windows 8 stopped using it ? Correct. > Unfortunately something similar applies to vendor interfaces, > When Windows XP started using (and mandating for certification > IIRC) ACPI backlight control, vendors still kept their own > vendor specific EC/smbios/ACPI/WMI backlight interfaces around for > a long long time, except they were often no longer tested. The current situation (both before your patchset and with its current implementation) is that vendor is preferred to native, so if the vendor interface is present then we're already using it. > > The > > problem you're dealing with is that the knowledge of whether or not > > there's a vendor interface isn't something the core kernel code knows > > about. What you're proposing here is effectively for us to expose > > additional information about whether or not there's a vendor interface > > in the system firmware, but since we're talking in some cases about > > hardware that's almost 20 years old, we're not realistically going to > > get those old machines fixed. > > I don't understand why you keep talking about the old vendor interfaces, > at least for the chromebook part of this thread the issue is that > the i915 driver no longer registers the intel_backlight device which > is a native device type, which is caused by the patch this email > thread is about (and old vendor interfaces do not come into play > at all here). So AFAICT this is a native vs acpi backlight control > issue ? I'm referring to your proposed patch that changed the default from backlight_vendor to backlight_native, which would fix my machine and Chromebooks but break anything that relies on the vendor interfaces. > I really want to resolve your bug, but I still lack a lot of info, > like what backlight interface you were actually using in 6.0 ? Native. > { > .callback = video_detect_force_video, > /* ThinkPad X201s */ > .matches = { > DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), > DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"), > }, > }, > > will trigger. In this case you'd break anyone else running the system who isn't using the hacked EC and different ACPI tables - obviously there's ways round this, but realistically since I'm (as far as I know) the only person in this situation it makes more sense for me to add a kernel parameter than carry around an exceedingly niche DMI quirk. I'm fine with that. But the point I'm trying to make is that the machines *are* telling you whether they'd prefer vendor or native, and you're not taking that into account in the video_detect code.
Hi, On 10/26/22 22:49, Matthew Garrett wrote: > On Wed, Oct 26, 2022 at 11:59:28AM +0200, Hans de Goede wrote: > >> Ok, so this is a local customization to what is already a custom BIOS >> for a custom motherboard. There is a lot of custom in that sentence and >> TBH at some point things might become too custom for them to be expected >> to work OOTB. > > But it *did* work OOTB before. You broke it. I accept that I'm a > ludicrously weird corner case here, but there are going to be other > systems that are also affected by this. > >> I'm afraid things are not that simple. I assume that with >> "if ACPI backlight control is expected to work" you mean don't >> use ACPI backlight control when (acpi_osi_is_win8() && native_available) >> evaluates to true because it is known to be broken on some of >> those systems because Windows 8 stopped using it ? > > Correct. > >> Unfortunately something similar applies to vendor interfaces, >> When Windows XP started using (and mandating for certification >> IIRC) ACPI backlight control, vendors still kept their own >> vendor specific EC/smbios/ACPI/WMI backlight interfaces around for >> a long long time, except they were often no longer tested. > > The current situation (both before your patchset and with its current > implementation) is that vendor is preferred to native, so if the vendor > interface is present then we're already using it. All vendor drivers that I'm aware of have: if (acpi_video_get_backlight_type() != acpi_backlight_vendor) return; In their backlight register paths and this has been present since circa 2015. So both before and after my 6.1 refactor vendor is only preferred on devices which don't implement the ACPI video bus control method. >>> The >>> problem you're dealing with is that the knowledge of whether or not >>> there's a vendor interface isn't something the core kernel code knows >>> about. What you're proposing here is effectively for us to expose >>> additional information about whether or not there's a vendor interface >>> in the system firmware, but since we're talking in some cases about >>> hardware that's almost 20 years old, we're not realistically going to >>> get those old machines fixed. >> >> I don't understand why you keep talking about the old vendor interfaces, >> at least for the chromebook part of this thread the issue is that >> the i915 driver no longer registers the intel_backlight device which >> is a native device type, which is caused by the patch this email >> thread is about (and old vendor interfaces do not come into play >> at all here). So AFAICT this is a native vs acpi backlight control >> issue ? > > I'm referring to your proposed patch that changed the default from > backlight_vendor to backlight_native, which would fix my machine and > Chromebooks but break anything that relies on the vendor interfaces. I see. I agree that preferring native over vendor on machines which do not have ACPI video backlight control will cause issues on older machines. Avoiding this scenario is exactly why currently the native check is conditional on the presence of ACPI video backlight control. >> I really want to resolve your bug, but I still lack a lot of info, >> like what backlight interface you were actually using in 6.0 ? > > Native. > >> { >> .callback = video_detect_force_video, >> /* ThinkPad X201s */ >> .matches = { >> DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"), >> DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"), >> }, >> }, >> >> will trigger. > > In this case you'd break anyone else running the system who isn't using > the hacked EC and different ACPI tables - obviously there's ways round > this, but realistically since I'm (as far as I know) the only person in > this situation it makes more sense for me to add a kernel parameter than > carry around an exceedingly niche DMI quirk. I'm fine with that. But the > point I'm trying to make is that the machines *are* telling you whether > they'd prefer vendor or native. I wish that that ("telling you whether they'd prefer vendor or native") were true. But that does not match my experience at all and I've been working on making the kernel pick the right backlight interface on laptops since 2014. Just because a vendor interface is present does not mean that it will work. Unfortunately for none of the 3 main native/acpi_video/vendor backlight control methods the control method being present also guarantees that it will work. Which completely sucks, but it is the reality we have to deal with. > , and you're not taking that into account > in the video_detect code. Regards, Hans
On Thu, Oct 27, 2022 at 10:51:45AM +0200, Hans de Goede wrote: > In their backlight register paths and this has been present since > circa 2015. > > So both before and after my 6.1 refactor vendor is only preferred > on devices which don't implement the ACPI video bus control method. Sorry, yes, that's the case I meant. > Just because a vendor interface is present does not mean that it will > work. Unfortunately for none of the 3 main native/acpi_video/vendor > backlight control methods the control method being present also guarantees > that it will work. Which completely sucks, but it is the reality we > have to deal with. But traditionally that's been logic that we've encoded into the vendor drivers, which can take other factors into account when determining whether the exposed interface works. You've now discarded that knowledge. The only way you can maintain the degree of functionality that 6.0 had is to move that determination into core code, or alternatively support dynamic reattachment of backlight interfaces based on vendor drivers loading later. An alternative would be to just revert all of this, and instead only use this logic for the output property interface (which would still result in different outcomes, but only for userland that's choosing to use the new interface, so that's a different problem).
Hi Matthew, On 10/27/22 11:11, Matthew Garrett wrote: > On Thu, Oct 27, 2022 at 10:51:45AM +0200, Hans de Goede wrote: > >> In their backlight register paths and this has been present since >> circa 2015. >> >> So both before and after my 6.1 refactor vendor is only preferred >> on devices which don't implement the ACPI video bus control method. > > Sorry, yes, that's the case I meant. > >> Just because a vendor interface is present does not mean that it will >> work. Unfortunately for none of the 3 main native/acpi_video/vendor >> backlight control methods the control method being present also guarantees >> that it will work. Which completely sucks, but it is the reality we >> have to deal with. > > But traditionally that's been logic that we've encoded into the vendor > drivers, which can take other factors into account when determining > whether the exposed interface works. You've now discarded that > knowledge. As I already mentioned in my previous email, the vendor drivers have been using something like: if (acpi_video_get_backlight_type() != acpi_backlight_vendor) return; In their backlight register paths *since 2015* and even before then most of them called some acpi_video helper function to determine if ACPI video backlight control was available and skipped registering their backlight device if that returned true. And calling that acpi_video helper is as smart as they traditionally were. That + DMI quirks and we still have all those quirks. I was very careful with the refactoring landing in 6.1 to *not* change any of this. The *only* behavior which actually is new in 6.1 is the native GPU drivers now doing the equivalent of: if (acpi_video_get_backlight_type() != acpi_backlight_native) return; In their backlight register paths (i), which is causing the native backlight to disappear on your custom laptop setup and on Chromebooks (with the Chromebooks case being already solved I hope.). I am fully aware that this may turn out to also impact other laptops. I'm keeping out an eye for this and I have specifically reached-out to the coreboot community asking them to test 6.1 . > The only way you can maintain the degree of functionality > that 6.0 had is to move that determination into core code, or > alternatively support dynamic reattachment of backlight interfaces based > on vendor drivers loading later. An alternative would be to just revert > all of this, and instead only use this logic for the output property > interface (which would still result in different outcomes, but only for > userland that's choosing to use the new interface, so that's a different > problem). Yes I am considering dropping the "acpi_video_get_backlight_type() != acpi_backlight_native" check from at least the i915 driver if we get more bug reports and then indeed only do the equivalent of that check in the code for the new output property. I agree this is a possible solution if this turns out to break more systems and there is no other easy/clean way to fix those. But I would greatly prefer to keep this change and stop the IMHO bad kernel behavior of "registering multiple backlight-devices for a single panel and then let userspace sort it out". Regards, Hans i) Before this, the kernel was relying on userspace preferring acpi_video or vendor backlight devices over native if both are present and the native backlight devices were registered unconditionally.
On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > The *only* behavior which actually is new in 6.1 is the native GPU > drivers now doing the equivalent of: > > if (acpi_video_get_backlight_type() != acpi_backlight_native) > return; > > In their backlight register paths (i), which is causing the native > backlight to disappear on your custom laptop setup and on Chromebooks > (with the Chromebooks case being already solved I hope.). It's causing the backlight control to vanish on any machine that isn't ((acpi_video || vendor interface) || !acpi). Most machines that fall into that are either weird or Chromebooks or old, but there are machines that fall into that. (I wrote https://mjg59.livejournal.com/127103.html over 12 years ago, so please do assume that I'm familiar with the complexities here :) ) > I agree this is a possible solution if this turns out to break more > systems and there is no other easy/clean way to fix those. But I would > greatly prefer to keep this change and stop the IMHO bad kernel behavior > of "registering multiple backlight-devices for a single panel and then > let userspace sort it out". If we're not able to make a correct policy decision in the kernel then punting it to userland seems like the right thing to do? The kernel absolutely *should* make the right decision where it has enough information to do so, but in this case the code that's making that decision doesn't have the full set of information.
Hi, On 10/27/22 11:52, Matthew Garrett wrote: > On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > >> The *only* behavior which actually is new in 6.1 is the native GPU >> drivers now doing the equivalent of: >> >> if (acpi_video_get_backlight_type() != acpi_backlight_native) >> return; >> >> In their backlight register paths (i), which is causing the native >> backlight to disappear on your custom laptop setup and on Chromebooks >> (with the Chromebooks case being already solved I hope.). > > It's causing the backlight control to vanish on any machine that isn't > ((acpi_video || vendor interface) || !acpi). Most machines that fall > into that are either weird or Chromebooks or old, but there are machines > that fall into that. I acknowledge that their are machines that fall into this category, but I expect / hope there to be so few of them that we can just DMI quirk our way out if this. I believe the old group to be small because: 1. Generally speaking the "native" control method is usually not present on the really old (pre ACPI video spec) mobile GPUs. 2. On most old laptops I would still expect there to be a vendor interface too, and if both get registered standard desktop environments will prefer the vendor one, so then we need a native DMI quirk to disable the vendor interface anyways and we already have a bunch of those, so some laptops in this group are already covered by DMI quirks. And a fix for the Chromebook case is already in Linus' tree, which just leaves the weird case, of which there will hopefully be only a few. I do share your worry that this might break some machines, but the only way to really find out is to get this code out there I'm afraid. I have just written a blog post asking for people to check if their laptop might be affected; and to report various details to me of their laptop is affected: https://hansdegoede.dreamwidth.org/26548.html Lets wait and see how this goes. If I get (too) many reports then I will send a revert of the addition of the: if (acpi_video_get_backlight_type() != acpi_backlight_native) return; check to the i915 / radeon / amd / nouveau drivers. (And if I only get a couple of reports I will probably just submit DMI quirks for the affected models). Regards, Hans
On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> wrote: > > Hi, > > On 10/27/22 11:52, Matthew Garrett wrote: > > On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > > > >> The *only* behavior which actually is new in 6.1 is the native GPU > >> drivers now doing the equivalent of: > >> > >> if (acpi_video_get_backlight_type() != acpi_backlight_native) > >> return; > >> > >> In their backlight register paths (i), which is causing the native > >> backlight to disappear on your custom laptop setup and on Chromebooks > >> (with the Chromebooks case being already solved I hope.). > > > > It's causing the backlight control to vanish on any machine that isn't > > ((acpi_video || vendor interface) || !acpi). Most machines that fall > > into that are either weird or Chromebooks or old, but there are machines > > that fall into that. > > I acknowledge that their are machines that fall into this category, > but I expect / hope there to be so few of them that we can just DMI > quirk our way out if this. > > I believe the old group to be small because: > > 1. Generally speaking the "native" control method is usually not > present on the really old (pre ACPI video spec) mobile GPUs. > > 2. On most old laptops I would still expect there to be a vendor > interface too, and if both get registered standard desktop environments > will prefer the vendor one, so then we need a native DMI quirk to > disable the vendor interface anyways and we already have a bunch of > those, so some laptops in this group are already covered by DMI quirks. > > And a fix for the Chromebook case is already in Linus' tree, which > just leaves the weird case, of which there will hopefully be only > a few. > > I do share your worry that this might break some machines, but > the only way to really find out is to get this code out there > I'm afraid. > > I have just written a blog post asking for people to check if > their laptop might be affected; and to report various details > to me of their laptop is affected: > > https://hansdegoede.dreamwidth.org/26548.html > > Lets wait and see how this goes. If I get (too) many reports then > I will send a revert of the addition of the: > > if (acpi_video_get_backlight_type() != acpi_backlight_native) > return; > > check to the i915 / radeon / amd / nouveau drivers. > > (And if I only get a couple of reports I will probably just submit > DMI quirks for the affected models). Sounds reasonable to me, FWIW. And IIUC the check above can be overridden by passing acpi_backlight=native in the kernel command line, right?
Hi, On 10/27/22 14:09, Rafael J. Wysocki wrote: > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> wrote: >> >> Hi, >> >> On 10/27/22 11:52, Matthew Garrett wrote: >>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: >>> >>>> The *only* behavior which actually is new in 6.1 is the native GPU >>>> drivers now doing the equivalent of: >>>> >>>> if (acpi_video_get_backlight_type() != acpi_backlight_native) >>>> return; >>>> >>>> In their backlight register paths (i), which is causing the native >>>> backlight to disappear on your custom laptop setup and on Chromebooks >>>> (with the Chromebooks case being already solved I hope.). >>> >>> It's causing the backlight control to vanish on any machine that isn't >>> ((acpi_video || vendor interface) || !acpi). Most machines that fall >>> into that are either weird or Chromebooks or old, but there are machines >>> that fall into that. >> >> I acknowledge that their are machines that fall into this category, >> but I expect / hope there to be so few of them that we can just DMI >> quirk our way out if this. >> >> I believe the old group to be small because: >> >> 1. Generally speaking the "native" control method is usually not >> present on the really old (pre ACPI video spec) mobile GPUs. >> >> 2. On most old laptops I would still expect there to be a vendor >> interface too, and if both get registered standard desktop environments >> will prefer the vendor one, so then we need a native DMI quirk to >> disable the vendor interface anyways and we already have a bunch of >> those, so some laptops in this group are already covered by DMI quirks. >> >> And a fix for the Chromebook case is already in Linus' tree, which >> just leaves the weird case, of which there will hopefully be only >> a few. >> >> I do share your worry that this might break some machines, but >> the only way to really find out is to get this code out there >> I'm afraid. >> >> I have just written a blog post asking for people to check if >> their laptop might be affected; and to report various details >> to me of their laptop is affected: >> >> https://hansdegoede.dreamwidth.org/26548.html >> >> Lets wait and see how this goes. If I get (too) many reports then >> I will send a revert of the addition of the: >> >> if (acpi_video_get_backlight_type() != acpi_backlight_native) >> return; >> >> check to the i915 / radeon / amd / nouveau drivers. >> >> (And if I only get a couple of reports I will probably just submit >> DMI quirks for the affected models). > > Sounds reasonable to me, FWIW. > > And IIUC the check above can be overridden by passing > acpi_backlight=native in the kernel command line, right? Right, that can be used as a quick workaround, but we really do want this to work OOTB everywhere. Regards, Hans
On Thu, Oct 27, 2022 at 2:17 PM Hans de Goede <hdegoede@redhat.com> wrote: > > Hi, > > On 10/27/22 14:09, Rafael J. Wysocki wrote: > > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> wrote: > >> > >> Hi, > >> > >> On 10/27/22 11:52, Matthew Garrett wrote: > >>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: > >>> > >>>> The *only* behavior which actually is new in 6.1 is the native GPU > >>>> drivers now doing the equivalent of: > >>>> > >>>> if (acpi_video_get_backlight_type() != acpi_backlight_native) > >>>> return; > >>>> > >>>> In their backlight register paths (i), which is causing the native > >>>> backlight to disappear on your custom laptop setup and on Chromebooks > >>>> (with the Chromebooks case being already solved I hope.). > >>> > >>> It's causing the backlight control to vanish on any machine that isn't > >>> ((acpi_video || vendor interface) || !acpi). Most machines that fall > >>> into that are either weird or Chromebooks or old, but there are machines > >>> that fall into that. > >> > >> I acknowledge that their are machines that fall into this category, > >> but I expect / hope there to be so few of them that we can just DMI > >> quirk our way out if this. > >> > >> I believe the old group to be small because: > >> > >> 1. Generally speaking the "native" control method is usually not > >> present on the really old (pre ACPI video spec) mobile GPUs. > >> > >> 2. On most old laptops I would still expect there to be a vendor > >> interface too, and if both get registered standard desktop environments > >> will prefer the vendor one, so then we need a native DMI quirk to > >> disable the vendor interface anyways and we already have a bunch of > >> those, so some laptops in this group are already covered by DMI quirks. > >> > >> And a fix for the Chromebook case is already in Linus' tree, which > >> just leaves the weird case, of which there will hopefully be only > >> a few. > >> > >> I do share your worry that this might break some machines, but > >> the only way to really find out is to get this code out there > >> I'm afraid. > >> > >> I have just written a blog post asking for people to check if > >> their laptop might be affected; and to report various details > >> to me of their laptop is affected: > >> > >> https://hansdegoede.dreamwidth.org/26548.html > >> > >> Lets wait and see how this goes. If I get (too) many reports then > >> I will send a revert of the addition of the: > >> > >> if (acpi_video_get_backlight_type() != acpi_backlight_native) > >> return; > >> > >> check to the i915 / radeon / amd / nouveau drivers. > >> > >> (And if I only get a couple of reports I will probably just submit > >> DMI quirks for the affected models). > > > > Sounds reasonable to me, FWIW. > > > > And IIUC the check above can be overridden by passing > > acpi_backlight=native in the kernel command line, right? > > Right, that can be used as a quick workaround, but we really do > want this to work OOTB everywhere. Sure. My point is that if it doesn't work OOTB for someone, and say it used to, they can use the above workaround and report back.
Hi Matthew, Rafael, On 10/27/22 14:09, Rafael J. Wysocki wrote: > On Thu, Oct 27, 2022 at 12:37 PM Hans de Goede <hdegoede@redhat.com> wrote: >> >> Hi, >> >> On 10/27/22 11:52, Matthew Garrett wrote: >>> On Thu, Oct 27, 2022 at 11:39:38AM +0200, Hans de Goede wrote: >>> >>>> The *only* behavior which actually is new in 6.1 is the native GPU >>>> drivers now doing the equivalent of: >>>> >>>> if (acpi_video_get_backlight_type() != acpi_backlight_native) >>>> return; >>>> >>>> In their backlight register paths (i), which is causing the native >>>> backlight to disappear on your custom laptop setup and on Chromebooks >>>> (with the Chromebooks case being already solved I hope.). >>> >>> It's causing the backlight control to vanish on any machine that isn't >>> ((acpi_video || vendor interface) || !acpi). Most machines that fall >>> into that are either weird or Chromebooks or old, but there are machines >>> that fall into that. >> >> I acknowledge that their are machines that fall into this category, >> but I expect / hope there to be so few of them that we can just DMI >> quirk our way out if this. >> >> I believe the old group to be small because: >> >> 1. Generally speaking the "native" control method is usually not >> present on the really old (pre ACPI video spec) mobile GPUs. >> >> 2. On most old laptops I would still expect there to be a vendor >> interface too, and if both get registered standard desktop environments >> will prefer the vendor one, so then we need a native DMI quirk to >> disable the vendor interface anyways and we already have a bunch of >> those, so some laptops in this group are already covered by DMI quirks. >> >> And a fix for the Chromebook case is already in Linus' tree, which >> just leaves the weird case, of which there will hopefully be only >> a few. >> >> I do share your worry that this might break some machines, but >> the only way to really find out is to get this code out there >> I'm afraid. >> >> I have just written a blog post asking for people to check if >> their laptop might be affected; and to report various details >> to me of their laptop is affected: >> >> https://hansdegoede.dreamwidth.org/26548.html >> >> Lets wait and see how this goes. If I get (too) many reports then >> I will send a revert of the addition of the: >> >> if (acpi_video_get_backlight_type() != acpi_backlight_native) >> return; >> >> check to the i915 / radeon / amd / nouveau drivers. >> >> (And if I only get a couple of reports I will probably just submit >> DMI quirks for the affected models). > > Sounds reasonable to me, FWIW. I have received quite a few test reports as a result of my blogpost (and of the blogpost's mention in an arstechnica article). Long story short, Matthew, you are right. Quite a few laptop models will end up with an empty /sys/class/backlight because of the native backlight class devices no longer registering when acpi_video_backlight_use_native() returns false. I will submit a patch-set later today to fix this (by making cpi_video_backlight_use_native() always return true for now). More detailed summary/analysis of the received test reports: -30 unaffected models -The following laptop models: Acer Aspire 1640 Apple MacBook 2.1 Apple MacBook 4.1 Apple MacBook Pro 7.1 (uses nv_backligh instead of intel_backlight!) HP Compaq nc6120 IBM ThinkPad X40 System76 Starling Star1 All only have a native intel_backlight interface and the heuristics from acpi_video_get_backlight_type() return acpi_backlight_vendor there causing the changes in 6.1 to not register native backlights when acpi_video_backlight_use_native() returns false resulting in an empty /sys/class/backlight, breaking users ability to control their laptop panel's brightness. I will submit a patch to always make acpi_video_backlight_use_native() return true for now to work around this for 6.1. I do plan to try to re-introduce that change again later. First I need to change the heuristics to still native on more models so that on models where the native backlight is the only (working) entry they will return native. -The Dell N1410 has acpi_video support and acpi_osi_is_win8() returns false so acpi_video_get_backlight_type() returns acpi_video, but acpi_video fails to register a backlight device due to a_BCM eval error. The intel_backlight interface works fine, but this model is going to need a DMI-use-native-quirk to avoid intel_backlight disappearing when acpi_video_backlight_use_native() is changed back. -The following laptop models actually use a vendor backlight control method, while also having a native backlight entry under /sys/class/backlight: Asus EeePC 901 -> native backlight confirmed to also work Dell Latitude D610 -> native backlight confirmed to work better then vendor Sony Vaio PCG-FRV3 -> native backlight not tested Note these will keep working the same as before in 6.1, independent of the revert. I've tracked these seperately because they will likely be affected by future changes to the heuristics. Regards, Hans p.s. My plan is to try again with 6.2 by making native be preferred over vendor (when native is available). It looks like native tends to work well when available even on systems so old that the don't have acpi_video backlight control support. I do plan to do another blogpost asking people to explicitly test that native works on laptops with a combination of vendor + native backlight control available.
diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c b/drivers/gpu/drm/i915/display/intel_backlight.c index 681ebcda97ad..03c7966f68d6 100644 --- a/drivers/gpu/drm/i915/display/intel_backlight.c +++ b/drivers/gpu/drm/i915/display/intel_backlight.c @@ -8,6 +8,8 @@ #include <linux/pwm.h> #include <linux/string_helpers.h> +#include <acpi/video.h> + #include "intel_backlight.h" #include "intel_backlight_regs.h" #include "intel_connector.h" @@ -952,6 +954,11 @@ int intel_backlight_device_register(struct intel_connector *connector) WARN_ON(panel->backlight.max == 0); + if (!acpi_video_backlight_use_native()) { + drm_info(&i915->drm, "Skipping intel_backlight registration\n"); + return 0; + } + memset(&props, 0, sizeof(props)); props.type = BACKLIGHT_RAW;