Centos-kernel-stream-9/drivers/acpi/video_detect.c

835 lines
23 KiB
C
Raw Normal View History

/*
* Copyright (C) 2015 Red Hat Inc.
* Hans de Goede <hdegoede@redhat.com>
* Copyright (C) 2008 SuSE Linux Products GmbH
* Thomas Renninger <trenn@suse.de>
*
* May be copied or modified under the terms of the GNU General Public License
*
* video_detect.c:
* After PCI devices are glued with ACPI devices
* acpi_get_pci_dev() can be called to identify ACPI graphics
* devices for which a real graphics card is plugged in
*
* Depending on whether ACPI graphics extensions (cmp. ACPI spec Appendix B)
* are available, video.ko should be used to handle the device.
*
* Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
* sony_acpi,... can take care about backlight brightness.
*
ACPI: video: Add acpi_video_backlight_use_native() helper Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2160456 Upstream Status: v6.1-rc1 commit 2600bfa3df9944562d43d1f17016832a6ffa3b38 Author: Hans de Goede <hdegoede@redhat.com> AuthorDate: Fri Apr 15 13:59:48 2022 +0200 Commit: Hans de Goede <hdegoede@redhat.com> CommitDate: Wed Aug 17 12:30:05 2022 +0200 ATM on x86 laptops where we want userspace to use the acpi_video backlight device we often 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, but registering 2 backlight devices for a single display really is undesirable. On x86 laptops where the native GPU backlight device should be used, the registering of other backlight devices is avoided by their drivers using acpi_video_get_backlight_type() and only registering their backlight if the return value matches their type. acpi_video_get_backlight_type() uses backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a native driver is available and will never return native if this returns false. This means that the GPU's native backlight registering code cannot just call acpi_video_get_backlight_type() to determine if it should register its backlight, since acpi_video_get_backlight_type() will never return native until the native backlight has already registered. To fix this add a new internal native function parameter to acpi_video_get_backlight_type(), which when set to true will make acpi_video_get_backlight_type() behave as if a native backlight has already been registered. And add a new acpi_video_backlight_use_native() helper, which sets this to true, for use in native GPU backlight code. Changes in v2: - Replace adding a native parameter to acpi_video_get_backlight_type() with adding a new acpi_video_backlight_use_native() helper. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mika Penttilä <mpenttil@redhat.com>
2023-03-20 10:05:32 +00:00
* Backlight drivers can use acpi_video_get_backlight_type() to determine which
* driver should handle the backlight. RAW/GPU-driver backlight drivers must
* use the acpi_video_backlight_use_native() helper for this.
*
* If CONFIG_ACPI_VIDEO is neither set as "compiled in" (y) nor as a module (m)
* this file will not be compiled and acpi_video_get_backlight_type() will
* always return acpi_backlight_vendor.
*/
#include <linux/export.h>
#include <linux/acpi.h>
#include <linux/backlight.h>
#include <linux/dmi.h>
acpi-video-detect: video: Make video_detect code part of the video module This is a preparation patch for the backlight interface selection logic cleanup, there are 2 reasons to not always build the video_detect code into the kernel: 1) In order for the video_detect.c to also deal with / select native backlight interfaces on win8 systems, instead of doing this in video.c where it does not belong, video_detect.c needs to call into the backlight class code. Which cannot be done if it is builtin and the blacklight class is not. 2) Currently all the platform/x86 drivers which have quirks to prefer the vendor driver over acpi-video call acpi_video_unregister_backlight() to remove the acpi-video backlight interface, this logic really belongs in video_detect.c, which will cause video_detect.c to depend on symbols of video.c and video.c already depends on video_detect.c symbols, so they really need to be a single module. Note that this commits make 2 changes so as to maintain 100% kernel commandline compatibility: 1) The __setup call for the acpi_backlight= handling is moved to acpi/util.c as __setup may only be used by code which is alwasy builtin 2) video.c is renamed to acpi_video.c so that it can be combined with video_detect.c into video.ko This commit also makes changes to drivers/platform/x86/Kconfig to ensure that drivers which use acpi_video_backlight_support() from video_detect.c, will not be built-in when acpi_video is not built in. This also changes some "select" uses to "depends on" to avoid dependency loops. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-16 14:27:47 +00:00
#include <linux/module.h>
#include <linux/pci.h>
#include <linux/platform_data/x86/nvidia-wmi-ec-backlight.h>
#include <linux/types.h>
ACPI / video: Fix circular lock dependency issue in the video-detect code Before this commit, the following would happen: a) acpi_video_get_backlight_type() gets called b) acpi_video_get_backlight_type() calls acpi_video_init_backlight_type() c) acpi_video_init_backlight_type() locks its function static init_mutex d) acpi_video_init_backlight_type() calls backlight_register_notifier() e) backlight_register_notifier() takes its notifier-chain lock And when the backlight notifier chain gets called we've: 1) blocking_notifier_call_chain() gets called 2) blocking_notifier_call_chain() takes the notifier-chain lock 3) blocking_notifier_call_chain() calls acpi_video_backlight_notify() 4) acpi_video_backlight_notify() calls acpi_video_get_backlight_type() 5) acpi_video_get_backlight_type() calls acpi_video_init_backlight_type() 6) acpi_video_init_backlight_type() locks its function static init_mutex So in the first call sequence we have: a) init_mutex gets locked b) notifier-chain gets locked and in the second call sequence we have: 1) notifier-chain gets locked 2) init_mutex gets locked And we've a circular locking dependency. This specific locking dependency is fixable without using the big hammer otherwise known as a workqueue, but further analysis shows a similar problem with the backlight notifier chain lock vs register_count_mutex from drivers/acpi/acpi_video.c, and fixing that becomes problematic. So this commit simply fixes this with the big hammer, performance wise this is a non issue as we expect the work to get scheduled exactly zero or one times during normal system use. Fixes: 93a291dfaf9c (ACPI / video: Move backlight notifier to video_detect.c) Signed-off-by: Hans de Goede <hdegoede@redhat.com> Reported-and-tested-by: Sedat Dilek <sedat.dilek@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-08-13 16:53:37 +00:00
#include <linux/workqueue.h>
#include <acpi/video.h>
void acpi_video_unregister_backlight(void);
static enum acpi_backlight_type acpi_backlight_cmdline = acpi_backlight_undef;
static enum acpi_backlight_type acpi_backlight_dmi = acpi_backlight_undef;
acpi-video-detect: video: Make video_detect code part of the video module This is a preparation patch for the backlight interface selection logic cleanup, there are 2 reasons to not always build the video_detect code into the kernel: 1) In order for the video_detect.c to also deal with / select native backlight interfaces on win8 systems, instead of doing this in video.c where it does not belong, video_detect.c needs to call into the backlight class code. Which cannot be done if it is builtin and the blacklight class is not. 2) Currently all the platform/x86 drivers which have quirks to prefer the vendor driver over acpi-video call acpi_video_unregister_backlight() to remove the acpi-video backlight interface, this logic really belongs in video_detect.c, which will cause video_detect.c to depend on symbols of video.c and video.c already depends on video_detect.c symbols, so they really need to be a single module. Note that this commits make 2 changes so as to maintain 100% kernel commandline compatibility: 1) The __setup call for the acpi_backlight= handling is moved to acpi/util.c as __setup may only be used by code which is alwasy builtin 2) video.c is renamed to acpi_video.c so that it can be combined with video_detect.c into video.ko This commit also makes changes to drivers/platform/x86/Kconfig to ensure that drivers which use acpi_video_backlight_support() from video_detect.c, will not be built-in when acpi_video is not built in. This also changes some "select" uses to "depends on" to avoid dependency loops. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-16 14:27:47 +00:00
static void acpi_video_parse_cmdline(void)
{
if (!strcmp("vendor", acpi_video_backlight_string))
acpi_backlight_cmdline = acpi_backlight_vendor;
acpi-video-detect: video: Make video_detect code part of the video module This is a preparation patch for the backlight interface selection logic cleanup, there are 2 reasons to not always build the video_detect code into the kernel: 1) In order for the video_detect.c to also deal with / select native backlight interfaces on win8 systems, instead of doing this in video.c where it does not belong, video_detect.c needs to call into the backlight class code. Which cannot be done if it is builtin and the blacklight class is not. 2) Currently all the platform/x86 drivers which have quirks to prefer the vendor driver over acpi-video call acpi_video_unregister_backlight() to remove the acpi-video backlight interface, this logic really belongs in video_detect.c, which will cause video_detect.c to depend on symbols of video.c and video.c already depends on video_detect.c symbols, so they really need to be a single module. Note that this commits make 2 changes so as to maintain 100% kernel commandline compatibility: 1) The __setup call for the acpi_backlight= handling is moved to acpi/util.c as __setup may only be used by code which is alwasy builtin 2) video.c is renamed to acpi_video.c so that it can be combined with video_detect.c into video.ko This commit also makes changes to drivers/platform/x86/Kconfig to ensure that drivers which use acpi_video_backlight_support() from video_detect.c, will not be built-in when acpi_video is not built in. This also changes some "select" uses to "depends on" to avoid dependency loops. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-16 14:27:47 +00:00
if (!strcmp("video", acpi_video_backlight_string))
acpi_backlight_cmdline = acpi_backlight_video;
if (!strcmp("native", acpi_video_backlight_string))
acpi_backlight_cmdline = acpi_backlight_native;
if (!strcmp("nvidia_wmi_ec", acpi_video_backlight_string))
acpi_backlight_cmdline = acpi_backlight_nvidia_wmi_ec;
if (!strcmp("none", acpi_video_backlight_string))
acpi_backlight_cmdline = acpi_backlight_none;
acpi-video-detect: video: Make video_detect code part of the video module This is a preparation patch for the backlight interface selection logic cleanup, there are 2 reasons to not always build the video_detect code into the kernel: 1) In order for the video_detect.c to also deal with / select native backlight interfaces on win8 systems, instead of doing this in video.c where it does not belong, video_detect.c needs to call into the backlight class code. Which cannot be done if it is builtin and the blacklight class is not. 2) Currently all the platform/x86 drivers which have quirks to prefer the vendor driver over acpi-video call acpi_video_unregister_backlight() to remove the acpi-video backlight interface, this logic really belongs in video_detect.c, which will cause video_detect.c to depend on symbols of video.c and video.c already depends on video_detect.c symbols, so they really need to be a single module. Note that this commits make 2 changes so as to maintain 100% kernel commandline compatibility: 1) The __setup call for the acpi_backlight= handling is moved to acpi/util.c as __setup may only be used by code which is alwasy builtin 2) video.c is renamed to acpi_video.c so that it can be combined with video_detect.c into video.ko This commit also makes changes to drivers/platform/x86/Kconfig to ensure that drivers which use acpi_video_backlight_support() from video_detect.c, will not be built-in when acpi_video is not built in. This also changes some "select" uses to "depends on" to avoid dependency loops. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Darren Hart <dvhart@linux.intel.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2015-06-16 14:27:47 +00:00
}
static acpi_status
find_video(acpi_handle handle, u32 lvl, void *context, void **rv)
{
struct acpi_device *acpi_dev = acpi_fetch_acpi_dev(handle);
long *cap = context;
struct pci_dev *dev;
static const struct acpi_device_id video_ids[] = {
{ACPI_VIDEO_HID, 0},
{"", 0},
};
if (acpi_dev && !acpi_match_device_ids(acpi_dev, video_ids)) {
dev = acpi_get_pci_dev(handle);
if (!dev)
return AE_OK;
pci_dev_put(dev);
*cap |= acpi_is_video_device(handle);
}
return AE_OK;
}
/* This depends on ACPI_WMI which is X86 only */
#ifdef CONFIG_X86
static bool nvidia_wmi_ec_supported(void)
{
struct wmi_brightness_args args = {
.mode = WMI_BRIGHTNESS_MODE_GET,
.val = 0,
.ret = 0,
};
struct acpi_buffer buf = { (acpi_size)sizeof(args), &args };
acpi_status status;
status = wmi_evaluate_method(WMI_BRIGHTNESS_GUID, 0,
WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf);
if (ACPI_FAILURE(status))
return false;
/*
* If brightness is handled by the EC then nvidia-wmi-ec-backlight
* should be used, else the GPU driver(s) should be used.
*/
return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
}
#else
static bool nvidia_wmi_ec_supported(void)
{
return false;
}
#endif
/* Force to use vendor driver when the ACPI device is known to be
* buggy */
static int video_detect_force_vendor(const struct dmi_system_id *d)
{
acpi_backlight_dmi = acpi_backlight_vendor;
return 0;
}
static int video_detect_force_video(const struct dmi_system_id *d)
{
acpi_backlight_dmi = acpi_backlight_video;
return 0;
}
static int video_detect_force_native(const struct dmi_system_id *d)
{
acpi_backlight_dmi = acpi_backlight_native;
return 0;
}
static int video_detect_portege_r100(const struct dmi_system_id *d)
{
struct pci_dev *dev;
/* Search for Trident CyberBlade XP4m32 to confirm Portégé R100 */
dev = pci_get_device(PCI_VENDOR_ID_TRIDENT, 0x2100, NULL);
if (dev)
acpi_backlight_dmi = acpi_backlight_vendor;
return 0;
}
static const struct dmi_system_id video_detect_dmi_table[] = {
/* On Samsung X360, the BIOS will set a flag (VDRV) if generic
* ACPI backlight device is used. This flag will definitively break
* the backlight interface (even the vendor interface) until next
* reboot. It's why we should prevent video.ko from being used here
* and we can't rely on a later call to acpi_video_unregister().
*/
{
.callback = video_detect_force_vendor,
/* X360 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
DMI_MATCH(DMI_PRODUCT_NAME, "X360"),
DMI_MATCH(DMI_BOARD_NAME, "X360"),
},
},
{
.callback = video_detect_force_vendor,
/* Asus UL30VT */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "UL30VT"),
},
},
{
.callback = video_detect_force_vendor,
/* Asus UL30A */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"),
},
},
{
.callback = video_detect_force_vendor,
/* GIGABYTE GB-BXBT-2807 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
},
},
{
.callback = video_detect_force_vendor,
/* Sony VPCEH3U1E */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Sony Corporation"),
DMI_MATCH(DMI_PRODUCT_NAME, "VPCEH3U1E"),
},
},
{
.callback = video_detect_force_native,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "Vostro 15 3535"),
},
},
/*
* Toshiba Portégé R100 has working both acpi_video and toshiba_acpi
* vendor driver. But none of them gets activated as it has a VGA with
* no kernel driver (Trident CyberBlade XP4m32).
* The DMI strings are generic so check for the VGA chip in callback.
*/
{
.callback = video_detect_portege_r100,
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
DMI_MATCH(DMI_PRODUCT_NAME, "Portable PC"),
DMI_MATCH(DMI_PRODUCT_VERSION, "Version 1.0"),
DMI_MATCH(DMI_BOARD_NAME, "Portable PC")
},
},
/*
* Models which need acpi_video backlight control where the GPU drivers
* do not call acpi_video_register_backlight() because no internal panel
* is detected. Typically these are all-in-ones (monitors with builtin
* PC) where the panel connection shows up as regular DP instead of eDP.
*/
{
.callback = video_detect_force_video,
/* Apple iMac14,1 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "iMac14,1"),
},
},
{
.callback = video_detect_force_video,
/* Apple iMac14,2 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "iMac14,2"),
},
},
ACPI: video: Add acpi_backlight=video quirk for Lenovo ThinkPad W530 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2186058 Upstream-status: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git commit a5b2781dcab2c77979a4b8adda781d2543580901 Author: Hans de Goede <hdegoede@redhat.com> Date: Tue, 4 Apr 2023 13:02:49 +0200 The Lenovo ThinkPad W530 uses a nvidia k1000m GPU. When this gets used together with one of the older nvidia binary driver series (the latest series does not support it), then backlight control does not work. This is caused by commit 3dbc80a3e4c5 ("ACPI: video: Make backlight class device registration a separate step (v2)") combined with commit 5aa9d943e9b6 ("ACPI: video: Don't enable fallback path for creating ACPI backlight by default"). After these changes the acpi_video# backlight device is only registered when requested by a GPU driver calling acpi_video_register_backlight() which the nvidia binary driver does not do. I realize that using the nvidia binary driver is not a supported use-case and users can workaround this by adding acpi_backlight=video on the kernel commandline, but the ThinkPad W530 is a popular model under Linux users, so it seems worthwhile to add a quirk for this. I will also email Nvidia asking them to make the driver call acpi_video_register_backlight() when an internal LCD panel is detected. So maybe the next maintenance release of the drivers will fix this... Fixes: 5aa9d943e9b6 ("ACPI: video: Don't enable fallback path for creating ACPI backlight by default") Cc: All applicable <stable@vger.kernel.org> Reviewed-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
2023-07-06 17:21:22 +00:00
/*
* Older models with nvidia GPU which need acpi_video backlight
* control and where the old nvidia binary driver series does not
* call acpi_video_register_backlight().
*/
{
.callback = video_detect_force_video,
/* ThinkPad W530 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad W530"),
},
},
/*
* These models have a working acpi_video backlight control, and using
* native backlight causes a regression where backlight does not work
* when userspace is not handling brightness key events. Disable
* native_backlight on these to fix this:
* https://bugzilla.kernel.org/show_bug.cgi?id=81691
*/
{
.callback = video_detect_force_video,
/* ThinkPad T420 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T420"),
},
},
{
.callback = video_detect_force_video,
/* ThinkPad T520 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad T520"),
},
},
{
.callback = video_detect_force_video,
/* ThinkPad X201s */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201s"),
},
},
{
.callback = video_detect_force_video,
/* ThinkPad X201T */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_PRODUCT_VERSION, "ThinkPad X201T"),
},
},
/* The native backlight controls do not work on some older machines */
{
/* https://bugs.freedesktop.org/show_bug.cgi?id=81515 */
.callback = video_detect_force_video,
/* HP ENVY 15 Notebook */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
DMI_MATCH(DMI_PRODUCT_NAME, "HP ENVY 15 Notebook PC"),
},
},
{
.callback = video_detect_force_video,
/* SAMSUNG 870Z5E/880Z5E/680Z5E */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
DMI_MATCH(DMI_PRODUCT_NAME, "870Z5E/880Z5E/680Z5E"),
},
},
{
.callback = video_detect_force_video,
/* SAMSUNG 370R4E/370R4V/370R5E/3570RE/370R5V */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
DMI_MATCH(DMI_PRODUCT_NAME,
"370R4E/370R4V/370R5E/3570RE/370R5V"),
},
},
{
/* https://bugzilla.redhat.com/show_bug.cgi?id=1186097 */
.callback = video_detect_force_video,
/* SAMSUNG 3570R/370R/470R/450R/510R/4450RV */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
DMI_MATCH(DMI_PRODUCT_NAME,
"3570R/370R/470R/450R/510R/4450RV"),
},
},
{
/* https://bugzilla.redhat.com/show_bug.cgi?id=1557060 */
.callback = video_detect_force_video,
/* SAMSUNG 670Z5E */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
DMI_MATCH(DMI_PRODUCT_NAME, "670Z5E"),
},
},
{
/* https://bugzilla.redhat.com/show_bug.cgi?id=1094948 */
.callback = video_detect_force_video,
/* SAMSUNG 730U3E/740U3E */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
DMI_MATCH(DMI_PRODUCT_NAME, "730U3E/740U3E"),
},
},
{
/* https://bugs.freedesktop.org/show_bug.cgi?id=87286 */
.callback = video_detect_force_video,
/* SAMSUNG 900X3C/900X3D/900X3E/900X4C/900X4D */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
DMI_MATCH(DMI_PRODUCT_NAME,
"900X3C/900X3D/900X3E/900X4C/900X4D"),
},
},
{
/* https://bugzilla.redhat.com/show_bug.cgi?id=1272633 */
.callback = video_detect_force_video,
/* Dell XPS14 L421X */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "XPS L421X"),
},
},
{
/* https://bugzilla.redhat.com/show_bug.cgi?id=1163574 */
.callback = video_detect_force_video,
/* Dell XPS15 L521X */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "XPS L521X"),
},
},
{
/* https://bugzilla.kernel.org/show_bug.cgi?id=108971 */
.callback = video_detect_force_video,
/* SAMSUNG 530U4E/540U4E */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
DMI_MATCH(DMI_PRODUCT_NAME, "530U4E/540U4E"),
},
},
/* https://bugs.launchpad.net/bugs/1894667 */
{
.callback = video_detect_force_video,
/* HP 635 Notebook */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Hewlett-Packard"),
DMI_MATCH(DMI_PRODUCT_NAME, "HP 635 Notebook PC"),
},
},
/* Non win8 machines which need native backlight nevertheless */
{
/* https://bugzilla.redhat.com/show_bug.cgi?id=1201530 */
.callback = video_detect_force_native,
/* Lenovo Ideapad S405 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_BOARD_NAME, "Lenovo IdeaPad S405"),
},
},
{
/* https://bugzilla.suse.com/show_bug.cgi?id=1208724 */
.callback = video_detect_force_native,
/* Lenovo Ideapad Z470 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_PRODUCT_VERSION, "IdeaPad Z470"),
},
},
{
/* https://bugzilla.redhat.com/show_bug.cgi?id=1187004 */
.callback = video_detect_force_native,
/* Lenovo Ideapad Z570 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_PRODUCT_NAME, "102434U"),
},
},
{
.callback = video_detect_force_native,
/* Lenovo E41-25 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_PRODUCT_NAME, "81FS"),
},
},
{
.callback = video_detect_force_native,
/* Lenovo E41-45 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_PRODUCT_NAME, "82BK"),
},
},
{
.callback = video_detect_force_native,
/* Lenovo Slim 7 16ARH7 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_PRODUCT_NAME, "82UX"),
},
},
{
.callback = video_detect_force_native,
/* Lenovo ThinkPad X131e (3371 AMD version) */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "LENOVO"),
DMI_MATCH(DMI_PRODUCT_NAME, "3371"),
},
},
{
.callback = video_detect_force_native,
/* Apple iMac11,3 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "iMac11,3"),
},
},
{
/* https://gitlab.freedesktop.org/drm/amd/-/issues/1838 */
.callback = video_detect_force_native,
/* Apple iMac12,1 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "iMac12,1"),
},
},
{
/* https://gitlab.freedesktop.org/drm/amd/-/issues/2753 */
.callback = video_detect_force_native,
/* Apple iMac12,2 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "iMac12,2"),
},
},
{
/* https://bugzilla.redhat.com/show_bug.cgi?id=1217249 */
.callback = video_detect_force_native,
/* Apple MacBook Pro 12,1 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Apple Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "MacBookPro12,1"),
},
},
{
.callback = video_detect_force_native,
/* Dell Inspiron N4010 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "Inspiron N4010"),
},
},
{
.callback = video_detect_force_native,
/* Dell Vostro V131 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "Vostro V131"),
},
},
{
/* https://bugzilla.redhat.com/show_bug.cgi?id=1123661 */
.callback = video_detect_force_native,
/* Dell XPS 17 L702X */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "Dell System XPS L702X"),
},
},
{
.callback = video_detect_force_native,
/* Dell Precision 7510 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "Precision 7510"),
},
},
{
.callback = video_detect_force_native,
/* Dell Studio 1569 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Dell Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "Studio 1569"),
},
},
{
.callback = video_detect_force_native,
/* Acer Aspire 3830TG */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 3830TG"),
},
},
{
.callback = video_detect_force_native,
/* Acer Aspire 5738z */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5738"),
DMI_MATCH(DMI_BOARD_NAME, "JV50"),
},
},
{
/* https://bugzilla.kernel.org/show_bug.cgi?id=207835 */
.callback = video_detect_force_native,
/* Acer TravelMate 5735Z */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5735Z"),
DMI_MATCH(DMI_BOARD_NAME, "BA51_MV"),
},
},
{
.callback = video_detect_force_native,
/* ASUSTeK COMPUTER INC. GA401 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA401"),
},
},
{
.callback = video_detect_force_native,
/* ASUSTeK COMPUTER INC. GA502 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA502"),
},
},
{
.callback = video_detect_force_native,
/* ASUSTeK COMPUTER INC. GA503 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA503"),
},
},
/*
* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
* working native and video interface. However the default detection
* mechanism first registers the video interface before unregistering
* it again and switching to the native interface during boot. This
* results in a dangling SBIOS request for backlight change for some
* reason, causing the backlight to switch to ~2% once per boot on the
* first power cord connect or disconnect event. Setting the native
* interface explicitly circumvents this buggy behaviour, by avoiding
* the unregistering process.
*/
{
.callback = video_detect_force_native,
.ident = "Clevo NL5xRU",
.matches = {
DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
},
},
{
.callback = video_detect_force_native,
.ident = "Clevo NL5xRU",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
DMI_MATCH(DMI_BOARD_NAME, "AURA1501"),
},
},
{
.callback = video_detect_force_native,
.ident = "Clevo NL5xRU",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
DMI_MATCH(DMI_BOARD_NAME, "EDUBOOK1502"),
},
},
{
.callback = video_detect_force_native,
.ident = "Clevo NL5xNU",
.matches = {
DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
},
},
/*
* The TongFang PF5PU1G, PF4NU1F, PF5NU1G, and PF5LUXG/TUXEDO BA15 Gen10,
* Pulse 14/15 Gen1, and Pulse 15 Gen2 have the same problem as the Clevo
* NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2. See the description
* above.
*/
{
.callback = video_detect_force_native,
.ident = "TongFang PF5PU1G",
.matches = {
DMI_MATCH(DMI_BOARD_NAME, "PF5PU1G"),
},
},
{
.callback = video_detect_force_native,
.ident = "TongFang PF4NU1F",
.matches = {
DMI_MATCH(DMI_BOARD_NAME, "PF4NU1F"),
},
},
{
.callback = video_detect_force_native,
.ident = "TongFang PF4NU1F",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
DMI_MATCH(DMI_BOARD_NAME, "PULSE1401"),
},
},
{
.callback = video_detect_force_native,
.ident = "TongFang PF5NU1G",
.matches = {
DMI_MATCH(DMI_BOARD_NAME, "PF5NU1G"),
},
},
{
.callback = video_detect_force_native,
.ident = "TongFang PF5NU1G",
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
DMI_MATCH(DMI_BOARD_NAME, "PULSE1501"),
},
},
{
.callback = video_detect_force_native,
.ident = "TongFang PF5LUXG",
.matches = {
DMI_MATCH(DMI_BOARD_NAME, "PF5LUXG"),
},
},
/*
* x86 android tablets which directly control the backlight through
* an external backlight controller, typically TI's LP8557.
* The backlight is directly controlled by the lp855x driver on these.
* This setup means that neither i915's native nor acpi_video backlight
* control works. Add a "vendor" quirk to disable both. Note these
* devices do not use vendor control in the typical meaning of
* vendor specific SMBIOS or ACPI calls being used.
*/
{
.callback = video_detect_force_vendor,
/* Lenovo Yoga Book X90F / X90L */
.matches = {
DMI_EXACT_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
DMI_EXACT_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
DMI_EXACT_MATCH(DMI_PRODUCT_VERSION, "YETI-11"),
},
},
{
.callback = video_detect_force_vendor,
/*
* Lenovo Yoga Tablet 2 830F/L or 1050F/L (The 8" and 10"
* Lenovo Yoga Tablet 2 use the same mainboard)
*/
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Intel Corp."),
DMI_MATCH(DMI_PRODUCT_NAME, "VALLEYVIEW C0 PLATFORM"),
DMI_MATCH(DMI_BOARD_NAME, "BYT-T FFD8"),
/* Partial match on beginning of BIOS version */
DMI_MATCH(DMI_BIOS_VERSION, "BLADE_21"),
},
},
{
.callback = video_detect_force_vendor,
/* Lenovo Yoga Tab 3 Pro YT3-X90F */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Intel Corporation"),
DMI_MATCH(DMI_PRODUCT_NAME, "CHERRYVIEW D1 PLATFORM"),
DMI_MATCH(DMI_PRODUCT_VERSION, "Blade3-10A-001"),
},
},
{
.callback = video_detect_force_vendor,
/* Xiaomi Mi Pad 2 */
.matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Xiaomi Inc"),
DMI_MATCH(DMI_PRODUCT_NAME, "Mipad2"),
},
},
{ },
};
static bool google_cros_ec_present(void)
{
return acpi_dev_found("GOOG0004") || acpi_dev_found("GOOG000C");
}
/*
* Windows 8 and newer no longer use the ACPI video interface, so it often
* does not work. So on win8+ systems prefer native brightness control.
* Chromebooks should always prefer native backlight control.
*/
static bool prefer_native_over_acpi_video(void)
{
return acpi_osi_is_win8() || google_cros_ec_present();
}
/*
* Determine which type of backlight interface to use on this system,
* First check cmdline, then dmi quirks, then do autodetect.
*/
enum acpi_backlight_type __acpi_video_get_backlight_type(bool native, bool *auto_detect)
{
static DEFINE_MUTEX(init_mutex);
static bool nvidia_wmi_ec_present;
ACPI: video: Add acpi_video_backlight_use_native() helper Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2160456 Upstream Status: v6.1-rc1 commit 2600bfa3df9944562d43d1f17016832a6ffa3b38 Author: Hans de Goede <hdegoede@redhat.com> AuthorDate: Fri Apr 15 13:59:48 2022 +0200 Commit: Hans de Goede <hdegoede@redhat.com> CommitDate: Wed Aug 17 12:30:05 2022 +0200 ATM on x86 laptops where we want userspace to use the acpi_video backlight device we often 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, but registering 2 backlight devices for a single display really is undesirable. On x86 laptops where the native GPU backlight device should be used, the registering of other backlight devices is avoided by their drivers using acpi_video_get_backlight_type() and only registering their backlight if the return value matches their type. acpi_video_get_backlight_type() uses backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a native driver is available and will never return native if this returns false. This means that the GPU's native backlight registering code cannot just call acpi_video_get_backlight_type() to determine if it should register its backlight, since acpi_video_get_backlight_type() will never return native until the native backlight has already registered. To fix this add a new internal native function parameter to acpi_video_get_backlight_type(), which when set to true will make acpi_video_get_backlight_type() behave as if a native backlight has already been registered. And add a new acpi_video_backlight_use_native() helper, which sets this to true, for use in native GPU backlight code. Changes in v2: - Replace adding a native parameter to acpi_video_get_backlight_type() with adding a new acpi_video_backlight_use_native() helper. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mika Penttilä <mpenttil@redhat.com>
2023-03-20 10:05:32 +00:00
static bool native_available;
static bool init_done;
static long video_caps;
/* Parse cmdline, dmi and acpi only once */
mutex_lock(&init_mutex);
if (!init_done) {
acpi_video_parse_cmdline();
dmi_check_system(video_detect_dmi_table);
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, find_video, NULL,
&video_caps, NULL);
nvidia_wmi_ec_present = nvidia_wmi_ec_supported();
init_done = true;
}
ACPI: video: Add acpi_video_backlight_use_native() helper Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2160456 Upstream Status: v6.1-rc1 commit 2600bfa3df9944562d43d1f17016832a6ffa3b38 Author: Hans de Goede <hdegoede@redhat.com> AuthorDate: Fri Apr 15 13:59:48 2022 +0200 Commit: Hans de Goede <hdegoede@redhat.com> CommitDate: Wed Aug 17 12:30:05 2022 +0200 ATM on x86 laptops where we want userspace to use the acpi_video backlight device we often 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, but registering 2 backlight devices for a single display really is undesirable. On x86 laptops where the native GPU backlight device should be used, the registering of other backlight devices is avoided by their drivers using acpi_video_get_backlight_type() and only registering their backlight if the return value matches their type. acpi_video_get_backlight_type() uses backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a native driver is available and will never return native if this returns false. This means that the GPU's native backlight registering code cannot just call acpi_video_get_backlight_type() to determine if it should register its backlight, since acpi_video_get_backlight_type() will never return native until the native backlight has already registered. To fix this add a new internal native function parameter to acpi_video_get_backlight_type(), which when set to true will make acpi_video_get_backlight_type() behave as if a native backlight has already been registered. And add a new acpi_video_backlight_use_native() helper, which sets this to true, for use in native GPU backlight code. Changes in v2: - Replace adding a native parameter to acpi_video_get_backlight_type() with adding a new acpi_video_backlight_use_native() helper. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mika Penttilä <mpenttil@redhat.com>
2023-03-20 10:05:32 +00:00
if (native)
native_available = true;
mutex_unlock(&init_mutex);
if (auto_detect)
*auto_detect = false;
/*
* The below heuristics / detection steps are in order of descending
* presedence. The commandline takes presedence over anything else.
*/
if (acpi_backlight_cmdline != acpi_backlight_undef)
return acpi_backlight_cmdline;
/* DMI quirks override any autodetection. */
if (acpi_backlight_dmi != acpi_backlight_undef)
return acpi_backlight_dmi;
/* Special cases such as nvidia_wmi_ec and apple gmux. */
if (nvidia_wmi_ec_present)
return acpi_backlight_nvidia_wmi_ec;
if (auto_detect)
*auto_detect = true;
/* 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 */
ACPI: video: Prefer native over vendor Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2186058 Conflicts: drivers/acpi/video_detect.c - second stanza did not apply at all. the final version of acpi_video_backlight_use_native() was already present in include/acpi/video.h so it was dropped. Omitted-fix: 9dcb34234b82 Omitted-fix: e6b3086fddc0 both are out of scope for this MR and will be backported as part of the next round of ACPI updates commit fb1836c91317e0770950260dfa91eb9b2170cb27 Author: Hans de Goede <hdegoede@redhat.com> Date: Mon Nov 14 15:44:59 2022 +0100 When available prefer native backlight control over vendor backlight control. Testing has shown that there are quite a few laptop models which rely on native backlight control (they don't have ACPI video bus backlight control) and on which acpi_osi_is_win8() returns false. Currently __acpi_video_get_backlight_type() returns vendor on these laptops, leading to an empty /sys/class/backlight. As a workaround for this acpi_video_backlight_use_native() has been temporarily changed to always return true. This re-introduces the problem of having multiple backlight devices under /sys/class/backlight for a single panel. Change __acpi_video_get_backlight_type() to prefer native over vendor when available. So that it returns native on these models. And change acpi_video_backlight_use_native() back to only return true when __acpi_video_get_backlight_type() returns native. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
2023-06-21 18:00:54 +00:00
if (native_available)
return acpi_backlight_native;
ACPI: video: Stop trying to use vendor backlight control on laptops from after ~2012 Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2186058 Upstream-status: git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git commit aa8a950a5d6b2094830aff834198777371ff91ff Author: Hans de Goede <hdegoede@redhat.com> Date: Thu Jun 8 11:12:58 2023 +0200 There have been 2 separate reports now about a non working "dell_backlight" device getting registered under /sys/class/backlight 1 report for a Raptor Lake based Dell and 1 report for a Meteor Lake (development) platform. On hw from the last 10 years dell-laptop will not register "dell_backlight" because acpi_video_get_backlight_type() will return acpi_backlight_video there if called before the GPU/kms driver loads. So it does not matter if the GPU driver's native backlight is registered after dell-laptop loads. But it seems that on the latest generation laptops the ACPI tables no longer contain acpi_video backlight control support which causes acpi_video_get_backlight_type() to return acpi_backlight_vendor causing "dell_backlight" to get registered if the dell-laptop module is loaded before the GPU/kms driver. Vendor specific backlight control like the "dell_backlight" device is only necessary on quite old hw (from before acpi_video backlight control was introduced). Work around "dell_backlight" registering on very new hw (where acpi_video backlight control seems to be no more) by making acpi_video_get_backlight_type() return acpi_backlight_none instead of acpi_backlight_vendor as final fallback when the ACPI tables have support for Windows 8 or later (laptops from after ~2012). Suggested-by: Matthew Garrett <mjg59@srcf.ucam.org> Reported-by: AceLan Kao <acelan.kao@canonical.com> Closes: https://lore.kernel.org/platform-driver-x86/20230607034331.576623-1-acelan.kao@canonical.com/ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
2023-06-21 18:02:47 +00:00
/*
* The vendor specific BIOS interfaces are only necessary for
* laptops from before ~2008.
*
* For laptops from ~2008 till ~2023 this point is never reached
* because on those (video_caps & ACPI_VIDEO_BACKLIGHT) above is true.
*
* Laptops from after ~2023 no longer support ACPI_VIDEO_BACKLIGHT,
* if this point is reached on those, this likely means that
* the GPU kms driver which sets native_available has not loaded yet.
*
* Returning acpi_backlight_vendor in this case is known to sometimes
* cause a non working vendor specific /sys/class/backlight device to
* get registered.
*
* Return acpi_backlight_none on laptops with ACPI tables written
* for Windows 8 (laptops from after ~2012) to avoid this problem.
*/
if (acpi_osi_is_win8())
return acpi_backlight_none;
ACPI: video: Prefer native over vendor Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2186058 Conflicts: drivers/acpi/video_detect.c - second stanza did not apply at all. the final version of acpi_video_backlight_use_native() was already present in include/acpi/video.h so it was dropped. Omitted-fix: 9dcb34234b82 Omitted-fix: e6b3086fddc0 both are out of scope for this MR and will be backported as part of the next round of ACPI updates commit fb1836c91317e0770950260dfa91eb9b2170cb27 Author: Hans de Goede <hdegoede@redhat.com> Date: Mon Nov 14 15:44:59 2022 +0100 When available prefer native backlight control over vendor backlight control. Testing has shown that there are quite a few laptop models which rely on native backlight control (they don't have ACPI video bus backlight control) and on which acpi_osi_is_win8() returns false. Currently __acpi_video_get_backlight_type() returns vendor on these laptops, leading to an empty /sys/class/backlight. As a workaround for this acpi_video_backlight_use_native() has been temporarily changed to always return true. This re-introduces the problem of having multiple backlight devices under /sys/class/backlight for a single panel. Change __acpi_video_get_backlight_type() to prefer native over vendor when available. So that it returns native on these models. And change acpi_video_backlight_use_native() back to only return true when __acpi_video_get_backlight_type() returns native. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Mark Langsdorf <mlangsdo@redhat.com>
2023-06-21 18:00:54 +00:00
/* No ACPI video/native (old hw), use vendor specific fw methods. */
return acpi_backlight_vendor;
}
ACPI: video: Add acpi_video_backlight_use_native() helper Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2160456 Upstream Status: v6.1-rc1 commit 2600bfa3df9944562d43d1f17016832a6ffa3b38 Author: Hans de Goede <hdegoede@redhat.com> AuthorDate: Fri Apr 15 13:59:48 2022 +0200 Commit: Hans de Goede <hdegoede@redhat.com> CommitDate: Wed Aug 17 12:30:05 2022 +0200 ATM on x86 laptops where we want userspace to use the acpi_video backlight device we often 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, but registering 2 backlight devices for a single display really is undesirable. On x86 laptops where the native GPU backlight device should be used, the registering of other backlight devices is avoided by their drivers using acpi_video_get_backlight_type() and only registering their backlight if the return value matches their type. acpi_video_get_backlight_type() uses backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a native driver is available and will never return native if this returns false. This means that the GPU's native backlight registering code cannot just call acpi_video_get_backlight_type() to determine if it should register its backlight, since acpi_video_get_backlight_type() will never return native until the native backlight has already registered. To fix this add a new internal native function parameter to acpi_video_get_backlight_type(), which when set to true will make acpi_video_get_backlight_type() behave as if a native backlight has already been registered. And add a new acpi_video_backlight_use_native() helper, which sets this to true, for use in native GPU backlight code. Changes in v2: - Replace adding a native parameter to acpi_video_get_backlight_type() with adding a new acpi_video_backlight_use_native() helper. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mika Penttilä <mpenttil@redhat.com>
2023-03-20 10:05:32 +00:00
EXPORT_SYMBOL(__acpi_video_get_backlight_type);
ACPI: video: Add acpi_video_backlight_use_native() helper Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2160456 Upstream Status: v6.1-rc1 commit 2600bfa3df9944562d43d1f17016832a6ffa3b38 Author: Hans de Goede <hdegoede@redhat.com> AuthorDate: Fri Apr 15 13:59:48 2022 +0200 Commit: Hans de Goede <hdegoede@redhat.com> CommitDate: Wed Aug 17 12:30:05 2022 +0200 ATM on x86 laptops where we want userspace to use the acpi_video backlight device we often 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, but registering 2 backlight devices for a single display really is undesirable. On x86 laptops where the native GPU backlight device should be used, the registering of other backlight devices is avoided by their drivers using acpi_video_get_backlight_type() and only registering their backlight if the return value matches their type. acpi_video_get_backlight_type() uses backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a native driver is available and will never return native if this returns false. This means that the GPU's native backlight registering code cannot just call acpi_video_get_backlight_type() to determine if it should register its backlight, since acpi_video_get_backlight_type() will never return native until the native backlight has already registered. To fix this add a new internal native function parameter to acpi_video_get_backlight_type(), which when set to true will make acpi_video_get_backlight_type() behave as if a native backlight has already been registered. And add a new acpi_video_backlight_use_native() helper, which sets this to true, for use in native GPU backlight code. Changes in v2: - Replace adding a native parameter to acpi_video_get_backlight_type() with adding a new acpi_video_backlight_use_native() helper. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Mika Penttilä <mpenttil@redhat.com>
2023-03-20 10:05:32 +00:00
/*
* Set the preferred backlight interface type based on DMI info.
* This function allows DMI blacklists to be implemented by external
* platform drivers instead of putting a big blacklist in video_detect.c
*/
void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
{
acpi_backlight_dmi = type;
/* Remove acpi-video backlight interface if it is no longer desired */
if (acpi_video_get_backlight_type() != acpi_backlight_video)
acpi_video_unregister_backlight();
}
EXPORT_SYMBOL(acpi_video_set_dmi_backlight_type);