* [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-21 21:24 ` Daniel Dadap
2022-07-12 19:38 ` [PATCH v2 02/29] drm/i915: Don't register backlight when another backlight should be used Hans de Goede
` (29 subsequent siblings)
30 siblings, 1 reply; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
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.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/video_detect.c | 24 ++++++++++++++++++++----
include/acpi/video.h | 5 +++++
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index becc198e4c22..4346c990022d 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -17,8 +17,9 @@
* Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
* sony_acpi,... can take care about backlight brightness.
*
- * Backlight drivers can use acpi_video_get_backlight_type() to determine
- * which driver should handle the backlight.
+ * 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
@@ -548,9 +549,10 @@ static int acpi_video_backlight_notify(struct notifier_block *nb,
* Arguably the native on win8 check should be done first, but that would
* be a behavior change, which may causes issues.
*/
-enum acpi_backlight_type acpi_video_get_backlight_type(void)
+static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
{
static DEFINE_MUTEX(init_mutex);
+ static bool native_available;
static bool init_done;
static long video_caps;
@@ -570,6 +572,8 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
backlight_notifier_registered = true;
init_done = true;
}
+ if (native)
+ native_available = true;
mutex_unlock(&init_mutex);
if (acpi_backlight_cmdline != acpi_backlight_undef)
@@ -581,13 +585,25 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
return acpi_backlight_vendor;
- if (acpi_osi_is_win8() && backlight_device_get_by_type(BACKLIGHT_RAW))
+ if (acpi_osi_is_win8() &&
+ (native_available || backlight_device_get_by_type(BACKLIGHT_RAW)))
return acpi_backlight_native;
return acpi_backlight_video;
}
+
+enum acpi_backlight_type acpi_video_get_backlight_type(void)
+{
+ return __acpi_video_get_backlight_type(false);
+}
EXPORT_SYMBOL(acpi_video_get_backlight_type);
+bool acpi_video_backlight_use_native(void)
+{
+ return __acpi_video_get_backlight_type(true) == acpi_backlight_native;
+}
+EXPORT_SYMBOL(acpi_video_backlight_use_native);
+
/*
* Set the preferred backlight interface type based on DMI info.
* This function allows DMI blacklists to be implemented by external
diff --git a/include/acpi/video.h b/include/acpi/video.h
index db8548ff03ce..4705e339c252 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -56,6 +56,7 @@ extern void acpi_video_unregister(void);
extern int acpi_video_get_edid(struct acpi_device *device, int type,
int device_id, void **edid);
extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
+extern bool acpi_video_backlight_use_native(void);
extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type);
/*
* Note: The value returned by acpi_video_handles_brightness_key_presses()
@@ -77,6 +78,10 @@ static inline enum acpi_backlight_type acpi_video_get_backlight_type(void)
{
return acpi_backlight_vendor;
}
+static inline bool acpi_video_backlight_use_native(void)
+{
+ return true;
+}
static inline void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
{
}
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper
2022-07-12 19:38 ` [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper Hans de Goede
@ 2022-07-21 21:24 ` Daniel Dadap
2022-07-21 21:30 ` Daniel Dadap
0 siblings, 1 reply; 58+ messages in thread
From: Daniel Dadap @ 2022-07-21 21:24 UTC (permalink / raw)
To: Hans de Goede, Ben Skeggs, Karol Herbst, Lyude,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher,
Christian König, Xinhui, Rafael J . Wysocki,
Mika Westerberg, Lukas Wunner, Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
On 7/12/22 14:38, Hans de Goede wrote:
> 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.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/acpi/video_detect.c | 24 ++++++++++++++++++++----
> include/acpi/video.h | 5 +++++
> 2 files changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
> index becc198e4c22..4346c990022d 100644
> --- a/drivers/acpi/video_detect.c
> +++ b/drivers/acpi/video_detect.c
> @@ -17,8 +17,9 @@
> * Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
> * sony_acpi,... can take care about backlight brightness.
> *
> - * Backlight drivers can use acpi_video_get_backlight_type() to determine
> - * which driver should handle the backlight.
> + * 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
> @@ -548,9 +549,10 @@ static int acpi_video_backlight_notify(struct notifier_block *nb,
> * Arguably the native on win8 check should be done first, but that would
> * be a behavior change, which may causes issues.
> */
> -enum acpi_backlight_type acpi_video_get_backlight_type(void)
> +static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
> {
> static DEFINE_MUTEX(init_mutex);
> + static bool native_available;
> static bool init_done;
> static long video_caps;
>
> @@ -570,6 +572,8 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
> backlight_notifier_registered = true;
> init_done = true;
> }
> + if (native)
> + native_available = true;
> mutex_unlock(&init_mutex);
>
> if (acpi_backlight_cmdline != acpi_backlight_undef)
> @@ -581,13 +585,25 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
> if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
> return acpi_backlight_vendor;
>
> - if (acpi_osi_is_win8() && backlight_device_get_by_type(BACKLIGHT_RAW))
> + if (acpi_osi_is_win8() &&
> + (native_available || backlight_device_get_by_type(BACKLIGHT_RAW)))
> return acpi_backlight_native;
>
> return acpi_backlight_video;
So I ran into a minor problem when testing the NVIDIA proprietary driver
against this change set, after checking
acpi_video_backlight_use_native() before registering the NVIDIA
proprietary driver's backlight handler. Namely, for the case where a
user installs the NVIDIA proprietary driver after the video.ko has
already registered its backlight handler, we end up with both the
firmware and native handlers registered simultaneously, since the ACPI
video driver no longer unregisters its backlight handler. In this state,
desktop environments end up preferring the registered but non-functional
firmware handler from video.ko. (Manually twiddling the sysfs interface
for the native NVIDIA handler works fine.) When rebooting the system
after installing the NVIDIA proprietary driver, it is able to register
its native handler before the delayed work to register the ACPI video
backlight handler fires, so we end up with only one (native) handler,
and userspace is happy.
Maybe this will be moot later on, when the existing sysfs interface is
deprecated, and it probably isn't a huge deal, since a reboot fixes
things (I imagine installing an in-tree DRM/KMS driver on an already
running kernel isn't really a thing, which is why this isn't a problem
with the in-tree drivers), but would it make sense to unregister the
ACPI video backlight handler here before returning
acpi_backlight_native? That way, we'll briefly end up with zero
backlight handlers rather than briefly ending up with two of them. Not
sure if that's really any better, though.
> }
> +
> +enum acpi_backlight_type acpi_video_get_backlight_type(void)
> +{
> + return __acpi_video_get_backlight_type(false);
> +}
> EXPORT_SYMBOL(acpi_video_get_backlight_type);
>
> +bool acpi_video_backlight_use_native(void)
> +{
> + return __acpi_video_get_backlight_type(true) == acpi_backlight_native;
> +}
> +EXPORT_SYMBOL(acpi_video_backlight_use_native);
> +
> /*
> * Set the preferred backlight interface type based on DMI info.
> * This function allows DMI blacklists to be implemented by external
> diff --git a/include/acpi/video.h b/include/acpi/video.h
> index db8548ff03ce..4705e339c252 100644
> --- a/include/acpi/video.h
> +++ b/include/acpi/video.h
> @@ -56,6 +56,7 @@ extern void acpi_video_unregister(void);
> extern int acpi_video_get_edid(struct acpi_device *device, int type,
> int device_id, void **edid);
> extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
> +extern bool acpi_video_backlight_use_native(void);
> extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type);
> /*
> * Note: The value returned by acpi_video_handles_brightness_key_presses()
> @@ -77,6 +78,10 @@ static inline enum acpi_backlight_type acpi_video_get_backlight_type(void)
> {
> return acpi_backlight_vendor;
> }
> +static inline bool acpi_video_backlight_use_native(void)
> +{
> + return true;
> +}
> static inline void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
> {
> }
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper
2022-07-21 21:24 ` Daniel Dadap
@ 2022-07-21 21:30 ` Daniel Dadap
2022-08-02 11:31 ` Hans de Goede
0 siblings, 1 reply; 58+ messages in thread
From: Daniel Dadap @ 2022-07-21 21:30 UTC (permalink / raw)
To: Hans de Goede, Ben Skeggs, Karol Herbst, Lyude,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher,
Christian König, Xinhui, Rafael J . Wysocki,
Mika Westerberg, Lukas Wunner, Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
On 7/21/22 16:24, Daniel Dadap wrote:
>
> On 7/12/22 14:38, Hans de Goede wrote:
>> 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.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/acpi/video_detect.c | 24 ++++++++++++++++++++----
>> include/acpi/video.h | 5 +++++
>> 2 files changed, 25 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>> index becc198e4c22..4346c990022d 100644
>> --- a/drivers/acpi/video_detect.c
>> +++ b/drivers/acpi/video_detect.c
>> @@ -17,8 +17,9 @@
>> * Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
>> * sony_acpi,... can take care about backlight brightness.
>> *
>> - * Backlight drivers can use acpi_video_get_backlight_type() to
>> determine
>> - * which driver should handle the backlight.
>> + * 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
>> @@ -548,9 +549,10 @@ static int acpi_video_backlight_notify(struct
>> notifier_block *nb,
>> * Arguably the native on win8 check should be done first, but that
>> would
>> * be a behavior change, which may causes issues.
>> */
>> -enum acpi_backlight_type acpi_video_get_backlight_type(void)
>> +static enum acpi_backlight_type __acpi_video_get_backlight_type(bool
>> native)
>> {
>> static DEFINE_MUTEX(init_mutex);
>> + static bool native_available;
>> static bool init_done;
>> static long video_caps;
>> @@ -570,6 +572,8 @@ enum acpi_backlight_type
>> acpi_video_get_backlight_type(void)
>> backlight_notifier_registered = true;
>> init_done = true;
>> }
>> + if (native)
>> + native_available = true;
>> mutex_unlock(&init_mutex);
>> if (acpi_backlight_cmdline != acpi_backlight_undef)
>> @@ -581,13 +585,25 @@ enum acpi_backlight_type
>> acpi_video_get_backlight_type(void)
>> if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
>> return acpi_backlight_vendor;
>> - if (acpi_osi_is_win8() &&
>> backlight_device_get_by_type(BACKLIGHT_RAW))
>> + if (acpi_osi_is_win8() &&
>> + (native_available ||
>> backlight_device_get_by_type(BACKLIGHT_RAW)))
>> return acpi_backlight_native;
>> return acpi_backlight_video;
>
>
> So I ran into a minor problem when testing the NVIDIA proprietary
> driver against this change set, after checking
> acpi_video_backlight_use_native() before registering the NVIDIA
> proprietary driver's backlight handler. Namely, for the case where a
> user installs the NVIDIA proprietary driver after the video.ko has
> already registered its backlight handler, we end up with both the
> firmware and native handlers registered simultaneously, since the ACPI
> video driver no longer unregisters its backlight handler. In this
> state, desktop environments end up preferring the registered but
> non-functional firmware handler from video.ko. (Manually twiddling the
> sysfs interface for the native NVIDIA handler works fine.) When
> rebooting the system after installing the NVIDIA proprietary driver,
> it is able to register its native handler before the delayed work to
> register the ACPI video backlight handler fires, so we end up with
> only one (native) handler, and userspace is happy.
>
> Maybe this will be moot later on, when the existing sysfs interface is
> deprecated, and it probably isn't a huge deal, since a reboot fixes
> things (I imagine installing an in-tree DRM/KMS driver on an already
> running kernel isn't really a thing, which is why this isn't a problem
> with the in-tree drivers), but would it make sense to unregister the
> ACPI video backlight handler here before returning
> acpi_backlight_native? That way, we'll briefly end up with zero
> backlight handlers rather than briefly ending up with two of them. Not
> sure if that's really any better, though.
>
Thinking about this a little more, maybe it's better not to overly
complicate things, and just assert that users of the NVIDIA proprietary
driver will need to reboot after installation in order to get the
backlight working, at least until we get further along in this effort
and the backlight interface transitions to the DRM connector property
you have proposed.
>
>> }
>> +
>> +enum acpi_backlight_type acpi_video_get_backlight_type(void)
>> +{
>> + return __acpi_video_get_backlight_type(false);
>> +}
>> EXPORT_SYMBOL(acpi_video_get_backlight_type);
>> +bool acpi_video_backlight_use_native(void)
>> +{
>> + return __acpi_video_get_backlight_type(true) ==
>> acpi_backlight_native;
>> +}
>> +EXPORT_SYMBOL(acpi_video_backlight_use_native);
>> +
>> /*
>> * Set the preferred backlight interface type based on DMI info.
>> * This function allows DMI blacklists to be implemented by external
>> diff --git a/include/acpi/video.h b/include/acpi/video.h
>> index db8548ff03ce..4705e339c252 100644
>> --- a/include/acpi/video.h
>> +++ b/include/acpi/video.h
>> @@ -56,6 +56,7 @@ extern void acpi_video_unregister(void);
>> extern int acpi_video_get_edid(struct acpi_device *device, int type,
>> int device_id, void **edid);
>> extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
>> +extern bool acpi_video_backlight_use_native(void);
>> extern void acpi_video_set_dmi_backlight_type(enum
>> acpi_backlight_type type);
>> /*
>> * Note: The value returned by
>> acpi_video_handles_brightness_key_presses()
>> @@ -77,6 +78,10 @@ static inline enum acpi_backlight_type
>> acpi_video_get_backlight_type(void)
>> {
>> return acpi_backlight_vendor;
>> }
>> +static inline bool acpi_video_backlight_use_native(void)
>> +{
>> + return true;
>> +}
>> static inline void acpi_video_set_dmi_backlight_type(enum
>> acpi_backlight_type type)
>> {
>> }
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper
2022-07-21 21:30 ` Daniel Dadap
@ 2022-08-02 11:31 ` Hans de Goede
2022-08-02 16:49 ` Daniel Dadap
0 siblings, 1 reply; 58+ messages in thread
From: Hans de Goede @ 2022-08-02 11:31 UTC (permalink / raw)
To: Daniel Dadap, Ben Skeggs, Karol Herbst, Lyude, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Hi Daniel,
On 7/21/22 23:30, Daniel Dadap wrote:
>
> On 7/21/22 16:24, Daniel Dadap wrote:
>>
>> On 7/12/22 14:38, Hans de Goede wrote:
>>> 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.
>>>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> ---
>>> drivers/acpi/video_detect.c | 24 ++++++++++++++++++++----
>>> include/acpi/video.h | 5 +++++
>>> 2 files changed, 25 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>>> index becc198e4c22..4346c990022d 100644
>>> --- a/drivers/acpi/video_detect.c
>>> +++ b/drivers/acpi/video_detect.c
>>> @@ -17,8 +17,9 @@
>>> * Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
>>> * sony_acpi,... can take care about backlight brightness.
>>> *
>>> - * Backlight drivers can use acpi_video_get_backlight_type() to determine
>>> - * which driver should handle the backlight.
>>> + * 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
>>> @@ -548,9 +549,10 @@ static int acpi_video_backlight_notify(struct notifier_block *nb,
>>> * Arguably the native on win8 check should be done first, but that would
>>> * be a behavior change, which may causes issues.
>>> */
>>> -enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>> +static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>> {
>>> static DEFINE_MUTEX(init_mutex);
>>> + static bool native_available;
>>> static bool init_done;
>>> static long video_caps;
>>> @@ -570,6 +572,8 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>> backlight_notifier_registered = true;
>>> init_done = true;
>>> }
>>> + if (native)
>>> + native_available = true;
>>> mutex_unlock(&init_mutex);
>>> if (acpi_backlight_cmdline != acpi_backlight_undef)
>>> @@ -581,13 +585,25 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>> if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
>>> return acpi_backlight_vendor;
>>> - if (acpi_osi_is_win8() && backlight_device_get_by_type(BACKLIGHT_RAW))
>>> + if (acpi_osi_is_win8() &&
>>> + (native_available || backlight_device_get_by_type(BACKLIGHT_RAW)))
>>> return acpi_backlight_native;
>>> return acpi_backlight_video;
>>
>>
>> So I ran into a minor problem when testing the NVIDIA proprietary driver against this change set, after checking acpi_video_backlight_use_native() before registering the NVIDIA proprietary driver's backlight handler. Namely, for the case where a user installs the NVIDIA proprietary driver after the video.ko has already registered its backlight handler, we end up with both the firmware and native handlers registered simultaneously, since the ACPI video driver no longer unregisters its backlight handler. In this state, desktop environments end up preferring the registered but non-functional firmware handler from video.ko. (Manually twiddling the sysfs interface for the native NVIDIA handler works fine.) When rebooting the system after installing the NVIDIA proprietary driver, it is able to register its native handler before the delayed work to register the ACPI video backlight handler fires, so we end up with only one (native) handler, and userspace is happy.
>>
>> Maybe this will be moot later on, when the existing sysfs interface is deprecated, and it probably isn't a huge deal, since a reboot fixes things (I imagine installing an in-tree DRM/KMS driver on an already running kernel isn't really a thing, which is why this isn't a problem with the in-tree drivers), but would it make sense to unregister the ACPI video backlight handler here before returning acpi_backlight_native? That way, we'll briefly end up with zero backlight handlers rather than briefly ending up with two of them. Not sure if that's really any better, though.
>>
>
> Thinking about this a little more, maybe it's better not to overly complicate things, and just assert that users of the NVIDIA proprietary driver will need to reboot after installation in order to get the backlight working, at least until we get further along in this effort and the backlight interface transitions to the DRM connector property you have proposed.
Right, this series stops unregistering the acpi_video# /sys/class/backlight
devices because the idea is to never register them in the first place.
Registering them in the first place causes 2 problems:
1. It causes userspace to see udev events for the register + unregister
and by the time the systemd backlight level save/restore helper runs
from udev the unregister has already happened and it logs ugly errors.
More in general this kinda racy behavior just is ugly.
2. On some hw merely registering the backlight device, which I think
at least tries to retrieve the current level through ACPI, is causing
issues. So now we have DMI quirks to force the native backlight on
some devices, even though the heuristics also say native eventually,
just to avoid the race. Avoiding the add + remove dance allows
us to drop a bunch of quirks and likely also fixes issues on other
devices which we don't yet know need the quirk.
So this patch-set changes the acpi_video.c code to no longer register
the acpi_video# backlight devices at init time *at all*. Instead native
drivers are supposed to now call acpi_video_register_backlight()
when they have found an internal panel. But to avoid this causing
the acpi_video# backlight devices to not show up at all in some
cases (e.g. native kms drivers blacklisted) the acpi_video code
also calls acpi_video_register_backlight() itself after 8 seconds.
I believe this is what you are hitting, the 8 seconds have passed
before the nvidia driver calls acpi_video_backlight_use_native(),
so the acpi_video# backlight devices have registered (and no longer
go away).
This is not only a problem when installing the nvidia binary driver
for the first time. It can also be a problem if the binary driver
is not in the initrd and leaving the initrd takes longer then
8 seconds, say because of a diskcrypt password. So I believe that
this really can be a problem with the nvidia binary driver.
But I think this is easy to fix. We could make the 8 second
delay configurable by replacing the ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY
define with a module-parameter; and we could make "0" as value mean
that acpi_video.c will never call acpi_video_register_backlight()
itself.
Since the various (also counting distor packaging) nvidia binary
driver installers already all modify the kernel commandline to
blacklist nouveau, then the installers can just also pass this
parameter and then acpi_video.c will never register the acpi_video#.
This does mean that the nvidia binary driver then must call
acpi_video_register_backlight() when an internal panel is found.
Note the current patches to amdgpu/nouveau skip the calling of
acpi_video_register_backlight() when
the acpi_video_backlight_use_native() call returns true and they
have registered their own backlight. But calling it always is ok
*as long as the driver is driving the laptops internal panel* !
acpi_video_register_backlight() contains:
if (acpi_video_get_backlight_type() != acpi_backlight_video)
return 0;
So calling it when a native backlight has already been registered
is a no-op.
Please let me know if the proposed solution works for you and
if you want me to make ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY a
module-option for the next version.
Regards,
Hans
p.s.
I think that eventually I might even try to make the new
module-param default to 0 / default to not having acpi_video.c
do the registering itself ever and see how that goes...
>>> }
>>> +
>>> +enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>> +{
>>> + return __acpi_video_get_backlight_type(false);
>>> +}
>>> EXPORT_SYMBOL(acpi_video_get_backlight_type);
>>> +bool acpi_video_backlight_use_native(void)
>>> +{
>>> + return __acpi_video_get_backlight_type(true) == acpi_backlight_native;
>>> +}
>>> +EXPORT_SYMBOL(acpi_video_backlight_use_native);
>>> +
>>> /*
>>> * Set the preferred backlight interface type based on DMI info.
>>> * This function allows DMI blacklists to be implemented by external
>>> diff --git a/include/acpi/video.h b/include/acpi/video.h
>>> index db8548ff03ce..4705e339c252 100644
>>> --- a/include/acpi/video.h
>>> +++ b/include/acpi/video.h
>>> @@ -56,6 +56,7 @@ extern void acpi_video_unregister(void);
>>> extern int acpi_video_get_edid(struct acpi_device *device, int type,
>>> int device_id, void **edid);
>>> extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
>>> +extern bool acpi_video_backlight_use_native(void);
>>> extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type);
>>> /*
>>> * Note: The value returned by acpi_video_handles_brightness_key_presses()
>>> @@ -77,6 +78,10 @@ static inline enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>> {
>>> return acpi_backlight_vendor;
>>> }
>>> +static inline bool acpi_video_backlight_use_native(void)
>>> +{
>>> + return true;
>>> +}
>>> static inline void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
>>> {
>>> }
>
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper
2022-08-02 11:31 ` Hans de Goede
@ 2022-08-02 16:49 ` Daniel Dadap
2022-08-17 15:05 ` Hans de Goede
0 siblings, 1 reply; 58+ messages in thread
From: Daniel Dadap @ 2022-08-02 16:49 UTC (permalink / raw)
To: Hans de Goede, Ben Skeggs, Karol Herbst, Lyude,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher,
Christian König, Xinhui, Rafael J . Wysocki,
Mika Westerberg, Lukas Wunner, Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
On 8/2/22 06:31, Hans de Goede wrote:
> Hi Daniel,
>
> On 7/21/22 23:30, Daniel Dadap wrote:
>> On 7/21/22 16:24, Daniel Dadap wrote:
>>> On 7/12/22 14:38, Hans de Goede wrote:
>>>> 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.
>>>>
>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>> ---
>>>> drivers/acpi/video_detect.c | 24 ++++++++++++++++++++----
>>>> include/acpi/video.h | 5 +++++
>>>> 2 files changed, 25 insertions(+), 4 deletions(-)
>>>>
>>>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>>>> index becc198e4c22..4346c990022d 100644
>>>> --- a/drivers/acpi/video_detect.c
>>>> +++ b/drivers/acpi/video_detect.c
>>>> @@ -17,8 +17,9 @@
>>>> * Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
>>>> * sony_acpi,... can take care about backlight brightness.
>>>> *
>>>> - * Backlight drivers can use acpi_video_get_backlight_type() to determine
>>>> - * which driver should handle the backlight.
>>>> + * 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
>>>> @@ -548,9 +549,10 @@ static int acpi_video_backlight_notify(struct notifier_block *nb,
>>>> * Arguably the native on win8 check should be done first, but that would
>>>> * be a behavior change, which may causes issues.
>>>> */
>>>> -enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>> +static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>>> {
>>>> static DEFINE_MUTEX(init_mutex);
>>>> + static bool native_available;
>>>> static bool init_done;
>>>> static long video_caps;
>>>> @@ -570,6 +572,8 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>> backlight_notifier_registered = true;
>>>> init_done = true;
>>>> }
>>>> + if (native)
>>>> + native_available = true;
>>>> mutex_unlock(&init_mutex);
>>>> if (acpi_backlight_cmdline != acpi_backlight_undef)
>>>> @@ -581,13 +585,25 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>> if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
>>>> return acpi_backlight_vendor;
>>>> - if (acpi_osi_is_win8() && backlight_device_get_by_type(BACKLIGHT_RAW))
>>>> + if (acpi_osi_is_win8() &&
>>>> + (native_available || backlight_device_get_by_type(BACKLIGHT_RAW)))
>>>> return acpi_backlight_native;
>>>> return acpi_backlight_video;
>>>
>>> So I ran into a minor problem when testing the NVIDIA proprietary driver against this change set, after checking acpi_video_backlight_use_native() before registering the NVIDIA proprietary driver's backlight handler. Namely, for the case where a user installs the NVIDIA proprietary driver after the video.ko has already registered its backlight handler, we end up with both the firmware and native handlers registered simultaneously, since the ACPI video driver no longer unregisters its backlight handler. In this state, desktop environments end up preferring the registered but non-functional firmware handler from video.ko. (Manually twiddling the sysfs interface for the native NVIDIA handler works fine.) When rebooting the system after installing the NVIDIA proprietary driver, it is able to register its native handler before the delayed work to register the ACPI video backlight handler fires, so we end up with only one (native) handler, and userspace is happy.
>>>
>>> Maybe this will be moot later on, when the existing sysfs interface is deprecated, and it probably isn't a huge deal, since a reboot fixes things (I imagine installing an in-tree DRM/KMS driver on an already running kernel isn't really a thing, which is why this isn't a problem with the in-tree drivers), but would it make sense to unregister the ACPI video backlight handler here before returning acpi_backlight_native? That way, we'll briefly end up with zero backlight handlers rather than briefly ending up with two of them. Not sure if that's really any better, though.
>>>
>> Thinking about this a little more, maybe it's better not to overly complicate things, and just assert that users of the NVIDIA proprietary driver will need to reboot after installation in order to get the backlight working, at least until we get further along in this effort and the backlight interface transitions to the DRM connector property you have proposed.
> Right, this series stops unregistering the acpi_video# /sys/class/backlight
> devices because the idea is to never register them in the first place.
>
> Registering them in the first place causes 2 problems:
>
> 1. It causes userspace to see udev events for the register + unregister
> and by the time the systemd backlight level save/restore helper runs
> from udev the unregister has already happened and it logs ugly errors.
> More in general this kinda racy behavior just is ugly.
>
> 2. On some hw merely registering the backlight device, which I think
> at least tries to retrieve the current level through ACPI, is causing
> issues. So now we have DMI quirks to force the native backlight on
> some devices, even though the heuristics also say native eventually,
> just to avoid the race. Avoiding the add + remove dance allows
> us to drop a bunch of quirks and likely also fixes issues on other
> devices which we don't yet know need the quirk.
Yes, those sound like good reasons to avoid registering the ACPI video
backlight driver wherever possible.
> So this patch-set changes the acpi_video.c code to no longer register
> the acpi_video# backlight devices at init time *at all*. Instead native
> drivers are supposed to now call acpi_video_register_backlight()
> when they have found an internal panel. But to avoid this causing
> the acpi_video# backlight devices to not show up at all in some
> cases (e.g. native kms drivers blacklisted) the acpi_video code
> also calls acpi_video_register_backlight() itself after 8 seconds.
>
> I believe this is what you are hitting, the 8 seconds have passed
> before the nvidia driver calls acpi_video_backlight_use_native(),
> so the acpi_video# backlight devices have registered (and no longer
> go away).
>
> This is not only a problem when installing the nvidia binary driver
> for the first time. It can also be a problem if the binary driver
> is not in the initrd and leaving the initrd takes longer then
> 8 seconds, say because of a diskcrypt password. So I believe that
> this really can be a problem with the nvidia binary driver.
Hmm. I hadn't considered the case of the binary driver being absent from
the initrd, and the possibility of the transition out of the initrd
happening after the timeout. Yes, this is a bigger problem than the
"only after first installing the driver" scenario I ran into.
> But I think this is easy to fix. We could make the 8 second
> delay configurable by replacing the ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY
> define with a module-parameter; and we could make "0" as value mean
> that acpi_video.c will never call acpi_video_register_backlight()
> itself.
>
> Since the various (also counting distor packaging) nvidia binary
> driver installers already all modify the kernel commandline to
> blacklist nouveau, then the installers can just also pass this
> parameter and then acpi_video.c will never register the acpi_video#.
This sounds like a reasonable compromise, but I worry that it may be
difficult to determine whether a system definitely doesn't need the ACPI
video backlight driver. On the other hand, the last system that I recall
personally seeing that did use the ACPI video backlight driver was a
little over 10 years ago, so it's possible that there are no systems
which use that driver which are supported by current versions of the
NVIDIA proprietary driver. I'll have to do some research to determine
what types of systems actually used video.ko's backlight driver, unless
you happen to know already.
> This does mean that the nvidia binary driver then must call
> acpi_video_register_backlight() when an internal panel is found.
>
> Note the current patches to amdgpu/nouveau skip the calling of
> acpi_video_register_backlight() when
> the acpi_video_backlight_use_native() call returns true and they
> have registered their own backlight. But calling it always is ok
> *as long as the driver is driving the laptops internal panel* !
>
> acpi_video_register_backlight() contains:
>
> if (acpi_video_get_backlight_type() != acpi_backlight_video)
> return 0;
>
> So calling it when a native backlight has already been registered
> is a no-op.
The NVIDIA proprietary driver will already know when it has registered
its own backlight handler, so there probably isn't any need to always
call it when driving an internal panel. I'll have to double-check to see
if we have already determined whether a panel is connected before
registering the backlight handler: I am pretty certain that is the case.
One further potential difficulty that I anticipate is that not all
dynamic mux systems use the EC backlight driver (or a similar,
GPU-agnostic driver), and rather have whichever GPU happens to be
connected at the time be responsible for the backlight. I had initially
thought that supporting the EC backlight interface was a requirement for
OEMs to implement dynamic mux support, but I recently learned this is
not true in all cases. On Windows, this requires coordinating the
backlight controls of the two GPU drivers across a mux switch, to load
the state of the switched-away-from GPU and set it on the switched-to
GPU. I imagine for these systems we may need to do some similar
save/restore, probably managed by vga-switcheroo, but it would require
having both GPU drivers register their own native backlight handlers
(and possibly while one of them is not connected to the panel).
Dynamic mux switching isn't actually supported on Linux, yet, so we
should be able to kick this particular can a little further down the
road, but in the meantime we should probably start planning for how best
to handle this sort of system under the "only one backlight handler per
panel" model. Maybe the vga-switcheroo handler can register its own
backlight handler, that then negotiates the actual backlight settings
between the relevant GPU drivers, possibly through a new vga-switcheroo
client callback. I'll have to think about this a bit more.
> Please let me know if the proposed solution works for you and
> if you want me to make ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY a
> module-option for the next version.
I do think it should be workable, apart from the concern I mentioned
above about knowing when to set the module option to disable the ACPI
video backlight driver. I'll need to get a better understanding of
exactly which systems actually use that driver.
> Regards,
>
> Hans
>
>
> p.s.
>
> I think that eventually I might even try to make the new
> module-param default to 0 / default to not having acpi_video.c
> do the registering itself ever and see how that goes...
Would the GPU drivers then be responsible for calling acpi_video_register_backlight() again? My understanding was that part of the intention here was to make that no longer necessary.
>
>>>> }
>>>> +
>>>> +enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>> +{
>>>> + return __acpi_video_get_backlight_type(false);
>>>> +}
>>>> EXPORT_SYMBOL(acpi_video_get_backlight_type);
>>>> +bool acpi_video_backlight_use_native(void)
>>>> +{
>>>> + return __acpi_video_get_backlight_type(true) == acpi_backlight_native;
>>>> +}
>>>> +EXPORT_SYMBOL(acpi_video_backlight_use_native);
>>>> +
>>>> /*
>>>> * Set the preferred backlight interface type based on DMI info.
>>>> * This function allows DMI blacklists to be implemented by external
>>>> diff --git a/include/acpi/video.h b/include/acpi/video.h
>>>> index db8548ff03ce..4705e339c252 100644
>>>> --- a/include/acpi/video.h
>>>> +++ b/include/acpi/video.h
>>>> @@ -56,6 +56,7 @@ extern void acpi_video_unregister(void);
>>>> extern int acpi_video_get_edid(struct acpi_device *device, int type,
>>>> int device_id, void **edid);
>>>> extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
>>>> +extern bool acpi_video_backlight_use_native(void);
>>>> extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type);
>>>> /*
>>>> * Note: The value returned by acpi_video_handles_brightness_key_presses()
>>>> @@ -77,6 +78,10 @@ static inline enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>> {
>>>> return acpi_backlight_vendor;
>>>> }
>>>> +static inline bool acpi_video_backlight_use_native(void)
>>>> +{
>>>> + return true;
>>>> +}
>>>> static inline void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
>>>> {
>>>> }
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper
2022-08-02 16:49 ` Daniel Dadap
@ 2022-08-17 15:05 ` Hans de Goede
2022-08-17 20:18 ` Daniel Dadap
0 siblings, 1 reply; 58+ messages in thread
From: Hans de Goede @ 2022-08-17 15:05 UTC (permalink / raw)
To: Daniel Dadap, Ben Skeggs, Karol Herbst, Lyude, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Hi Daniel,
On 8/2/22 18:49, Daniel Dadap wrote:
> On 8/2/22 06:31, Hans de Goede wrote:
>> Hi Daniel,
>>
>> On 7/21/22 23:30, Daniel Dadap wrote:
>>> On 7/21/22 16:24, Daniel Dadap wrote:
>>>> On 7/12/22 14:38, Hans de Goede wrote:
>>>>> 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.
>>>>>
>>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>>> ---
>>>>> drivers/acpi/video_detect.c | 24 ++++++++++++++++++++----
>>>>> include/acpi/video.h | 5 +++++
>>>>> 2 files changed, 25 insertions(+), 4 deletions(-)
>>>>>
>>>>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>>>>> index becc198e4c22..4346c990022d 100644
>>>>> --- a/drivers/acpi/video_detect.c
>>>>> +++ b/drivers/acpi/video_detect.c
>>>>> @@ -17,8 +17,9 @@
>>>>> * Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
>>>>> * sony_acpi,... can take care about backlight brightness.
>>>>> *
>>>>> - * Backlight drivers can use acpi_video_get_backlight_type() to determine
>>>>> - * which driver should handle the backlight.
>>>>> + * 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
>>>>> @@ -548,9 +549,10 @@ static int acpi_video_backlight_notify(struct notifier_block *nb,
>>>>> * Arguably the native on win8 check should be done first, but that would
>>>>> * be a behavior change, which may causes issues.
>>>>> */
>>>>> -enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>>> +static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>>>> {
>>>>> static DEFINE_MUTEX(init_mutex);
>>>>> + static bool native_available;
>>>>> static bool init_done;
>>>>> static long video_caps;
>>>>> @@ -570,6 +572,8 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>>> backlight_notifier_registered = true;
>>>>> init_done = true;
>>>>> }
>>>>> + if (native)
>>>>> + native_available = true;
>>>>> mutex_unlock(&init_mutex);
>>>>> if (acpi_backlight_cmdline != acpi_backlight_undef)
>>>>> @@ -581,13 +585,25 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>>> if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
>>>>> return acpi_backlight_vendor;
>>>>> - if (acpi_osi_is_win8() && backlight_device_get_by_type(BACKLIGHT_RAW))
>>>>> + if (acpi_osi_is_win8() &&
>>>>> + (native_available || backlight_device_get_by_type(BACKLIGHT_RAW)))
>>>>> return acpi_backlight_native;
>>>>> return acpi_backlight_video;
>>>>
>>>> So I ran into a minor problem when testing the NVIDIA proprietary driver against this change set, after checking acpi_video_backlight_use_native() before registering the NVIDIA proprietary driver's backlight handler. Namely, for the case where a user installs the NVIDIA proprietary driver after the video.ko has already registered its backlight handler, we end up with both the firmware and native handlers registered simultaneously, since the ACPI video driver no longer unregisters its backlight handler. In this state, desktop environments end up preferring the registered but non-functional firmware handler from video.ko. (Manually twiddling the sysfs interface for the native NVIDIA handler works fine.) When rebooting the system after installing the NVIDIA proprietary driver, it is able to register its native handler before the delayed work to register the ACPI video backlight handler fires, so we end up with only one (native) handler, and userspace is happy.
>>>>
>>>> Maybe this will be moot later on, when the existing sysfs interface is deprecated, and it probably isn't a huge deal, since a reboot fixes things (I imagine installing an in-tree DRM/KMS driver on an already running kernel isn't really a thing, which is why this isn't a problem with the in-tree drivers), but would it make sense to unregister the ACPI video backlight handler here before returning acpi_backlight_native? That way, we'll briefly end up with zero backlight handlers rather than briefly ending up with two of them. Not sure if that's really any better, though.
>>>>
>>> Thinking about this a little more, maybe it's better not to overly complicate things, and just assert that users of the NVIDIA proprietary driver will need to reboot after installation in order to get the backlight working, at least until we get further along in this effort and the backlight interface transitions to the DRM connector property you have proposed.
>> Right, this series stops unregistering the acpi_video# /sys/class/backlight
>> devices because the idea is to never register them in the first place.
>>
>> Registering them in the first place causes 2 problems:
>>
>> 1. It causes userspace to see udev events for the register + unregister
>> and by the time the systemd backlight level save/restore helper runs
>> from udev the unregister has already happened and it logs ugly errors.
>> More in general this kinda racy behavior just is ugly.
>>
>> 2. On some hw merely registering the backlight device, which I think
>> at least tries to retrieve the current level through ACPI, is causing
>> issues. So now we have DMI quirks to force the native backlight on
>> some devices, even though the heuristics also say native eventually,
>> just to avoid the race. Avoiding the add + remove dance allows
>> us to drop a bunch of quirks and likely also fixes issues on other
>> devices which we don't yet know need the quirk.
>
>
> Yes, those sound like good reasons to avoid registering the ACPI video backlight driver wherever possible.
>
>
>> So this patch-set changes the acpi_video.c code to no longer register
>> the acpi_video# backlight devices at init time *at all*. Instead native
>> drivers are supposed to now call acpi_video_register_backlight()
>> when they have found an internal panel. But to avoid this causing
>> the acpi_video# backlight devices to not show up at all in some
>> cases (e.g. native kms drivers blacklisted) the acpi_video code
>> also calls acpi_video_register_backlight() itself after 8 seconds.
>>
>> I believe this is what you are hitting, the 8 seconds have passed
>> before the nvidia driver calls acpi_video_backlight_use_native(),
>> so the acpi_video# backlight devices have registered (and no longer
>> go away).
>>
>> This is not only a problem when installing the nvidia binary driver
>> for the first time. It can also be a problem if the binary driver
>> is not in the initrd and leaving the initrd takes longer then
>> 8 seconds, say because of a diskcrypt password. So I believe that
>> this really can be a problem with the nvidia binary driver.
>
>
> Hmm. I hadn't considered the case of the binary driver being absent from the initrd, and the possibility of the transition out of the initrd happening after the timeout. Yes, this is a bigger problem than the "only after first installing the driver" scenario I ran into.
>
>
>> But I think this is easy to fix. We could make the 8 second
>> delay configurable by replacing the ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY
>> define with a module-parameter; and we could make "0" as value mean
>> that acpi_video.c will never call acpi_video_register_backlight()
>> itself.
>>
>> Since the various (also counting distor packaging) nvidia binary
>> driver installers already all modify the kernel commandline to
>> blacklist nouveau, then the installers can just also pass this
>> parameter and then acpi_video.c will never register the acpi_video#.
>
>
> This sounds like a reasonable compromise, but I worry that it may be difficult to determine whether a system definitely doesn't need the ACPI video backlight driver. On the other hand, the last system that I recall personally seeing that did use the ACPI video backlight driver was a little over 10 years ago, so it's possible that there are no systems which use that driver which are supported by current versions of the NVIDIA proprietary driver. I'll have to do some research to determine what types of systems actually used video.ko's backlight driver, unless you happen to know already.
Generally the backlight control method / fw interface to use depends
on the Era of the laptop:
1. pre Windows XP Era laptops use vendor specific ACPI or SMBIOS interfaces
such as those dealt with by dell-laptop, thinkpad-acpi, etc.
2. Windows XP Era (which ends with Win 8/Vista) laptops used the ACPI video
bus backlight interface
3. Win 8/Vista and later Era laptops use the GPU driver's native backlight
support instead of some firmware interface
This is generalizing things a bit. E.g. esp during the transition between
the Eras often both Era methods (e.g vendor + acpi-video) would work
equally well.
So wrt your questions, generally speaking any laptops which were
designed for Win8/Vista or newer no longer use the ACPI video
interface.
So yes it is possible that there are no systems supported by
the latest NVIDIA proprietary driver which need ACPI video at
all. OTOH on dual-GPU setups with muxes it is not unreasonable
for ACPI video to actually be the driver which needs to be
used in case e.g. the backlight control is hooked up to the
EC so that it does not need to go through the mux. Basically
ACPI video Should work well (if the ACPI tables are written
properly) in setups where the EC drivers the backlight and
where this the GPU driver cannot control it directly. So
their might very well be pre nvidia-wmi-ec-backlight laptops
which use ACPI video to control the brightness through the EC.
>> This does mean that the nvidia binary driver then must call
>> acpi_video_register_backlight() when an internal panel is found.
>>
>> Note the current patches to amdgpu/nouveau skip the calling of
>> acpi_video_register_backlight() when
>> the acpi_video_backlight_use_native() call returns true and they
>> have registered their own backlight. But calling it always is ok
>> *as long as the driver is driving the laptops internal panel* !
>>
>> acpi_video_register_backlight() contains:
>>
>> if (acpi_video_get_backlight_type() != acpi_backlight_video)
>> return 0;
>>
>> So calling it when a native backlight has already been registered
>> is a no-op.
>
>
> The NVIDIA proprietary driver will already know when it has registered its own backlight handler, so there probably isn't any need to always call it when driving an internal panel.
Ok.
> I'll have to double-check to see if we have already determined whether a panel is connected before registering the backlight handler: I am pretty certain that is the case.
Yeah registering a backlight handler when there is no internal panel would be weird.
> One further potential difficulty that I anticipate is that not all dynamic mux systems use the EC backlight driver (or a similar, GPU-agnostic driver), and rather have whichever GPU happens to be connected at the time be responsible for the backlight. I had initially thought that supporting the EC backlight interface was a requirement for OEMs to implement dynamic mux support, but I recently learned this is not true in all cases. On Windows, this requires coordinating the backlight controls of the two GPU drivers across a mux switch, to load the state of the switched-away-from GPU and set it on the switched-to GPU. I imagine for these systems we may need to do some similar save/restore, probably managed by vga-switcheroo, but it would require having both GPU drivers register their own native backlight handlers (and possibly while one of them is not connected to the panel).
Right, systems where the backlight control basically gets muxed from one GPU to the other GPU together with the panel's video-data lines exist. Currently Linux already register both native GPU backlight handlers in this case. e.g. /sys/class/backlight/intel_backlight and /sys/class/backlight/nouveau_bl.
Userspace (atleast GNOME) has code which checks which GPU is actually connected to the panel using the panel's drm connector's status on each GPU (only one of which should report connected) and then uses the backlight interface associated with the connected connector.
> Dynamic mux switching isn't actually supported on Linux, yet, so we should be able to kick this particular can a little further down the road, but in the meantime we should probably start planning for how best to handle this sort of system under the "only one backlight handler per panel" model. Maybe the vga-switcheroo handler can register its own backlight handler, that then negotiates the actual backlight settings between the relevant GPU drivers, possibly through a new vga-switcheroo client callback. I'll have to think about this a bit more.
The "only one backlight handler per panel" model is actualy "only one backlight handler per panel"-connector since the new API uses drm properties on the drm connector object. With 2 GPUs both using their native backlight control there will be 2 connectors and userspace will/must use the one which is actually reporting that it is connected to the panel so this will work fine.
If anything the nvidia-wmi-ec-backlight case is a but more tricky, the "only one backlight handler per panel" thing is actually more of a "only one backlight handler per laptop" rule which is intended for (to be written) drm helpers for the new properties to be able to get the handler from the backlight class in the non native case by just taking the first registered backlight handler.
This means that in a dual GPU setup with nvidia-wmi-ec-backlight both GPU's panel connector objects will have their brightness properties pointing to / proxying the same backlight class device. Userspace should really be only writing to the one which is actually connected though. I guess we could even enforce this
in the kernel and reject brightness property writes on unconnected connectors.
>> Please let me know if the proposed solution works for you and
>> if you want me to make ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY a
>> module-option for the next version.
>
>
> I do think it should be workable, apart from the concern I mentioned above about knowing when to set the module option to disable the ACPI video backlight driver.
Note the option does not disable the ACPI video backlight driver. It disables the acpi_video code timing out and deciding to go ahead and register its backlight itself (providing that at the moment of timeout acpi_video_get_backlight_type() returns acpi_backlight_video). Any code (e.g. the nvidia binary driver) can still call acpi_video_register_backlight() itself to try and register even if the timeout handling has been disabled.
The idea is that without the timeout the probe order looks like this:
1. acpi_video initializes, does not register backlight
2. GPU driver initalizes, it either registers a native backlight handler;
or it calls acpi_video_register_backlight()
3. acpi_video_register_backlight() runs (if called) and calls:
acpi_video_get_backlight_type()
4.1 if acpi_video_get_backlight_type() returns acpi_backlight_video
/sys/class/backlight/acpi_video# is/are registered
4.2 if acpi_video_get_backlight_type() returns somerthing else, e.g.
acpi_backlight_nvidia_wmi_ec, acpi_video_register_backlight()
does nothing
The timeout is to ensure that 3. still happens, even if
there is no native GPU driver, because of e.g.
nomodeset on the kernel cmdline.
With the nvidia binary driver, that driver can call
acpi_video_register_backlight() if necessary so the timeout
is not necessary.
I'm currently preparing v3 of this patchset. I'll modify the
patch introducing the timeout to make it configurable
(with 0 disabling it completely).
>> p.s.
>>
>> I think that eventually I might even try to make the new
>> module-param default to 0 / default to not having acpi_video.c
>> do the registering itself ever and see how that goes...
>
> Would the GPU drivers then be responsible for calling acpi_video_register_backlight() again? My understanding was that part of the intention here was to make that no longer necessary.
It is actually the other way around, before this patch-set
acpi_video_register_backlight() does not exist as a separate
step. Before this patch-set the registering is done at
acpi_video probe time. At acpi_video probe time it may be
unknown if a native GPU driver (which is preferred) might
become available later.
This patch-set actually makes the registration a separate
step, which must be called by the GPU driver driving the panel
when its own native backlight control probing is done
(and has not resulted in registering its own backlight handler).
IOW this patch-set is actually what makes it necessary for
the GPU drivers to call acpi_video_register_backlight()
(rather then making this no longer necessary).
Also see the probe order example I wrote above.
The timeout is really just a bandaid to not regress on systems
where for some reason there is no native GPU driver to do
the registration.
I hope this makes things a bit more clear.
Regards,
Hans
>
>>
>>>>> }
>>>>> +
>>>>> +enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>>> +{
>>>>> + return __acpi_video_get_backlight_type(false);
>>>>> +}
>>>>> EXPORT_SYMBOL(acpi_video_get_backlight_type);
>>>>> +bool acpi_video_backlight_use_native(void)
>>>>> +{
>>>>> + return __acpi_video_get_backlight_type(true) == acpi_backlight_native;
>>>>> +}
>>>>> +EXPORT_SYMBOL(acpi_video_backlight_use_native);
>>>>> +
>>>>> /*
>>>>> * Set the preferred backlight interface type based on DMI info.
>>>>> * This function allows DMI blacklists to be implemented by external
>>>>> diff --git a/include/acpi/video.h b/include/acpi/video.h
>>>>> index db8548ff03ce..4705e339c252 100644
>>>>> --- a/include/acpi/video.h
>>>>> +++ b/include/acpi/video.h
>>>>> @@ -56,6 +56,7 @@ extern void acpi_video_unregister(void);
>>>>> extern int acpi_video_get_edid(struct acpi_device *device, int type,
>>>>> int device_id, void **edid);
>>>>> extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
>>>>> +extern bool acpi_video_backlight_use_native(void);
>>>>> extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type);
>>>>> /*
>>>>> * Note: The value returned by acpi_video_handles_brightness_key_presses()
>>>>> @@ -77,6 +78,10 @@ static inline enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>>> {
>>>>> return acpi_backlight_vendor;
>>>>> }
>>>>> +static inline bool acpi_video_backlight_use_native(void)
>>>>> +{
>>>>> + return true;
>>>>> +}
>>>>> static inline void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
>>>>> {
>>>>> }
>
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper
2022-08-17 15:05 ` Hans de Goede
@ 2022-08-17 20:18 ` Daniel Dadap
2022-08-24 11:08 ` Hans de Goede
0 siblings, 1 reply; 58+ messages in thread
From: Daniel Dadap @ 2022-08-17 20:18 UTC (permalink / raw)
To: Hans de Goede, Ben Skeggs, Karol Herbst, Lyude,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher,
Christian König, Xinhui, Rafael J . Wysocki,
Mika Westerberg, Lukas Wunner, Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
On 8/17/22 10:05 AM, Hans de Goede wrote:
> Hi Daniel,
>
> On 8/2/22 18:49, Daniel Dadap wrote:
>> On 8/2/22 06:31, Hans de Goede wrote:
>>> Hi Daniel,
>>>
>>> On 7/21/22 23:30, Daniel Dadap wrote:
>>>> On 7/21/22 16:24, Daniel Dadap wrote:
>>>>> On 7/12/22 14:38, Hans de Goede wrote:
>>>>>> 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.
>>>>>>
>>>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>>>> ---
>>>>>> drivers/acpi/video_detect.c | 24 ++++++++++++++++++++----
>>>>>> include/acpi/video.h | 5 +++++
>>>>>> 2 files changed, 25 insertions(+), 4 deletions(-)
>>>>>>
>>>>>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>>>>>> index becc198e4c22..4346c990022d 100644
>>>>>> --- a/drivers/acpi/video_detect.c
>>>>>> +++ b/drivers/acpi/video_detect.c
>>>>>> @@ -17,8 +17,9 @@
>>>>>> * Otherwise vendor specific drivers like thinkpad_acpi, asus-laptop,
>>>>>> * sony_acpi,... can take care about backlight brightness.
>>>>>> *
>>>>>> - * Backlight drivers can use acpi_video_get_backlight_type() to determine
>>>>>> - * which driver should handle the backlight.
>>>>>> + * 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
>>>>>> @@ -548,9 +549,10 @@ static int acpi_video_backlight_notify(struct notifier_block *nb,
>>>>>> * Arguably the native on win8 check should be done first, but that would
>>>>>> * be a behavior change, which may causes issues.
>>>>>> */
>>>>>> -enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>>>> +static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>>>>> {
>>>>>> static DEFINE_MUTEX(init_mutex);
>>>>>> + static bool native_available;
>>>>>> static bool init_done;
>>>>>> static long video_caps;
>>>>>> @@ -570,6 +572,8 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>>>> backlight_notifier_registered = true;
>>>>>> init_done = true;
>>>>>> }
>>>>>> + if (native)
>>>>>> + native_available = true;
>>>>>> mutex_unlock(&init_mutex);
>>>>>> if (acpi_backlight_cmdline != acpi_backlight_undef)
>>>>>> @@ -581,13 +585,25 @@ enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>>>> if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
>>>>>> return acpi_backlight_vendor;
>>>>>> - if (acpi_osi_is_win8() && backlight_device_get_by_type(BACKLIGHT_RAW))
>>>>>> + if (acpi_osi_is_win8() &&
>>>>>> + (native_available || backlight_device_get_by_type(BACKLIGHT_RAW)))
>>>>>> return acpi_backlight_native;
>>>>>> return acpi_backlight_video;
>>>>> So I ran into a minor problem when testing the NVIDIA proprietary driver against this change set, after checking acpi_video_backlight_use_native() before registering the NVIDIA proprietary driver's backlight handler. Namely, for the case where a user installs the NVIDIA proprietary driver after the video.ko has already registered its backlight handler, we end up with both the firmware and native handlers registered simultaneously, since the ACPI video driver no longer unregisters its backlight handler. In this state, desktop environments end up preferring the registered but non-functional firmware handler from video.ko. (Manually twiddling the sysfs interface for the native NVIDIA handler works fine.) When rebooting the system after installing the NVIDIA proprietary driver, it is able to register its native handler before the delayed work to register the ACPI video backlight handler fires, so we end up with only one (native) handler, and userspace is happy.
>>>>>
>>>>> Maybe this will be moot later on, when the existing sysfs interface is deprecated, and it probably isn't a huge deal, since a reboot fixes things (I imagine installing an in-tree DRM/KMS driver on an already running kernel isn't really a thing, which is why this isn't a problem with the in-tree drivers), but would it make sense to unregister the ACPI video backlight handler here before returning acpi_backlight_native? That way, we'll briefly end up with zero backlight handlers rather than briefly ending up with two of them. Not sure if that's really any better, though.
>>>>>
>>>> Thinking about this a little more, maybe it's better not to overly complicate things, and just assert that users of the NVIDIA proprietary driver will need to reboot after installation in order to get the backlight working, at least until we get further along in this effort and the backlight interface transitions to the DRM connector property you have proposed.
>>> Right, this series stops unregistering the acpi_video# /sys/class/backlight
>>> devices because the idea is to never register them in the first place.
>>>
>>> Registering them in the first place causes 2 problems:
>>>
>>> 1. It causes userspace to see udev events for the register + unregister
>>> and by the time the systemd backlight level save/restore helper runs
>>> from udev the unregister has already happened and it logs ugly errors.
>>> More in general this kinda racy behavior just is ugly.
>>>
>>> 2. On some hw merely registering the backlight device, which I think
>>> at least tries to retrieve the current level through ACPI, is causing
>>> issues. So now we have DMI quirks to force the native backlight on
>>> some devices, even though the heuristics also say native eventually,
>>> just to avoid the race. Avoiding the add + remove dance allows
>>> us to drop a bunch of quirks and likely also fixes issues on other
>>> devices which we don't yet know need the quirk.
>>
>> Yes, those sound like good reasons to avoid registering the ACPI video backlight driver wherever possible.
>>
>>
>>> So this patch-set changes the acpi_video.c code to no longer register
>>> the acpi_video# backlight devices at init time *at all*. Instead native
>>> drivers are supposed to now call acpi_video_register_backlight()
>>> when they have found an internal panel. But to avoid this causing
>>> the acpi_video# backlight devices to not show up at all in some
>>> cases (e.g. native kms drivers blacklisted) the acpi_video code
>>> also calls acpi_video_register_backlight() itself after 8 seconds.
>>>
>>> I believe this is what you are hitting, the 8 seconds have passed
>>> before the nvidia driver calls acpi_video_backlight_use_native(),
>>> so the acpi_video# backlight devices have registered (and no longer
>>> go away).
>>>
>>> This is not only a problem when installing the nvidia binary driver
>>> for the first time. It can also be a problem if the binary driver
>>> is not in the initrd and leaving the initrd takes longer then
>>> 8 seconds, say because of a diskcrypt password. So I believe that
>>> this really can be a problem with the nvidia binary driver.
>>
>> Hmm. I hadn't considered the case of the binary driver being absent from the initrd, and the possibility of the transition out of the initrd happening after the timeout. Yes, this is a bigger problem than the "only after first installing the driver" scenario I ran into.
>>
>>
>>> But I think this is easy to fix. We could make the 8 second
>>> delay configurable by replacing the ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY
>>> define with a module-parameter; and we could make "0" as value mean
>>> that acpi_video.c will never call acpi_video_register_backlight()
>>> itself.
>>>
>>> Since the various (also counting distor packaging) nvidia binary
>>> driver installers already all modify the kernel commandline to
>>> blacklist nouveau, then the installers can just also pass this
>>> parameter and then acpi_video.c will never register the acpi_video#.
>>
>> This sounds like a reasonable compromise, but I worry that it may be difficult to determine whether a system definitely doesn't need the ACPI video backlight driver. On the other hand, the last system that I recall personally seeing that did use the ACPI video backlight driver was a little over 10 years ago, so it's possible that there are no systems which use that driver which are supported by current versions of the NVIDIA proprietary driver. I'll have to do some research to determine what types of systems actually used video.ko's backlight driver, unless you happen to know already.
> Generally the backlight control method / fw interface to use depends
> on the Era of the laptop:
>
> 1. pre Windows XP Era laptops use vendor specific ACPI or SMBIOS interfaces
> such as those dealt with by dell-laptop, thinkpad-acpi, etc.
> 2. Windows XP Era (which ends with Win 8/Vista) laptops used the ACPI video
> bus backlight interface
> 3. Win 8/Vista and later Era laptops use the GPU driver's native backlight
> support instead of some firmware interface
>
> This is generalizing things a bit. E.g. esp during the transition between
> the Eras often both Era methods (e.g vendor + acpi-video) would work
> equally well.
>
> So wrt your questions, generally speaking any laptops which were
> designed for Win8/Vista or newer no longer use the ACPI video
> interface.
>
> So yes it is possible that there are no systems supported by
> the latest NVIDIA proprietary driver which need ACPI video at
> all. OTOH on dual-GPU setups with muxes it is not unreasonable
> for ACPI video to actually be the driver which needs to be
> used in case e.g. the backlight control is hooked up to the
> EC so that it does not need to go through the mux. Basically
> ACPI video Should work well (if the ACPI tables are written
> properly) in setups where the EC drivers the backlight and
> where this the GPU driver cannot control it directly. So
> their might very well be pre nvidia-wmi-ec-backlight laptops
> which use ACPI video to control the brightness through the EC.
Thanks. My understanding is that EC-driven backlight on muxed systems is
always controlled by the interface that the nvidia-wmi-ec-backlight
driver uses, but that could be true only for newer designs with NVIDIA
discrete GPUs. On older designs the mux was not intended to be switched
while a GPU was actively driving the display, so it seems unlikely, but
not impossible, that such designs would have seen a need to control the
backlight brightness via something other than one of the GPUs.
>>> This does mean that the nvidia binary driver then must call
>>> acpi_video_register_backlight() when an internal panel is found.
>>>
>>> Note the current patches to amdgpu/nouveau skip the calling of
>>> acpi_video_register_backlight() when
>>> the acpi_video_backlight_use_native() call returns true and they
>>> have registered their own backlight. But calling it always is ok
>>> *as long as the driver is driving the laptops internal panel* !
>>>
>>> acpi_video_register_backlight() contains:
>>>
>>> if (acpi_video_get_backlight_type() != acpi_backlight_video)
>>> return 0;
>>>
>>> So calling it when a native backlight has already been registered
>>> is a no-op.
>>
>> The NVIDIA proprietary driver will already know when it has registered its own backlight handler, so there probably isn't any need to always call it when driving an internal panel.
> Ok.
>
>> I'll have to double-check to see if we have already determined whether a panel is connected before registering the backlight handler: I am pretty certain that is the case.
> Yeah registering a backlight handler when there is no internal panel would be weird.
>
>> One further potential difficulty that I anticipate is that not all dynamic mux systems use the EC backlight driver (or a similar, GPU-agnostic driver), and rather have whichever GPU happens to be connected at the time be responsible for the backlight. I had initially thought that supporting the EC backlight interface was a requirement for OEMs to implement dynamic mux support, but I recently learned this is not true in all cases. On Windows, this requires coordinating the backlight controls of the two GPU drivers across a mux switch, to load the state of the switched-away-from GPU and set it on the switched-to GPU. I imagine for these systems we may need to do some similar save/restore, probably managed by vga-switcheroo, but it would require having both GPU drivers register their own native backlight handlers (and possibly while one of them is not connected to the panel).
> Right, systems where the backlight control basically gets muxed from one GPU to the other GPU together with the panel's video-data lines exist. Currently Linux already register both native GPU backlight handlers in this case. e.g. /sys/class/backlight/intel_backlight and /sys/class/backlight/nouveau_bl.
>
> Userspace (atleast GNOME) has code which checks which GPU is actually connected to the panel using the panel's drm connector's status on each GPU (only one of which should report connected) and then uses the backlight interface associated with the connected connector.
>
>> Dynamic mux switching isn't actually supported on Linux, yet, so we should be able to kick this particular can a little further down the road, but in the meantime we should probably start planning for how best to handle this sort of system under the "only one backlight handler per panel" model. Maybe the vga-switcheroo handler can register its own backlight handler, that then negotiates the actual backlight settings between the relevant GPU drivers, possibly through a new vga-switcheroo client callback. I'll have to think about this a bit more.
> The "only one backlight handler per panel" model is actualy "only one backlight handler per panel"-connector since the new API uses drm properties on the drm connector object. With 2 GPUs both using their native backlight control there will be 2 connectors and userspace will/must use the one which is actually reporting that it is connected to the panel so this will work fine.
That is a useful distinction. Would it fall under userspace's
reponsibility, then, to keep the brightness level synchronized across
drm_connectors that share a panel via a mux when performing a switch? I
suppose it's a cleaner design to leave it up to userspace to select
which backlight interface to manipulate. That is a harder decision for
userspace to make with the existing design, which doesn't cleanly map
sysfs backlight interfaces to individual connectors, but if the UAPI is
going to change to a drm_connector property, backlight interfaces are
obviously strongly correlated with the connectors. I'm not sure how easy
it is for userspace to solve the problem of maintaining consistent
brightness levels across a mux switch for an OLED panel, where there
really isn't a concept of a "backlight" to speak of, but I suppose it
wouldn't be any easier to do that in the kernel (e.g. with vga-switcheroo).
> If anything the nvidia-wmi-ec-backlight case is a but more tricky, the "only one backlight handler per panel" thing is actually more of a "only one backlight handler per laptop" rule which is intended for (to be written) drm helpers for the new properties to be able to get the handler from the backlight class in the non native case by just taking the first registered backlight handler.
>
> This means that in a dual GPU setup with nvidia-wmi-ec-backlight both GPU's panel connector objects will have their brightness properties pointing to / proxying the same backlight class device. Userspace should really be only writing to the one which is actually connected though. I guess we could even enforce this
> in the kernel and reject brightness property writes on unconnected connectors.
>
>>> Please let me know if the proposed solution works for you and
>>> if you want me to make ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY a
>>> module-option for the next version.
>>
>> I do think it should be workable, apart from the concern I mentioned above about knowing when to set the module option to disable the ACPI video backlight driver.
> Note the option does not disable the ACPI video backlight driver. It disables the acpi_video code timing out and deciding to go ahead and register its backlight itself (providing that at the moment of timeout acpi_video_get_backlight_type() returns acpi_backlight_video). Any code (e.g. the nvidia binary driver) can still call acpi_video_register_backlight() itself to try and register even if the timeout handling has been disabled.
>
> The idea is that without the timeout the probe order looks like this:
>
> 1. acpi_video initializes, does not register backlight
> 2. GPU driver initalizes, it either registers a native backlight handler;
> or it calls acpi_video_register_backlight()
> 3. acpi_video_register_backlight() runs (if called) and calls:
> acpi_video_get_backlight_type()
> 4.1 if acpi_video_get_backlight_type() returns acpi_backlight_video
> /sys/class/backlight/acpi_video# is/are registered
> 4.2 if acpi_video_get_backlight_type() returns somerthing else, e.g.
> acpi_backlight_nvidia_wmi_ec, acpi_video_register_backlight()
> does nothing
>
>
> The timeout is to ensure that 3. still happens, even if
> there is no native GPU driver, because of e.g.
> nomodeset on the kernel cmdline.
>
> With the nvidia binary driver, that driver can call
> acpi_video_register_backlight() if necessary so the timeout
> is not necessary.
>
> I'm currently preparing v3 of this patchset. I'll modify the
> patch introducing the timeout to make it configurable
> (with 0 disabling it completely).
Okay. That clarification makes sense. Would it be reasonable to disable
the timeout by default on systems with Win8 or later _OSI?
>>> p.s.
>>>
>>> I think that eventually I might even try to make the new
>>> module-param default to 0 / default to not having acpi_video.c
>>> do the registering itself ever and see how that goes...
>> Would the GPU drivers then be responsible for calling acpi_video_register_backlight() again? My understanding was that part of the intention here was to make that no longer necessary.
> It is actually the other way around, before this patch-set
> acpi_video_register_backlight() does not exist as a separate
> step. Before this patch-set the registering is done at
> acpi_video probe time. At acpi_video probe time it may be
> unknown if a native GPU driver (which is preferred) might
> become available later.
>
> This patch-set actually makes the registration a separate
> step, which must be called by the GPU driver driving the panel
> when its own native backlight control probing is done
> (and has not resulted in registering its own backlight handler).
>
> IOW this patch-set is actually what makes it necessary for
> the GPU drivers to call acpi_video_register_backlight()
> (rather then making this no longer necessary).
>
> Also see the probe order example I wrote above.
>
> The timeout is really just a bandaid to not regress on systems
> where for some reason there is no native GPU driver to do
> the registration.
>
> I hope this makes things a bit more clear.
Yes, thank you. It is much less confusing when I don't have my mental
model inside-out and backwards.
> Regards,
>
> Hans
>
>
>
>
>
>>>>>> }
>>>>>> +
>>>>>> +enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>>>> +{
>>>>>> + return __acpi_video_get_backlight_type(false);
>>>>>> +}
>>>>>> EXPORT_SYMBOL(acpi_video_get_backlight_type);
>>>>>> +bool acpi_video_backlight_use_native(void)
>>>>>> +{
>>>>>> + return __acpi_video_get_backlight_type(true) == acpi_backlight_native;
>>>>>> +}
>>>>>> +EXPORT_SYMBOL(acpi_video_backlight_use_native);
>>>>>> +
>>>>>> /*
>>>>>> * Set the preferred backlight interface type based on DMI info.
>>>>>> * This function allows DMI blacklists to be implemented by external
>>>>>> diff --git a/include/acpi/video.h b/include/acpi/video.h
>>>>>> index db8548ff03ce..4705e339c252 100644
>>>>>> --- a/include/acpi/video.h
>>>>>> +++ b/include/acpi/video.h
>>>>>> @@ -56,6 +56,7 @@ extern void acpi_video_unregister(void);
>>>>>> extern int acpi_video_get_edid(struct acpi_device *device, int type,
>>>>>> int device_id, void **edid);
>>>>>> extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
>>>>>> +extern bool acpi_video_backlight_use_native(void);
>>>>>> extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type);
>>>>>> /*
>>>>>> * Note: The value returned by acpi_video_handles_brightness_key_presses()
>>>>>> @@ -77,6 +78,10 @@ static inline enum acpi_backlight_type acpi_video_get_backlight_type(void)
>>>>>> {
>>>>>> return acpi_backlight_vendor;
>>>>>> }
>>>>>> +static inline bool acpi_video_backlight_use_native(void)
>>>>>> +{
>>>>>> + return true;
>>>>>> +}
>>>>>> static inline void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
>>>>>> {
>>>>>> }
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper
2022-08-17 20:18 ` Daniel Dadap
@ 2022-08-24 11:08 ` Hans de Goede
0 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-08-24 11:08 UTC (permalink / raw)
To: Daniel Dadap, Ben Skeggs, Karol Herbst, Lyude, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Hi Daniel,
On 8/17/22 22:18, Daniel Dadap wrote:
> On 8/17/22 10:05 AM, Hans de Goede wrote:
<snip>
>>> One further potential difficulty that I anticipate is that not all dynamic mux systems use the EC backlight driver (or a similar, GPU-agnostic driver), and rather have whichever GPU happens to be connected at the time be responsible for the backlight. I had initially thought that supporting the EC backlight interface was a requirement for OEMs to implement dynamic mux support, but I recently learned this is not true in all cases. On Windows, this requires coordinating the backlight controls of the two GPU drivers across a mux switch, to load the state of the switched-away-from GPU and set it on the switched-to GPU. I imagine for these systems we may need to do some similar save/restore, probably managed by vga-switcheroo, but it would require having both GPU drivers register their own native backlight handlers (and possibly while one of them is not connected to the panel).
>> Right, systems where the backlight control basically gets muxed from one GPU to the other GPU together with the panel's video-data lines exist. Currently Linux already register both native GPU backlight handlers in this case. e.g. /sys/class/backlight/intel_backlight and /sys/class/backlight/nouveau_bl.
>>
>> Userspace (atleast GNOME) has code which checks which GPU is actually connected to the panel using the panel's drm connector's status on each GPU (only one of which should report connected) and then uses the backlight interface associated with the connected connector.
>>
>>> Dynamic mux switching isn't actually supported on Linux, yet, so we should be able to kick this particular can a little further down the road, but in the meantime we should probably start planning for how best to handle this sort of system under the "only one backlight handler per panel" model. Maybe the vga-switcheroo handler can register its own backlight handler, that then negotiates the actual backlight settings between the relevant GPU drivers, possibly through a new vga-switcheroo client callback. I'll have to think about this a bit more.
>> The "only one backlight handler per panel" model is actualy "only one backlight handler per panel"-connector since the new API uses drm properties on the drm connector object. With 2 GPUs both using their native backlight control there will be 2 connectors and userspace will/must use the one which is actually reporting that it is connected to the panel so this will work fine.
>
>
> That is a useful distinction. Would it fall under userspace's reponsibility, then, to keep the brightness level synchronized across drm_connectors that share a panel via a mux when performing a switch?
Yes typically the 2 different GPU drivers know nothing about the other GPU and I think it would be good to keep things that way. When switching userspace will see a disconnect on the panel connector on one GPU and then a connect on the connector on the other GPU at which point it knows that it should set the brightness on the now connected connector instead of on the old one.
> I suppose it's a cleaner design to leave it up to userspace to select which backlight interface to manipulate.
Ack.
> That is a harder decision for userspace to make with the existing design, which doesn't cleanly map sysfs backlight interfaces to individual connectors, but if the UAPI is going to change to a drm_connector property, backlight interfaces are obviously strongly correlated with the connectors.
Right.
> I'm not sure how easy it is for userspace to solve the problem of maintaining consistent brightness levels across a mux switch for an OLED panel, where there really isn't a concept of a "backlight" to speak of, but I suppose it wouldn't be any easier to do that in the kernel (e.g. with vga-switcheroo).
The OLED brightness is send over DP-aux to the panel AFAIK, so as long as both drivers export the raw range of the panel's setting and don't try to get smart and scale or whatever then their should be a 1:1 mapping. Ideally for something like this both drivers would be using some shared drm-helper code / library to talk to the backlight, thus guaranteeing that both drivers interpret the scale the same.
>> If anything the nvidia-wmi-ec-backlight case is a but more tricky, the "only one backlight handler per panel" thing is actually more of a "only one backlight handler per laptop" rule which is intended for (to be written) drm helpers for the new properties to be able to get the handler from the backlight class in the non native case by just taking the first registered backlight handler.
>>
>> This means that in a dual GPU setup with nvidia-wmi-ec-backlight both GPU's panel connector objects will have their brightness properties pointing to / proxying the same backlight class device. Userspace should really be only writing to the one which is actually connected though. I guess we could even enforce this
>> in the kernel and reject brightness property writes on unconnected connectors.
>>
>>>> Please let me know if the proposed solution works for you and
>>>> if you want me to make ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY a
>>>> module-option for the next version.
>>>
>>> I do think it should be workable, apart from the concern I mentioned above about knowing when to set the module option to disable the ACPI video backlight driver.
>> Note the option does not disable the ACPI video backlight driver. It disables the acpi_video code timing out and deciding to go ahead and register its backlight itself (providing that at the moment of timeout acpi_video_get_backlight_type() returns acpi_backlight_video). Any code (e.g. the nvidia binary driver) can still call acpi_video_register_backlight() itself to try and register even if the timeout handling has been disabled.
>>
>> The idea is that without the timeout the probe order looks like this:
>>
>> 1. acpi_video initializes, does not register backlight
>> 2. GPU driver initalizes, it either registers a native backlight handler;
>> or it calls acpi_video_register_backlight()
>> 3. acpi_video_register_backlight() runs (if called) and calls:
>> acpi_video_get_backlight_type()
>> 4.1 if acpi_video_get_backlight_type() returns acpi_backlight_video
>> /sys/class/backlight/acpi_video# is/are registered
>> 4.2 if acpi_video_get_backlight_type() returns somerthing else, e.g.
>> acpi_backlight_nvidia_wmi_ec, acpi_video_register_backlight()
>> does nothing
>>
>>
>> The timeout is to ensure that 3. still happens, even if
>> there is no native GPU driver, because of e.g.
>> nomodeset on the kernel cmdline.
>>
>> With the nvidia binary driver, that driver can call
>> acpi_video_register_backlight() if necessary so the timeout
>> is not necessary.
>>
>> I'm currently preparing v3 of this patchset. I'll modify the
>> patch introducing the timeout to make it configurable
>> (with 0 disabling it completely).
>
>
> Okay. That clarification makes sense. Would it be reasonable to disable the timeout by default on systems with Win8 or later _OSI?
Hmm, there are Win8 or later systems which actually need acpi_video because the other method(s) to control the backlight don't work (we have a list of quirks for those) and more importantly there are Win8 or later systems where the video bios tables say: "Don't use the GPU for backlight control". We do need the acpi_video_register_backlight() call to happen on both those cases eventually. Also this will lead to 2 different code-paths making things more complicated, so no I don't think that that is a good idea.
Regards,
Hans
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v2 02/29] drm/i915: Don't register backlight when another backlight should be used
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
2022-07-12 19:38 ` [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-12 19:38 ` [PATCH v2 03/29] drm/amdgpu: " Hans de Goede
` (28 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
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.
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 110fc98ec280..567943c9ffbc 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_connector.h"
#include "intel_de.h"
@@ -950,6 +952,11 @@ int intel_backlight_device_register(struct intel_connector *connector)
WARN_ON(panel->backlight.max == 0);
+ if (!acpi_video_backlight_use_native()) {
+ DRM_INFO("Skipping intel_backlight registration\n");
+ return 0;
+ }
+
memset(&props, 0, sizeof(props));
props.type = BACKLIGHT_RAW;
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 03/29] drm/amdgpu: Don't register backlight when another backlight should be used
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
2022-07-12 19:38 ` [PATCH v2 01/29] ACPI: video: Add acpi_video_backlight_use_native() helper Hans de Goede
2022-07-12 19:38 ` [PATCH v2 02/29] drm/i915: Don't register backlight when another backlight should be used Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-20 16:44 ` Alex Deucher
2022-07-12 19:38 ` [PATCH v2 04/29] drm/radeon: " Hans de Goede
` (27 subsequent siblings)
30 siblings, 1 reply; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
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:
- To avoid linker errors when amdgpu is builtin and video_detect.c is in
a module, select ACPI_VIDEO and its deps if ACPI && X86 are enabled.
When these are not set, ACPI_VIDEO is disabled, ensuring the stubs
from acpi/video.h will be used.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/gpu/drm/Kconfig | 6 ++++++
drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 7 +++++++
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++++++
3 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index aaa7ad1f0614..d65119860760 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -258,6 +258,12 @@ config DRM_AMDGPU
select HWMON
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
+ # amdgpu depends on ACPI_VIDEO when X86 and ACPI are both enabled
+ # for select to work, ACPI_VIDEO's dependencies must also be selected
+ select INPUT if ACPI && X86
+ select X86_PLATFORM_DEVICES if ACPI && X86
+ select ACPI_WMI if ACPI && X86
+ select ACPI_VIDEO if ACPI && X86
help
Choose this option if you have a recent AMD Radeon graphics card.
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
index fa7421afb9a6..abf209e36fca 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
@@ -26,6 +26,8 @@
#include <linux/pci.h>
+#include <acpi/video.h>
+
#include <drm/drm_crtc_helper.h>
#include <drm/amdgpu_drm.h>
#include "amdgpu.h"
@@ -184,6 +186,11 @@ void amdgpu_atombios_encoder_init_backlight(struct amdgpu_encoder *amdgpu_encode
if (!(adev->mode_info.firmware_flags & ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
return;
+ if (!acpi_video_backlight_use_native()) {
+ DRM_INFO("Skipping amdgpu atom DIG backlight registration\n");
+ return;
+ }
+
pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("Memory allocation failed\n");
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 5eb111d35793..3b03a95e59a8 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -86,6 +86,8 @@
#include <drm/drm_audio_component.h>
#include <drm/drm_gem_atomic_helper.h>
+#include <acpi/video.h>
+
#include "ivsrcid/dcn/irqsrcs_dcn_1_0.h"
#include "dcn/dcn_1_0_offset.h"
@@ -4050,6 +4052,11 @@ amdgpu_dm_register_backlight_device(struct amdgpu_display_manager *dm)
amdgpu_dm_update_backlight_caps(dm, dm->num_of_edps);
dm->brightness[dm->num_of_edps] = AMDGPU_MAX_BL_LEVEL;
+ if (!acpi_video_backlight_use_native()) {
+ DRM_INFO("Skipping amdgpu DM backlight registration\n");
+ return;
+ }
+
props.max_brightness = AMDGPU_MAX_BL_LEVEL;
props.brightness = AMDGPU_MAX_BL_LEVEL;
props.type = BACKLIGHT_RAW;
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v2 03/29] drm/amdgpu: Don't register backlight when another backlight should be used
2022-07-12 19:38 ` [PATCH v2 03/29] drm/amdgpu: " Hans de Goede
@ 2022-07-20 16:44 ` Alex Deucher
2022-07-20 16:46 ` Alex Deucher
0 siblings, 1 reply; 58+ messages in thread
From: Alex Deucher @ 2022-07-20 16:44 UTC (permalink / raw)
To: Hans de Goede
Cc: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko, linux-acpi, David Airlie, nouveau,
intel-gfx, dri-devel, platform-driver-x86, amd-gfx, Len Brown
On Tue, Jul 12, 2022 at 3:39 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> 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:
> - To avoid linker errors when amdgpu is builtin and video_detect.c is in
> a module, select ACPI_VIDEO and its deps if ACPI && X86 are enabled.
> When these are not set, ACPI_VIDEO is disabled, ensuring the stubs
> from acpi/video.h will be used.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> drivers/gpu/drm/Kconfig | 6 ++++++
> drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 7 +++++++
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++++++
> 3 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index aaa7ad1f0614..d65119860760 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -258,6 +258,12 @@ config DRM_AMDGPU
> select HWMON
> select BACKLIGHT_CLASS_DEVICE
> select INTERVAL_TREE
> + # amdgpu depends on ACPI_VIDEO when X86 and ACPI are both enabled
> + # for select to work, ACPI_VIDEO's dependencies must also be selected
> + select INPUT if ACPI && X86
> + select X86_PLATFORM_DEVICES if ACPI && X86
> + select ACPI_WMI if ACPI && X86
> + select ACPI_VIDEO if ACPI && X86
> help
> Choose this option if you have a recent AMD Radeon graphics card.
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> index fa7421afb9a6..abf209e36fca 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> @@ -26,6 +26,8 @@
>
> #include <linux/pci.h>
>
> +#include <acpi/video.h>
> +
> #include <drm/drm_crtc_helper.h>
> #include <drm/amdgpu_drm.h>
> #include "amdgpu.h"
> @@ -184,6 +186,11 @@ void amdgpu_atombios_encoder_init_backlight(struct amdgpu_encoder *amdgpu_encode
> if (!(adev->mode_info.firmware_flags & ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
> return;
>
> + if (!acpi_video_backlight_use_native()) {
> + DRM_INFO("Skipping amdgpu atom DIG backlight registration\n");
> + return;
> + }
> +
> pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
> if (!pdata) {
> DRM_ERROR("Memory allocation failed\n");
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 5eb111d35793..3b03a95e59a8 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -86,6 +86,8 @@
> #include <drm/drm_audio_component.h>
> #include <drm/drm_gem_atomic_helper.h>
>
> +#include <acpi/video.h>
> +
> #include "ivsrcid/dcn/irqsrcs_dcn_1_0.h"
>
> #include "dcn/dcn_1_0_offset.h"
> @@ -4050,6 +4052,11 @@ amdgpu_dm_register_backlight_device(struct amdgpu_display_manager *dm)
> amdgpu_dm_update_backlight_caps(dm, dm->num_of_edps);
> dm->brightness[dm->num_of_edps] = AMDGPU_MAX_BL_LEVEL;
>
> + if (!acpi_video_backlight_use_native()) {
> + DRM_INFO("Skipping amdgpu DM backlight registration\n");
> + return;
> + }
> +
> props.max_brightness = AMDGPU_MAX_BL_LEVEL;
> props.brightness = AMDGPU_MAX_BL_LEVEL;
> props.type = BACKLIGHT_RAW;
> --
> 2.36.0
>
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 03/29] drm/amdgpu: Don't register backlight when another backlight should be used
2022-07-20 16:44 ` Alex Deucher
@ 2022-07-20 16:46 ` Alex Deucher
2022-08-17 13:05 ` Hans de Goede
0 siblings, 1 reply; 58+ messages in thread
From: Alex Deucher @ 2022-07-20 16:46 UTC (permalink / raw)
To: Hans de Goede
Cc: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko, linux-acpi, David Airlie, nouveau,
intel-gfx, dri-devel, platform-driver-x86, amd-gfx, Len Brown
On Wed, Jul 20, 2022 at 12:44 PM Alex Deucher <alexdeucher@gmail.com> wrote:
>
> On Tue, Jul 12, 2022 at 3:39 PM Hans de Goede <hdegoede@redhat.com> wrote:
> >
> > 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:
> > - To avoid linker errors when amdgpu is builtin and video_detect.c is in
> > a module, select ACPI_VIDEO and its deps if ACPI && X86 are enabled.
> > When these are not set, ACPI_VIDEO is disabled, ensuring the stubs
> > from acpi/video.h will be used.
> >
> > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> Acked-by: Alex Deucher <alexander.deucher@amd.com>
Actually, can you use dev_info for the messages below rather than
DRM_INFO? That makes it easier to tell which GPU is affected in a
multi-GPU system. With that changed,
Acked-by: Alex Deucher <alexander.deucher@amd.com>
>
> > ---
> > drivers/gpu/drm/Kconfig | 6 ++++++
> > drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 7 +++++++
> > drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++++++
> > 3 files changed, 20 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > index aaa7ad1f0614..d65119860760 100644
> > --- a/drivers/gpu/drm/Kconfig
> > +++ b/drivers/gpu/drm/Kconfig
> > @@ -258,6 +258,12 @@ config DRM_AMDGPU
> > select HWMON
> > select BACKLIGHT_CLASS_DEVICE
> > select INTERVAL_TREE
> > + # amdgpu depends on ACPI_VIDEO when X86 and ACPI are both enabled
> > + # for select to work, ACPI_VIDEO's dependencies must also be selected
> > + select INPUT if ACPI && X86
> > + select X86_PLATFORM_DEVICES if ACPI && X86
> > + select ACPI_WMI if ACPI && X86
> > + select ACPI_VIDEO if ACPI && X86
> > help
> > Choose this option if you have a recent AMD Radeon graphics card.
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> > index fa7421afb9a6..abf209e36fca 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> > @@ -26,6 +26,8 @@
> >
> > #include <linux/pci.h>
> >
> > +#include <acpi/video.h>
> > +
> > #include <drm/drm_crtc_helper.h>
> > #include <drm/amdgpu_drm.h>
> > #include "amdgpu.h"
> > @@ -184,6 +186,11 @@ void amdgpu_atombios_encoder_init_backlight(struct amdgpu_encoder *amdgpu_encode
> > if (!(adev->mode_info.firmware_flags & ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
> > return;
> >
> > + if (!acpi_video_backlight_use_native()) {
> > + DRM_INFO("Skipping amdgpu atom DIG backlight registration\n");
> > + return;
> > + }
> > +
> > pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
> > if (!pdata) {
> > DRM_ERROR("Memory allocation failed\n");
> > diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > index 5eb111d35793..3b03a95e59a8 100644
> > --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> > @@ -86,6 +86,8 @@
> > #include <drm/drm_audio_component.h>
> > #include <drm/drm_gem_atomic_helper.h>
> >
> > +#include <acpi/video.h>
> > +
> > #include "ivsrcid/dcn/irqsrcs_dcn_1_0.h"
> >
> > #include "dcn/dcn_1_0_offset.h"
> > @@ -4050,6 +4052,11 @@ amdgpu_dm_register_backlight_device(struct amdgpu_display_manager *dm)
> > amdgpu_dm_update_backlight_caps(dm, dm->num_of_edps);
> > dm->brightness[dm->num_of_edps] = AMDGPU_MAX_BL_LEVEL;
> >
> > + if (!acpi_video_backlight_use_native()) {
> > + DRM_INFO("Skipping amdgpu DM backlight registration\n");
> > + return;
> > + }
> > +
> > props.max_brightness = AMDGPU_MAX_BL_LEVEL;
> > props.brightness = AMDGPU_MAX_BL_LEVEL;
> > props.type = BACKLIGHT_RAW;
> > --
> > 2.36.0
> >
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 03/29] drm/amdgpu: Don't register backlight when another backlight should be used
2022-07-20 16:46 ` Alex Deucher
@ 2022-08-17 13:05 ` Hans de Goede
0 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-08-17 13:05 UTC (permalink / raw)
To: Alex Deucher
Cc: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko, linux-acpi, David Airlie, nouveau,
intel-gfx, dri-devel, platform-driver-x86, amd-gfx, Len Brown
Hi,
On 7/20/22 18:46, Alex Deucher wrote:
> On Wed, Jul 20, 2022 at 12:44 PM Alex Deucher <alexdeucher@gmail.com> wrote:
>>
>> On Tue, Jul 12, 2022 at 3:39 PM Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> 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:
>>> - To avoid linker errors when amdgpu is builtin and video_detect.c is in
>>> a module, select ACPI_VIDEO and its deps if ACPI && X86 are enabled.
>>> When these are not set, ACPI_VIDEO is disabled, ensuring the stubs
>>> from acpi/video.h will be used.
>>>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>
>> Acked-by: Alex Deucher <alexander.deucher@amd.com>
>
> Actually, can you use dev_info for the messages below rather than
> DRM_INFO? That makes it easier to tell which GPU is affected in a
> multi-GPU system. With that changed,
> Acked-by: Alex Deucher <alexander.deucher@amd.com>
Thank you for the ack. I've changed the DRM_INFO(...) calls with
drm_info(drm_dev, ...) calls for the version 3 of this series
which I'm preparing.
Regards,
Hans
>
>>
>>> ---
>>> drivers/gpu/drm/Kconfig | 6 ++++++
>>> drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 7 +++++++
>>> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 7 +++++++
>>> 3 files changed, 20 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
>>> index aaa7ad1f0614..d65119860760 100644
>>> --- a/drivers/gpu/drm/Kconfig
>>> +++ b/drivers/gpu/drm/Kconfig
>>> @@ -258,6 +258,12 @@ config DRM_AMDGPU
>>> select HWMON
>>> select BACKLIGHT_CLASS_DEVICE
>>> select INTERVAL_TREE
>>> + # amdgpu depends on ACPI_VIDEO when X86 and ACPI are both enabled
>>> + # for select to work, ACPI_VIDEO's dependencies must also be selected
>>> + select INPUT if ACPI && X86
>>> + select X86_PLATFORM_DEVICES if ACPI && X86
>>> + select ACPI_WMI if ACPI && X86
>>> + select ACPI_VIDEO if ACPI && X86
>>> help
>>> Choose this option if you have a recent AMD Radeon graphics card.
>>>
>>> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
>>> index fa7421afb9a6..abf209e36fca 100644
>>> --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
>>> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
>>> @@ -26,6 +26,8 @@
>>>
>>> #include <linux/pci.h>
>>>
>>> +#include <acpi/video.h>
>>> +
>>> #include <drm/drm_crtc_helper.h>
>>> #include <drm/amdgpu_drm.h>
>>> #include "amdgpu.h"
>>> @@ -184,6 +186,11 @@ void amdgpu_atombios_encoder_init_backlight(struct amdgpu_encoder *amdgpu_encode
>>> if (!(adev->mode_info.firmware_flags & ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
>>> return;
>>>
>>> + if (!acpi_video_backlight_use_native()) {
>>> + DRM_INFO("Skipping amdgpu atom DIG backlight registration\n");
>>> + return;
>>> + }
>>> +
>>> pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
>>> if (!pdata) {
>>> DRM_ERROR("Memory allocation failed\n");
>>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> index 5eb111d35793..3b03a95e59a8 100644
>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> @@ -86,6 +86,8 @@
>>> #include <drm/drm_audio_component.h>
>>> #include <drm/drm_gem_atomic_helper.h>
>>>
>>> +#include <acpi/video.h>
>>> +
>>> #include "ivsrcid/dcn/irqsrcs_dcn_1_0.h"
>>>
>>> #include "dcn/dcn_1_0_offset.h"
>>> @@ -4050,6 +4052,11 @@ amdgpu_dm_register_backlight_device(struct amdgpu_display_manager *dm)
>>> amdgpu_dm_update_backlight_caps(dm, dm->num_of_edps);
>>> dm->brightness[dm->num_of_edps] = AMDGPU_MAX_BL_LEVEL;
>>>
>>> + if (!acpi_video_backlight_use_native()) {
>>> + DRM_INFO("Skipping amdgpu DM backlight registration\n");
>>> + return;
>>> + }
>>> +
>>> props.max_brightness = AMDGPU_MAX_BL_LEVEL;
>>> props.brightness = AMDGPU_MAX_BL_LEVEL;
>>> props.type = BACKLIGHT_RAW;
>>> --
>>> 2.36.0
>>>
>
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v2 04/29] drm/radeon: Don't register backlight when another backlight should be used
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (2 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 03/29] drm/amdgpu: " Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-20 16:45 ` Alex Deucher
2022-07-12 19:38 ` [PATCH v2 05/29] drm/nouveau: " Hans de Goede
` (26 subsequent siblings)
30 siblings, 1 reply; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
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:
- To avoid linker errors when radeon is builtin and video_detect.c is in
a module, select ACPI_VIDEO and its deps if ACPI && X86 are enabled.
When these are not set, ACPI_VIDEO is disabled, ensuring the stubs
from acpi/video.h will be used.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/gpu/drm/Kconfig | 6 ++++++
drivers/gpu/drm/radeon/atombios_encoders.c | 7 +++++++
drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 7 +++++++
3 files changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index d65119860760..a07b76e06f84 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -234,6 +234,12 @@ config DRM_RADEON
select HWMON
select BACKLIGHT_CLASS_DEVICE
select INTERVAL_TREE
+ # radeon depends on ACPI_VIDEO when X86 and ACPI are both enabled
+ # for select to work, ACPI_VIDEO's dependencies must also be selected
+ select INPUT if ACPI && X86
+ select X86_PLATFORM_DEVICES if ACPI && X86
+ select ACPI_WMI if ACPI && X86
+ select ACPI_VIDEO if ACPI && X86
help
Choose this option if you have an ATI Radeon graphics card. There
are both PCI and AGP versions. You don't need to choose this to
diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
index c93040e60d04..958920230d6f 100644
--- a/drivers/gpu/drm/radeon/atombios_encoders.c
+++ b/drivers/gpu/drm/radeon/atombios_encoders.c
@@ -32,6 +32,8 @@
#include <drm/drm_file.h>
#include <drm/radeon_drm.h>
+#include <acpi/video.h>
+
#include "atom.h"
#include "radeon_atombios.h"
#include "radeon.h"
@@ -209,6 +211,11 @@ void radeon_atom_backlight_init(struct radeon_encoder *radeon_encoder,
if (!(rdev->mode_info.firmware_flags & ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
return;
+ if (!acpi_video_backlight_use_native()) {
+ DRM_INFO("Skipping radeon atom DIG backlight registration\n");
+ return;
+ }
+
pdata = kmalloc(sizeof(struct radeon_backlight_privdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("Memory allocation failed\n");
diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
index 1a66fb969ee7..d24cedf20c47 100644
--- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
@@ -33,6 +33,8 @@
#include <drm/drm_util.h>
#include <drm/radeon_drm.h>
+#include <acpi/video.h>
+
#include "radeon.h"
#include "radeon_asic.h"
#include "radeon_legacy_encoders.h"
@@ -387,6 +389,11 @@ void radeon_legacy_backlight_init(struct radeon_encoder *radeon_encoder,
return;
#endif
+ if (!acpi_video_backlight_use_native()) {
+ DRM_INFO("Skipping radeon legacy LVDS backlight registration\n");
+ return;
+ }
+
pdata = kmalloc(sizeof(struct radeon_backlight_privdata), GFP_KERNEL);
if (!pdata) {
DRM_ERROR("Memory allocation failed\n");
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v2 04/29] drm/radeon: Don't register backlight when another backlight should be used
2022-07-12 19:38 ` [PATCH v2 04/29] drm/radeon: " Hans de Goede
@ 2022-07-20 16:45 ` Alex Deucher
0 siblings, 0 replies; 58+ messages in thread
From: Alex Deucher @ 2022-07-20 16:45 UTC (permalink / raw)
To: Hans de Goede
Cc: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko, linux-acpi, David Airlie, nouveau,
intel-gfx, dri-devel, platform-driver-x86, amd-gfx, Len Brown
On Tue, Jul 12, 2022 at 3:39 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> 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:
> - To avoid linker errors when radeon is builtin and video_detect.c is in
> a module, select ACPI_VIDEO and its deps if ACPI && X86 are enabled.
> When these are not set, ACPI_VIDEO is disabled, ensuring the stubs
> from acpi/video.h will be used.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> drivers/gpu/drm/Kconfig | 6 ++++++
> drivers/gpu/drm/radeon/atombios_encoders.c | 7 +++++++
> drivers/gpu/drm/radeon/radeon_legacy_encoders.c | 7 +++++++
> 3 files changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index d65119860760..a07b76e06f84 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -234,6 +234,12 @@ config DRM_RADEON
> select HWMON
> select BACKLIGHT_CLASS_DEVICE
> select INTERVAL_TREE
> + # radeon depends on ACPI_VIDEO when X86 and ACPI are both enabled
> + # for select to work, ACPI_VIDEO's dependencies must also be selected
> + select INPUT if ACPI && X86
> + select X86_PLATFORM_DEVICES if ACPI && X86
> + select ACPI_WMI if ACPI && X86
> + select ACPI_VIDEO if ACPI && X86
> help
> Choose this option if you have an ATI Radeon graphics card. There
> are both PCI and AGP versions. You don't need to choose this to
> diff --git a/drivers/gpu/drm/radeon/atombios_encoders.c b/drivers/gpu/drm/radeon/atombios_encoders.c
> index c93040e60d04..958920230d6f 100644
> --- a/drivers/gpu/drm/radeon/atombios_encoders.c
> +++ b/drivers/gpu/drm/radeon/atombios_encoders.c
> @@ -32,6 +32,8 @@
> #include <drm/drm_file.h>
> #include <drm/radeon_drm.h>
>
> +#include <acpi/video.h>
> +
> #include "atom.h"
> #include "radeon_atombios.h"
> #include "radeon.h"
> @@ -209,6 +211,11 @@ void radeon_atom_backlight_init(struct radeon_encoder *radeon_encoder,
> if (!(rdev->mode_info.firmware_flags & ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
> return;
>
> + if (!acpi_video_backlight_use_native()) {
> + DRM_INFO("Skipping radeon atom DIG backlight registration\n");
> + return;
> + }
> +
> pdata = kmalloc(sizeof(struct radeon_backlight_privdata), GFP_KERNEL);
> if (!pdata) {
> DRM_ERROR("Memory allocation failed\n");
> diff --git a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> index 1a66fb969ee7..d24cedf20c47 100644
> --- a/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_legacy_encoders.c
> @@ -33,6 +33,8 @@
> #include <drm/drm_util.h>
> #include <drm/radeon_drm.h>
>
> +#include <acpi/video.h>
> +
> #include "radeon.h"
> #include "radeon_asic.h"
> #include "radeon_legacy_encoders.h"
> @@ -387,6 +389,11 @@ void radeon_legacy_backlight_init(struct radeon_encoder *radeon_encoder,
> return;
> #endif
>
> + if (!acpi_video_backlight_use_native()) {
> + DRM_INFO("Skipping radeon legacy LVDS backlight registration\n");
> + return;
> + }
> +
> pdata = kmalloc(sizeof(struct radeon_backlight_privdata), GFP_KERNEL);
> if (!pdata) {
> DRM_ERROR("Memory allocation failed\n");
> --
> 2.36.0
>
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v2 05/29] drm/nouveau: Don't register backlight when another backlight should be used
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (3 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 04/29] drm/radeon: " Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-14 21:04 ` Lyude Paul
2022-07-12 19:38 ` [PATCH v2 06/29] ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type() Hans de Goede
` (25 subsequent siblings)
30 siblings, 1 reply; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
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.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index a2141d3d9b1d..91c504c7b82c 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -34,6 +34,8 @@
#include <linux/backlight.h>
#include <linux/idr.h>
+#include <acpi/video.h>
+
#include "nouveau_drv.h"
#include "nouveau_reg.h"
#include "nouveau_encoder.h"
@@ -405,6 +407,11 @@ nouveau_backlight_init(struct drm_connector *connector)
goto fail_alloc;
}
+ if (!acpi_video_backlight_use_native()) {
+ NV_INFO(drm, "Skipping nv_backlight registration\n");
+ goto fail_alloc;
+ }
+
if (!nouveau_get_backlight_name(backlight_name, bl)) {
NV_ERROR(drm, "Failed to retrieve a unique name for the backlight interface\n");
goto fail_alloc;
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v2 05/29] drm/nouveau: Don't register backlight when another backlight should be used
2022-07-12 19:38 ` [PATCH v2 05/29] drm/nouveau: " Hans de Goede
@ 2022-07-14 21:04 ` Lyude Paul
0 siblings, 0 replies; 58+ messages in thread
From: Lyude Paul @ 2022-07-14 21:04 UTC (permalink / raw)
To: Hans de Goede, Ben Skeggs, Karol Herbst, Daniel Dadap,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher,
Christian König, Pan, Xinhui, Rafael J . Wysocki,
Mika Westerberg, Lukas Wunner, Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Reviewed-by: Lyude Paul <lyude@redhat.com>
You also have permission to push this to drm-misc-whatever
On Tue, 2022-07-12 at 21:38 +0200, Hans de Goede wrote:
> 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.
>
> Reviewed-by: Lyude Paul <lyude@redhat.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> index a2141d3d9b1d..91c504c7b82c 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
> @@ -34,6 +34,8 @@
> #include <linux/backlight.h>
> #include <linux/idr.h>
>
> +#include <acpi/video.h>
> +
> #include "nouveau_drv.h"
> #include "nouveau_reg.h"
> #include "nouveau_encoder.h"
> @@ -405,6 +407,11 @@ nouveau_backlight_init(struct drm_connector *connector)
> goto fail_alloc;
> }
>
> + if (!acpi_video_backlight_use_native()) {
> + NV_INFO(drm, "Skipping nv_backlight registration\n");
> + goto fail_alloc;
> + }
> +
> if (!nouveau_get_backlight_name(backlight_name, bl)) {
> NV_ERROR(drm, "Failed to retrieve a unique name for the
> backlight interface\n");
> goto fail_alloc;
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v2 06/29] ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type()
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (4 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 05/29] drm/nouveau: " Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-12 19:38 ` [PATCH v2 07/29] ACPI: video: Remove acpi_video_bus from list before tearing it down Hans de Goede
` (24 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
All x86/ACPI kms drivers which register native/BACKLIGHT_RAW type
backlight devices call acpi_video_backlight_use_native() now. This sets
__acpi_video_get_backlight_type()'s internal static native_available flag.
This makes the backlight_device_get_by_type(BACKLIGHT_RAW) check
unnecessary.
Relying on the cached native_available value not only is simpler, it will
also work correctly in cases where then native backlight registration was
skipped because of acpi_video_backlight_use_native() returning false.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/video_detect.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 4346c990022d..c18047da9f37 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -585,8 +585,7 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
return acpi_backlight_vendor;
- if (acpi_osi_is_win8() &&
- (native_available || backlight_device_get_by_type(BACKLIGHT_RAW)))
+ if (acpi_osi_is_win8() && native_available)
return acpi_backlight_native;
return acpi_backlight_video;
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 07/29] ACPI: video: Remove acpi_video_bus from list before tearing it down
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (5 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 06/29] ACPI: video: Drop backlight_device_get_by_type() call from acpi_video_get_backlight_type() Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-12 19:38 ` [PATCH v2 08/29] ACPI: video: Simplify acpi_video_unregister_backlight() Hans de Goede
` (23 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Move the list_del removing an acpi_video_bus from video_bus_head
on teardown to before the teardown is done, to avoid code iterating
over the video_bus_head list seeing acpi_video_bus objects on there
which are (partly) torn down already.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/acpi_video.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 43177c20ce4f..09899b7f7fab 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -2117,14 +2117,14 @@ static int acpi_video_bus_remove(struct acpi_device *device)
video = acpi_driver_data(device);
- acpi_video_bus_remove_notify_handler(video);
- acpi_video_bus_unregister_backlight(video);
- acpi_video_bus_put_devices(video);
-
mutex_lock(&video_list_lock);
list_del(&video->entry);
mutex_unlock(&video_list_lock);
+ acpi_video_bus_remove_notify_handler(video);
+ acpi_video_bus_unregister_backlight(video);
+ acpi_video_bus_put_devices(video);
+
kfree(video->attached_array);
kfree(video);
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 08/29] ACPI: video: Simplify acpi_video_unregister_backlight()
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (6 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 07/29] ACPI: video: Remove acpi_video_bus from list before tearing it down Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-12 19:38 ` [PATCH v2 09/29] ACPI: video: Make backlight class device registration a separate step Hans de Goede
` (22 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
When acpi_video_register() has not run yet the video_bus_head will be
empty, so there is no need to check the register_count flag first.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/acpi_video.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 09899b7f7fab..6944794797a5 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -2263,14 +2263,10 @@ void acpi_video_unregister_backlight(void)
{
struct acpi_video_bus *video;
- mutex_lock(®ister_count_mutex);
- if (register_count) {
- mutex_lock(&video_list_lock);
- list_for_each_entry(video, &video_bus_head, entry)
- acpi_video_bus_unregister_backlight(video);
- mutex_unlock(&video_list_lock);
- }
- mutex_unlock(®ister_count_mutex);
+ mutex_lock(&video_list_lock);
+ list_for_each_entry(video, &video_bus_head, entry)
+ acpi_video_bus_unregister_backlight(video);
+ mutex_unlock(&video_list_lock);
}
bool acpi_video_handles_brightness_key_presses(void)
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 09/29] ACPI: video: Make backlight class device registration a separate step
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (7 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 08/29] ACPI: video: Simplify acpi_video_unregister_backlight() Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-20 16:50 ` Alex Deucher
2022-07-12 19:38 ` [PATCH v2 10/29] ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers Hans de Goede
` (21 subsequent siblings)
30 siblings, 1 reply; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
On x86/ACPI boards the acpi_video driver will usually initializing before
the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
to show up and then the kms driver registers its own native backlight
device after which the drivers/acpi/video_detect.c code unregisters
the acpi_video0 device (when acpi_video_get_backlight_type()==native).
This means that userspace briefly sees 2 devices and the disappearing of
acpi_video0 after a brief time confuses the systemd backlight level
save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this make backlight class device registration a separate step
done by a new acpi_video_register_backlight() function. The intend is for
this to be called by the drm/kms driver *after* it is done setting up its
own native backlight device. So that acpi_video_get_backlight_type() knows
if a native backlight will be available or not at acpi_video backlight
registration time, avoiding the add + remove dance.
Note the new acpi_video_register_backlight() function is also called from
a delayed work to ensure that the acpi_video backlight devices does get
registered if necessary even if there is no drm/kms driver or when it is
disabled.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/acpi_video.c | 45 ++++++++++++++++++++++++++++++++++++---
include/acpi/video.h | 2 ++
2 files changed, 44 insertions(+), 3 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 6944794797a5..c4c3a9e7ce69 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -31,6 +31,12 @@
#define ACPI_VIDEO_BUS_NAME "Video Bus"
#define ACPI_VIDEO_DEVICE_NAME "Video Device"
+/*
+ * Display probing is known to take up to 5 seconds, so delay the fallback
+ * backlight registration by 5 seconds + 3 seconds for some extra margin.
+ */
+#define ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY (8 * HZ)
+
#define MAX_NAME_LEN 20
MODULE_AUTHOR("Bruno Ducrot");
@@ -81,6 +87,9 @@ static LIST_HEAD(video_bus_head);
static int acpi_video_bus_add(struct acpi_device *device);
static int acpi_video_bus_remove(struct acpi_device *device);
static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
+static void acpi_video_bus_register_backlight_work(struct work_struct *ignored);
+static DECLARE_DELAYED_WORK(video_bus_register_backlight_work,
+ acpi_video_bus_register_backlight_work);
void acpi_video_detect_exit(void);
/*
@@ -1865,8 +1874,6 @@ static int acpi_video_bus_register_backlight(struct acpi_video_bus *video)
if (video->backlight_registered)
return 0;
- acpi_video_run_bcl_for_osi(video);
-
if (acpi_video_get_backlight_type() != acpi_backlight_video)
return 0;
@@ -2092,7 +2099,11 @@ static int acpi_video_bus_add(struct acpi_device *device)
list_add_tail(&video->entry, &video_bus_head);
mutex_unlock(&video_list_lock);
- acpi_video_bus_register_backlight(video);
+ /*
+ * The userspace visible backlight_device gets registered separately
+ * from acpi_video_register_backlight().
+ */
+ acpi_video_run_bcl_for_osi(video);
acpi_video_bus_add_notify_handler(video);
return 0;
@@ -2131,6 +2142,11 @@ static int acpi_video_bus_remove(struct acpi_device *device)
return 0;
}
+static void acpi_video_bus_register_backlight_work(struct work_struct *ignored)
+{
+ acpi_video_register_backlight();
+}
+
static int __init is_i740(struct pci_dev *dev)
{
if (dev->device == 0x00D1)
@@ -2241,6 +2257,17 @@ int acpi_video_register(void)
*/
register_count = 1;
+ /*
+ * acpi_video_bus_add() skips registering the userspace visible
+ * backlight_device. The intend is for this to be registered by the
+ * drm/kms driver calling acpi_video_register_backlight() *after* it is
+ * done setting up its own native backlight device. The delayed work
+ * ensures that acpi_video_register_backlight() always gets called
+ * eventually, in case there is no drm/kms driver or it is disabled.
+ */
+ schedule_delayed_work(&video_bus_register_backlight_work,
+ ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY);
+
leave:
mutex_unlock(®ister_count_mutex);
return ret;
@@ -2251,6 +2278,7 @@ void acpi_video_unregister(void)
{
mutex_lock(®ister_count_mutex);
if (register_count) {
+ cancel_delayed_work_sync(&video_bus_register_backlight_work);
acpi_bus_unregister_driver(&acpi_video_bus);
register_count = 0;
has_backlight = false;
@@ -2259,6 +2287,17 @@ void acpi_video_unregister(void)
}
EXPORT_SYMBOL(acpi_video_unregister);
+void acpi_video_register_backlight(void)
+{
+ struct acpi_video_bus *video;
+
+ mutex_lock(&video_list_lock);
+ list_for_each_entry(video, &video_bus_head, entry)
+ acpi_video_bus_register_backlight(video);
+ mutex_unlock(&video_list_lock);
+}
+EXPORT_SYMBOL(acpi_video_register_backlight);
+
void acpi_video_unregister_backlight(void)
{
struct acpi_video_bus *video;
diff --git a/include/acpi/video.h b/include/acpi/video.h
index 4705e339c252..0625806d3bbd 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -53,6 +53,7 @@ enum acpi_backlight_type {
#if IS_ENABLED(CONFIG_ACPI_VIDEO)
extern int acpi_video_register(void);
extern void acpi_video_unregister(void);
+extern void acpi_video_register_backlight(void);
extern int acpi_video_get_edid(struct acpi_device *device, int type,
int device_id, void **edid);
extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
@@ -69,6 +70,7 @@ extern int acpi_video_get_levels(struct acpi_device *device,
#else
static inline int acpi_video_register(void) { return -ENODEV; }
static inline void acpi_video_unregister(void) { return; }
+static inline void acpi_video_register_backlight(void) { return; }
static inline int acpi_video_get_edid(struct acpi_device *device, int type,
int device_id, void **edid)
{
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v2 09/29] ACPI: video: Make backlight class device registration a separate step
2022-07-12 19:38 ` [PATCH v2 09/29] ACPI: video: Make backlight class device registration a separate step Hans de Goede
@ 2022-07-20 16:50 ` Alex Deucher
0 siblings, 0 replies; 58+ messages in thread
From: Alex Deucher @ 2022-07-20 16:50 UTC (permalink / raw)
To: Hans de Goede
Cc: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko, linux-acpi, David Airlie, nouveau,
intel-gfx, dri-devel, platform-driver-x86, amd-gfx, Len Brown
On Tue, Jul 12, 2022 at 3:40 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> On x86/ACPI boards the acpi_video driver will usually initializing before
initializing -> initialize
> the kms driver (except i915). This causes /sys/class/backlight/acpi_video0
> to show up and then the kms driver registers its own native backlight
> device after which the drivers/acpi/video_detect.c code unregisters
> the acpi_video0 device (when acpi_video_get_backlight_type()==native).
>
> This means that userspace briefly sees 2 devices and the disappearing of
> acpi_video0 after a brief time confuses the systemd backlight level
> save/restore code, see e.g.:
> https://bbs.archlinux.org/viewtopic.php?id=269920
>
> To fix this make backlight class device registration a separate step
> done by a new acpi_video_register_backlight() function. The intend is for
> this to be called by the drm/kms driver *after* it is done setting up its
> own native backlight device. So that acpi_video_get_backlight_type() knows
> if a native backlight will be available or not at acpi_video backlight
> registration time, avoiding the add + remove dance.
>
> Note the new acpi_video_register_backlight() function is also called from
> a delayed work to ensure that the acpi_video backlight devices does get
> registered if necessary even if there is no drm/kms driver or when it is
> disabled.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/acpi/acpi_video.c | 45 ++++++++++++++++++++++++++++++++++++---
> include/acpi/video.h | 2 ++
> 2 files changed, 44 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
> index 6944794797a5..c4c3a9e7ce69 100644
> --- a/drivers/acpi/acpi_video.c
> +++ b/drivers/acpi/acpi_video.c
> @@ -31,6 +31,12 @@
> #define ACPI_VIDEO_BUS_NAME "Video Bus"
> #define ACPI_VIDEO_DEVICE_NAME "Video Device"
>
> +/*
> + * Display probing is known to take up to 5 seconds, so delay the fallback
> + * backlight registration by 5 seconds + 3 seconds for some extra margin.
> + */
> +#define ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY (8 * HZ)
> +
> #define MAX_NAME_LEN 20
>
> MODULE_AUTHOR("Bruno Ducrot");
> @@ -81,6 +87,9 @@ static LIST_HEAD(video_bus_head);
> static int acpi_video_bus_add(struct acpi_device *device);
> static int acpi_video_bus_remove(struct acpi_device *device);
> static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
> +static void acpi_video_bus_register_backlight_work(struct work_struct *ignored);
> +static DECLARE_DELAYED_WORK(video_bus_register_backlight_work,
> + acpi_video_bus_register_backlight_work);
> void acpi_video_detect_exit(void);
>
> /*
> @@ -1865,8 +1874,6 @@ static int acpi_video_bus_register_backlight(struct acpi_video_bus *video)
> if (video->backlight_registered)
> return 0;
>
> - acpi_video_run_bcl_for_osi(video);
> -
> if (acpi_video_get_backlight_type() != acpi_backlight_video)
> return 0;
>
> @@ -2092,7 +2099,11 @@ static int acpi_video_bus_add(struct acpi_device *device)
> list_add_tail(&video->entry, &video_bus_head);
> mutex_unlock(&video_list_lock);
>
> - acpi_video_bus_register_backlight(video);
> + /*
> + * The userspace visible backlight_device gets registered separately
> + * from acpi_video_register_backlight().
> + */
> + acpi_video_run_bcl_for_osi(video);
> acpi_video_bus_add_notify_handler(video);
>
> return 0;
> @@ -2131,6 +2142,11 @@ static int acpi_video_bus_remove(struct acpi_device *device)
> return 0;
> }
>
> +static void acpi_video_bus_register_backlight_work(struct work_struct *ignored)
> +{
> + acpi_video_register_backlight();
> +}
> +
> static int __init is_i740(struct pci_dev *dev)
> {
> if (dev->device == 0x00D1)
> @@ -2241,6 +2257,17 @@ int acpi_video_register(void)
> */
> register_count = 1;
>
> + /*
> + * acpi_video_bus_add() skips registering the userspace visible
> + * backlight_device. The intend is for this to be registered by the
> + * drm/kms driver calling acpi_video_register_backlight() *after* it is
> + * done setting up its own native backlight device. The delayed work
> + * ensures that acpi_video_register_backlight() always gets called
> + * eventually, in case there is no drm/kms driver or it is disabled.
> + */
> + schedule_delayed_work(&video_bus_register_backlight_work,
> + ACPI_VIDEO_REGISTER_BACKLIGHT_DELAY);
> +
> leave:
> mutex_unlock(®ister_count_mutex);
> return ret;
> @@ -2251,6 +2278,7 @@ void acpi_video_unregister(void)
> {
> mutex_lock(®ister_count_mutex);
> if (register_count) {
> + cancel_delayed_work_sync(&video_bus_register_backlight_work);
> acpi_bus_unregister_driver(&acpi_video_bus);
> register_count = 0;
> has_backlight = false;
> @@ -2259,6 +2287,17 @@ void acpi_video_unregister(void)
> }
> EXPORT_SYMBOL(acpi_video_unregister);
>
> +void acpi_video_register_backlight(void)
> +{
> + struct acpi_video_bus *video;
> +
> + mutex_lock(&video_list_lock);
> + list_for_each_entry(video, &video_bus_head, entry)
> + acpi_video_bus_register_backlight(video);
> + mutex_unlock(&video_list_lock);
> +}
> +EXPORT_SYMBOL(acpi_video_register_backlight);
> +
> void acpi_video_unregister_backlight(void)
> {
> struct acpi_video_bus *video;
> diff --git a/include/acpi/video.h b/include/acpi/video.h
> index 4705e339c252..0625806d3bbd 100644
> --- a/include/acpi/video.h
> +++ b/include/acpi/video.h
> @@ -53,6 +53,7 @@ enum acpi_backlight_type {
> #if IS_ENABLED(CONFIG_ACPI_VIDEO)
> extern int acpi_video_register(void);
> extern void acpi_video_unregister(void);
> +extern void acpi_video_register_backlight(void);
> extern int acpi_video_get_edid(struct acpi_device *device, int type,
> int device_id, void **edid);
> extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
> @@ -69,6 +70,7 @@ extern int acpi_video_get_levels(struct acpi_device *device,
> #else
> static inline int acpi_video_register(void) { return -ENODEV; }
> static inline void acpi_video_unregister(void) { return; }
> +static inline void acpi_video_register_backlight(void) { return; }
> static inline int acpi_video_get_edid(struct acpi_device *device, int type,
> int device_id, void **edid)
> {
> --
> 2.36.0
>
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v2 10/29] ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (8 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 09/29] ACPI: video: Make backlight class device registration a separate step Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-12 19:38 ` [PATCH v2 11/29] drm/i915: Call acpi_video_register_backlight() (v2) Hans de Goede
` (20 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Remove the code to unregister acpi_video backlight devices when
a native backlight device gets registered later.
Now that the acpi_video backlight device registration is a separate step
which runs later, after the drm/kms driver is done setting up its own
native backlight device, it is no longer necessary to monitor for a
native (BACKLIGHT_RAW) device showing up later and to then unregister
the acpi_video backlight device(s).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/acpi_video.c | 2 --
drivers/acpi/video_detect.c | 36 ------------------------------------
2 files changed, 38 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index c4c3a9e7ce69..4fc2a8100865 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -90,7 +90,6 @@ static void acpi_video_bus_notify(struct acpi_device *device, u32 event);
static void acpi_video_bus_register_backlight_work(struct work_struct *ignored);
static DECLARE_DELAYED_WORK(video_bus_register_backlight_work,
acpi_video_bus_register_backlight_work);
-void acpi_video_detect_exit(void);
/*
* Indices in the _BCL method response: the first two items are special,
@@ -2343,7 +2342,6 @@ static int __init acpi_video_init(void)
static void __exit acpi_video_exit(void)
{
- acpi_video_detect_exit();
acpi_video_unregister();
}
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index c18047da9f37..f6bdc0c77e9a 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -38,10 +38,6 @@
void acpi_video_unregister_backlight(void);
-static bool backlight_notifier_registered;
-static struct notifier_block backlight_nb;
-static struct work_struct backlight_notify_work;
-
static enum acpi_backlight_type acpi_backlight_cmdline = acpi_backlight_undef;
static enum acpi_backlight_type acpi_backlight_dmi = acpi_backlight_undef;
@@ -515,26 +511,6 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
{ },
};
-/* This uses a workqueue to avoid various locking ordering issues */
-static void acpi_video_backlight_notify_work(struct work_struct *work)
-{
- if (acpi_video_get_backlight_type() != acpi_backlight_video)
- acpi_video_unregister_backlight();
-}
-
-static int acpi_video_backlight_notify(struct notifier_block *nb,
- unsigned long val, void *bd)
-{
- struct backlight_device *backlight = bd;
-
- /* A raw bl registering may change video -> native */
- if (backlight->props.type == BACKLIGHT_RAW &&
- val == BACKLIGHT_REGISTERED)
- schedule_work(&backlight_notify_work);
-
- return NOTIFY_OK;
-}
-
/*
* Determine which type of backlight interface to use on this system,
* First check cmdline, then dmi quirks, then do autodetect.
@@ -564,12 +540,6 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
ACPI_UINT32_MAX, find_video, NULL,
&video_caps, NULL);
- INIT_WORK(&backlight_notify_work,
- acpi_video_backlight_notify_work);
- backlight_nb.notifier_call = acpi_video_backlight_notify;
- backlight_nb.priority = 0;
- if (backlight_register_notifier(&backlight_nb) == 0)
- backlight_notifier_registered = true;
init_done = true;
}
if (native)
@@ -616,9 +586,3 @@ void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
acpi_video_unregister_backlight();
}
EXPORT_SYMBOL(acpi_video_set_dmi_backlight_type);
-
-void __exit acpi_video_detect_exit(void)
-{
- if (backlight_notifier_registered)
- backlight_unregister_notifier(&backlight_nb);
-}
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 11/29] drm/i915: Call acpi_video_register_backlight() (v2)
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (9 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 10/29] ACPI: video: Remove code to unregister acpi_video backlight when a native backlight registers Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-12 19:38 ` [PATCH v2 12/29] drm/nouveau: Register ACPI video backlight when nv_backlight registration fails Hans de Goede
` (19 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
On machins without an i915 opregion the acpi_video driver immediately
probes the ACPI video bus and used to also immediately register
acpi_video# backlight devices when supported.
Once the drm/kms driver then loaded later and possibly registered
a native backlight device then the drivers/acpi/video_detect.c code
unregistered the acpi_video0 device to avoid there being 2 backlight
devices (when acpi_video_get_backlight_type()==native).
This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.
Add a call to the new acpi_video_register_backlight() after the i915 calls
acpi_video_register() (after setting up the i915 opregion) so that the
acpi_video backlight devices get registered on systems where the i915
native backlight device is not registered.
Changes in v2:
-Only call acpi_video_register_backlight() when a panel is detected
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/gpu/drm/i915/display/intel_display.c | 8 ++++++++
drivers/gpu/drm/i915/display/intel_panel.c | 3 +++
drivers/gpu/drm/i915/i915_drv.h | 2 ++
3 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c
index a0f84cbe974f..6e120de83c0f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9086,6 +9086,14 @@ void intel_display_driver_register(struct drm_i915_private *i915)
/* Must be done after probing outputs */
intel_opregion_register(i915);
acpi_video_register();
+ /*
+ * Only call this if i915 is driving the internal panel. If the internal
+ * panel is not driven by i915 then another GPU driver may still register
+ * a native backlight driver later and this should only be called after
+ * any native backlights have been registered.
+ */
+ if (i915->have_panel)
+ acpi_video_register_backlight();
intel_audio_init(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_panel.c b/drivers/gpu/drm/i915/display/intel_panel.c
index 237a40623dd7..4536c527f50c 100644
--- a/drivers/gpu/drm/i915/display/intel_panel.c
+++ b/drivers/gpu/drm/i915/display/intel_panel.c
@@ -646,8 +646,11 @@ intel_panel_mode_valid(struct intel_connector *connector,
int intel_panel_init(struct intel_connector *connector)
{
+ struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_panel *panel = &connector->panel;
+ dev_priv->have_panel = true;
+
intel_backlight_init_funcs(panel);
drm_dbg_kms(connector->base.dev,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d25647be25d1..be6e8c6d8f73 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -756,6 +756,8 @@ struct drm_i915_private {
bool ipc_enabled;
+ bool have_panel;
+
struct intel_audio_private audio;
struct i915_pmu pmu;
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 12/29] drm/nouveau: Register ACPI video backlight when nv_backlight registration fails
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (10 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 11/29] drm/i915: Call acpi_video_register_backlight() (v2) Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-12 19:38 ` [PATCH v2 13/29] drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration Hans de Goede
` (18 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Typically the acpi_video driver will initialize before nouveau, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
nouveau would register its own nv_backlight device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.
This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.
Add a call to the new acpi_video_register_backlight() when native backlight
device registration has failed / was skipped to ensure that there is a
backlight device available before the drm_device gets registered with
userspace.
Reviewed-by: Lyude Paul <lyude@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/gpu/drm/nouveau/nouveau_backlight.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c b/drivers/gpu/drm/nouveau/nouveau_backlight.c
index 91c504c7b82c..befff2a8b763 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -437,6 +437,13 @@ nouveau_backlight_init(struct drm_connector *connector)
fail_alloc:
kfree(bl);
+ /*
+ * If we get here we have an internal panel, but no nv_backlight,
+ * try registering an ACPI video backlight device instead.
+ */
+ if (ret == 0)
+ acpi_video_register_backlight();
+
return ret;
}
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 13/29] drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (11 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 12/29] drm/nouveau: Register ACPI video backlight when nv_backlight registration fails Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-20 16:53 ` Alex Deucher
2022-07-12 19:38 ` [PATCH v2 14/29] drm/radeon: Register ACPI video backlight when skipping radeon " Hans de Goede
` (17 subsequent siblings)
30 siblings, 1 reply; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Typically the acpi_video driver will initialize before amdgpu, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
amdgpu would register its own amdgpu_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.
This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.
Add a call to the new acpi_video_register_backlight() when amdgpu skips
registering its own backlight device because of either the firmware_flags
or the acpi_video_get_backlight_type() return value. This ensures that
if the acpi_video backlight device should be used, it will be available
before the amdgpu drm_device gets registered with userspace.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 9 +++++++--
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
2 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
index abf209e36fca..45cd9268b426 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
@@ -184,11 +184,11 @@ void amdgpu_atombios_encoder_init_backlight(struct amdgpu_encoder *amdgpu_encode
return;
if (!(adev->mode_info.firmware_flags & ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
- return;
+ goto register_acpi_backlight;
if (!acpi_video_backlight_use_native()) {
DRM_INFO("Skipping amdgpu atom DIG backlight registration\n");
- return;
+ goto register_acpi_backlight;
}
pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
@@ -225,6 +225,11 @@ void amdgpu_atombios_encoder_init_backlight(struct amdgpu_encoder *amdgpu_encode
error:
kfree(pdata);
return;
+
+register_acpi_backlight:
+ /* Try registering an ACPI video backlight device instead. */
+ acpi_video_register_backlight();
+ return;
}
void
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 3b03a95e59a8..a667e66a9842 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -4054,6 +4054,8 @@ amdgpu_dm_register_backlight_device(struct amdgpu_display_manager *dm)
if (!acpi_video_backlight_use_native()) {
DRM_INFO("Skipping amdgpu DM backlight registration\n");
+ /* Try registering an ACPI video backlight device instead. */
+ acpi_video_register_backlight();
return;
}
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v2 13/29] drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration
2022-07-12 19:38 ` [PATCH v2 13/29] drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration Hans de Goede
@ 2022-07-20 16:53 ` Alex Deucher
0 siblings, 0 replies; 58+ messages in thread
From: Alex Deucher @ 2022-07-20 16:53 UTC (permalink / raw)
To: Hans de Goede
Cc: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko, linux-acpi, David Airlie, nouveau,
intel-gfx, dri-devel, platform-driver-x86, amd-gfx, Len Brown
On Tue, Jul 12, 2022 at 3:40 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Typically the acpi_video driver will initialize before amdgpu, which
> used to cause /sys/class/backlight/acpi_video0 to get registered and then
> amdgpu would register its own amdgpu_bl# device later. After which
> the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
> to avoid there being 2 backlight devices.
>
> This means that userspace used to briefly see 2 devices and the
> disappearing of acpi_video0 after a brief time confuses the systemd
> backlight level save/restore code, see e.g.:
> https://bbs.archlinux.org/viewtopic.php?id=269920
>
> To fix this the ACPI video code has been modified to make backlight class
> device registration a separate step, relying on the drm/kms driver to
> ask for the acpi_video backlight registration after it is done setting up
> its native backlight device.
>
> Add a call to the new acpi_video_register_backlight() when amdgpu skips
> registering its own backlight device because of either the firmware_flags
> or the acpi_video_get_backlight_type() return value. This ensures that
> if the acpi_video backlight device should be used, it will be available
> before the amdgpu drm_device gets registered with userspace.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/gpu/drm/amd/amdgpu/atombios_encoders.c | 9 +++++++--
> drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 2 ++
> 2 files changed, 9 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> index abf209e36fca..45cd9268b426 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> @@ -184,11 +184,11 @@ void amdgpu_atombios_encoder_init_backlight(struct amdgpu_encoder *amdgpu_encode
> return;
>
> if (!(adev->mode_info.firmware_flags & ATOM_BIOS_INFO_BL_CONTROLLED_BY_GPU))
> - return;
> + goto register_acpi_backlight;
>
> if (!acpi_video_backlight_use_native()) {
> DRM_INFO("Skipping amdgpu atom DIG backlight registration\n");
> - return;
> + goto register_acpi_backlight;
> }
>
> pdata = kmalloc(sizeof(struct amdgpu_backlight_privdata), GFP_KERNEL);
> @@ -225,6 +225,11 @@ void amdgpu_atombios_encoder_init_backlight(struct amdgpu_encoder *amdgpu_encode
> error:
> kfree(pdata);
> return;
> +
> +register_acpi_backlight:
> + /* Try registering an ACPI video backlight device instead. */
> + acpi_video_register_backlight();
> + return;
Can drop the return here. Either way,
Acked-by: Alex Deucher <alexander.deucher@amd.com>
> }
>
> void
> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> index 3b03a95e59a8..a667e66a9842 100644
> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
> @@ -4054,6 +4054,8 @@ amdgpu_dm_register_backlight_device(struct amdgpu_display_manager *dm)
>
> if (!acpi_video_backlight_use_native()) {
> DRM_INFO("Skipping amdgpu DM backlight registration\n");
> + /* Try registering an ACPI video backlight device instead. */
> + acpi_video_register_backlight();
> return;
> }
>
> --
> 2.36.0
>
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v2 14/29] drm/radeon: Register ACPI video backlight when skipping radeon backlight registration
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (12 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 13/29] drm/amdgpu: Register ACPI video backlight when skipping amdgpu backlight registration Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-20 16:54 ` Alex Deucher
2022-07-12 19:38 ` [PATCH v2 15/29] ACPI: video: Refactor acpi_video_get_backlight_type() a bit Hans de Goede
` (16 subsequent siblings)
30 siblings, 1 reply; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Typically the acpi_video driver will initialize before radeon, which
used to cause /sys/class/backlight/acpi_video0 to get registered and then
radeon would register its own radeon_bl# device later. After which
the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
to avoid there being 2 backlight devices.
This means that userspace used to briefly see 2 devices and the
disappearing of acpi_video0 after a brief time confuses the systemd
backlight level save/restore code, see e.g.:
https://bbs.archlinux.org/viewtopic.php?id=269920
To fix this the ACPI video code has been modified to make backlight class
device registration a separate step, relying on the drm/kms driver to
ask for the acpi_video backlight registration after it is done setting up
its native backlight device.
Add a call to the new acpi_video_register_backlight() when radeon skips
registering its own backlight device because of e.g. the firmware_flags
or the acpi_video_get_backlight_type() return value. This ensures that
if the acpi_video backlight device should be used, it will be available
before the radeon drm_device gets registered with userspace.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/gpu/drm/radeon/radeon_encoders.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c
index 46549d5179ee..c1cbebb51be1 100644
--- a/drivers/gpu/drm/radeon/radeon_encoders.c
+++ b/drivers/gpu/drm/radeon/radeon_encoders.c
@@ -30,6 +30,8 @@
#include <drm/drm_device.h>
#include <drm/radeon_drm.h>
+#include <acpi/video.h>
+
#include "radeon.h"
#include "radeon_atombios.h"
#include "radeon_legacy_encoders.h"
@@ -167,7 +169,7 @@ static void radeon_encoder_add_backlight(struct radeon_encoder *radeon_encoder,
return;
if (radeon_backlight == 0) {
- return;
+ use_bl = false;
} else if (radeon_backlight == 1) {
use_bl = true;
} else if (radeon_backlight == -1) {
@@ -193,6 +195,13 @@ static void radeon_encoder_add_backlight(struct radeon_encoder *radeon_encoder,
else
radeon_legacy_backlight_init(radeon_encoder, connector);
}
+
+ /*
+ * If there is no native backlight device (which may happen even when
+ * use_bl==true) try registering an ACPI video backlight device instead.
+ */
+ if (!rdev->mode_info.bl_encoder)
+ acpi_video_register_backlight();
}
void
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v2 14/29] drm/radeon: Register ACPI video backlight when skipping radeon backlight registration
2022-07-12 19:38 ` [PATCH v2 14/29] drm/radeon: Register ACPI video backlight when skipping radeon " Hans de Goede
@ 2022-07-20 16:54 ` Alex Deucher
0 siblings, 0 replies; 58+ messages in thread
From: Alex Deucher @ 2022-07-20 16:54 UTC (permalink / raw)
To: Hans de Goede
Cc: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko, linux-acpi, David Airlie, nouveau,
intel-gfx, dri-devel, platform-driver-x86, amd-gfx, Len Brown
On Tue, Jul 12, 2022 at 3:40 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Typically the acpi_video driver will initialize before radeon, which
> used to cause /sys/class/backlight/acpi_video0 to get registered and then
> radeon would register its own radeon_bl# device later. After which
> the drivers/acpi/video_detect.c code unregistered the acpi_video0 device
> to avoid there being 2 backlight devices.
>
> This means that userspace used to briefly see 2 devices and the
> disappearing of acpi_video0 after a brief time confuses the systemd
> backlight level save/restore code, see e.g.:
> https://bbs.archlinux.org/viewtopic.php?id=269920
>
> To fix this the ACPI video code has been modified to make backlight class
> device registration a separate step, relying on the drm/kms driver to
> ask for the acpi_video backlight registration after it is done setting up
> its native backlight device.
>
> Add a call to the new acpi_video_register_backlight() when radeon skips
> registering its own backlight device because of e.g. the firmware_flags
> or the acpi_video_get_backlight_type() return value. This ensures that
> if the acpi_video backlight device should be used, it will be available
> before the radeon drm_device gets registered with userspace.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
> ---
> drivers/gpu/drm/radeon/radeon_encoders.c | 11 ++++++++++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_encoders.c b/drivers/gpu/drm/radeon/radeon_encoders.c
> index 46549d5179ee..c1cbebb51be1 100644
> --- a/drivers/gpu/drm/radeon/radeon_encoders.c
> +++ b/drivers/gpu/drm/radeon/radeon_encoders.c
> @@ -30,6 +30,8 @@
> #include <drm/drm_device.h>
> #include <drm/radeon_drm.h>
>
> +#include <acpi/video.h>
> +
> #include "radeon.h"
> #include "radeon_atombios.h"
> #include "radeon_legacy_encoders.h"
> @@ -167,7 +169,7 @@ static void radeon_encoder_add_backlight(struct radeon_encoder *radeon_encoder,
> return;
>
> if (radeon_backlight == 0) {
> - return;
> + use_bl = false;
> } else if (radeon_backlight == 1) {
> use_bl = true;
> } else if (radeon_backlight == -1) {
> @@ -193,6 +195,13 @@ static void radeon_encoder_add_backlight(struct radeon_encoder *radeon_encoder,
> else
> radeon_legacy_backlight_init(radeon_encoder, connector);
> }
> +
> + /*
> + * If there is no native backlight device (which may happen even when
> + * use_bl==true) try registering an ACPI video backlight device instead.
> + */
> + if (!rdev->mode_info.bl_encoder)
> + acpi_video_register_backlight();
> }
>
> void
> --
> 2.36.0
>
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v2 15/29] ACPI: video: Refactor acpi_video_get_backlight_type() a bit
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (13 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 14/29] drm/radeon: Register ACPI video backlight when skipping radeon " Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-12 19:38 ` [PATCH v2 16/29] ACPI: video: Add Nvidia WMI EC brightness control detection Hans de Goede
` (15 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Refactor acpi_video_get_backlight_type() so that the heuristics /
detection steps are stricly in order of descending precedence.
Also move the comments describing the steps to when the various steps are
actually done, to avoid the comments getting out of sync with the code.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/video_detect.c | 39 ++++++++++++++++++++++---------------
1 file changed, 23 insertions(+), 16 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index f6bdc0c77e9a..8c2863403040 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -514,16 +514,6 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
/*
* Determine which type of backlight interface to use on this system,
* First check cmdline, then dmi quirks, then do autodetect.
- *
- * The autodetect order is:
- * 1) Is the acpi-video backlight interface supported ->
- * no, use a vendor interface
- * 2) Is this a win8 "ready" BIOS and do we have a native interface ->
- * yes, use a native interface
- * 3) Else use the acpi-video interface
- *
- * Arguably the native on win8 check should be done first, but that would
- * be a behavior change, which may causes issues.
*/
static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
{
@@ -546,19 +536,36 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
native_available = true;
mutex_unlock(&init_mutex);
+ /*
+ * 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;
- if (!(video_caps & ACPI_VIDEO_BACKLIGHT))
- return acpi_backlight_vendor;
-
- if (acpi_osi_is_win8() && native_available)
- return acpi_backlight_native;
+ /* 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;
+ }
- return acpi_backlight_video;
+ /* No ACPI video (old hw), use vendor specific fw methods. */
+ return acpi_backlight_vendor;
}
enum acpi_backlight_type acpi_video_get_backlight_type(void)
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 16/29] ACPI: video: Add Nvidia WMI EC brightness control detection
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (14 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 15/29] ACPI: video: Refactor acpi_video_get_backlight_type() a bit Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-12 20:13 ` Daniel Dadap
2022-07-12 19:38 ` [PATCH v2 17/29] ACPI: video: Add Apple GMUX " Hans de Goede
` (14 subsequent siblings)
30 siblings, 1 reply; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
On some new laptop designs a new Nvidia specific WMI interface is present
which gives info about panel brightness control and may allow controlling
the brightness through this interface when the embedded controller is used
for brightness control.
When this WMI interface is present and indicates that the EC is used,
then this interface should be used for brightness control.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/Kconfig | 1 +
drivers/acpi/video_detect.c | 35 ++++++++++++++++++++++++++++++++++
drivers/gpu/drm/gma500/Kconfig | 2 ++
drivers/gpu/drm/i915/Kconfig | 2 ++
include/acpi/video.h | 1 +
5 files changed, 41 insertions(+)
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 1e34f846508f..c372385cfc3f 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -212,6 +212,7 @@ config ACPI_VIDEO
tristate "Video"
depends on X86 && BACKLIGHT_CLASS_DEVICE
depends on INPUT
+ depends on ACPI_WMI
select THERMAL
help
This driver implements the ACPI Extensions For Display Adapters
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 8c2863403040..7b89dc9a04a2 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -75,6 +75,35 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv)
return AE_OK;
}
+#define WMI_BRIGHTNESS_METHOD_SOURCE 2
+#define WMI_BRIGHTNESS_MODE_GET 0
+#define WMI_BRIGHTNESS_SOURCE_EC 2
+
+struct wmi_brightness_args {
+ u32 mode;
+ u32 val;
+ u32 ret;
+ u32 ignored[3];
+};
+
+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("603E9613-EF25-4338-A3D0-C46177516DB7", 0,
+ WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf);
+ if (ACPI_FAILURE(status))
+ return false;
+
+ return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
+}
+
/* 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)
@@ -518,6 +547,7 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
{
static DEFINE_MUTEX(init_mutex);
+ static bool nvidia_wmi_ec_present;
static bool native_available;
static bool init_done;
static long video_caps;
@@ -530,6 +560,7 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
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;
}
if (native)
@@ -547,6 +578,10 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
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;
+
/* On systems with ACPI video use either native or ACPI video. */
if (video_caps & ACPI_VIDEO_BACKLIGHT) {
/*
diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
index 0cff20265f97..807b989e3c77 100644
--- a/drivers/gpu/drm/gma500/Kconfig
+++ b/drivers/gpu/drm/gma500/Kconfig
@@ -7,6 +7,8 @@ config DRM_GMA500
select ACPI_VIDEO if ACPI
select BACKLIGHT_CLASS_DEVICE if ACPI
select INPUT if ACPI
+ select X86_PLATFORM_DEVICES if ACPI
+ select ACPI_WMI if ACPI
help
Say yes for an experimental 2D KMS framebuffer driver for the
Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and
diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
index 7ae3b7d67fcf..3efce05d7b57 100644
--- a/drivers/gpu/drm/i915/Kconfig
+++ b/drivers/gpu/drm/i915/Kconfig
@@ -23,6 +23,8 @@ config DRM_I915
# but for select to work, need to select ACPI_VIDEO's dependencies, ick
select BACKLIGHT_CLASS_DEVICE if ACPI
select INPUT if ACPI
+ select X86_PLATFORM_DEVICES if ACPI
+ select ACPI_WMI if ACPI
select ACPI_VIDEO if ACPI
select ACPI_BUTTON if ACPI
select SYNC_FILE
diff --git a/include/acpi/video.h b/include/acpi/video.h
index 0625806d3bbd..91578e77ac4e 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -48,6 +48,7 @@ enum acpi_backlight_type {
acpi_backlight_video,
acpi_backlight_vendor,
acpi_backlight_native,
+ acpi_backlight_nvidia_wmi_ec,
};
#if IS_ENABLED(CONFIG_ACPI_VIDEO)
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v2 16/29] ACPI: video: Add Nvidia WMI EC brightness control detection
2022-07-12 19:38 ` [PATCH v2 16/29] ACPI: video: Add Nvidia WMI EC brightness control detection Hans de Goede
@ 2022-07-12 20:13 ` Daniel Dadap
2022-07-15 11:59 ` Hans de Goede
0 siblings, 1 reply; 58+ messages in thread
From: Daniel Dadap @ 2022-07-12 20:13 UTC (permalink / raw)
To: Hans de Goede, Ben Skeggs, Karol Herbst, Lyude,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher,
Christian König, Xinhui, Rafael J . Wysocki,
Mika Westerberg, Lukas Wunner, Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Thanks, Hans:
On 7/12/22 14:38, Hans de Goede wrote:
> On some new laptop designs a new Nvidia specific WMI interface is present
> which gives info about panel brightness control and may allow controlling
> the brightness through this interface when the embedded controller is used
> for brightness control.
>
> When this WMI interface is present and indicates that the EC is used,
> then this interface should be used for brightness control.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/acpi/Kconfig | 1 +
> drivers/acpi/video_detect.c | 35 ++++++++++++++++++++++++++++++++++
> drivers/gpu/drm/gma500/Kconfig | 2 ++
> drivers/gpu/drm/i915/Kconfig | 2 ++
> include/acpi/video.h | 1 +
> 5 files changed, 41 insertions(+)
>
> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
> index 1e34f846508f..c372385cfc3f 100644
> --- a/drivers/acpi/Kconfig
> +++ b/drivers/acpi/Kconfig
> @@ -212,6 +212,7 @@ config ACPI_VIDEO
> tristate "Video"
> depends on X86 && BACKLIGHT_CLASS_DEVICE
> depends on INPUT
> + depends on ACPI_WMI
> select THERMAL
> help
> This driver implements the ACPI Extensions For Display Adapters
> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
> index 8c2863403040..7b89dc9a04a2 100644
> --- a/drivers/acpi/video_detect.c
> +++ b/drivers/acpi/video_detect.c
> @@ -75,6 +75,35 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv)
> return AE_OK;
> }
>
> +#define WMI_BRIGHTNESS_METHOD_SOURCE 2
> +#define WMI_BRIGHTNESS_MODE_GET 0
> +#define WMI_BRIGHTNESS_SOURCE_EC 2
> +
> +struct wmi_brightness_args {
> + u32 mode;
> + u32 val;
> + u32 ret;
> + u32 ignored[3];
> +};
> +
> +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("603E9613-EF25-4338-A3D0-C46177516DB7", 0,
> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf);
> + if (ACPI_FAILURE(status))
> + return false;
> +
> + return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
> +}
> +
The code duplication here with nvidia-wmi-ec-backlight.c is a little
unfortunate. Can we move the constants, struct definition, and WMI GUID
from that file to a header file that's used both by the EC backlight
driver and the ACPI video driver?
I was thinking it might be nice to add a wrapper around
wmi_brightness_notify() in nvidia-wmi-ec-backlight.c that does this
source == WMI_BRIGHTNESS_SOURCE_EC test, and then export it so that it
can be called both here and in the EC backlight driver's probe routine,
but then I guess that would make video.ko depend on
nvidia-wmi-ec-backlight.ko, which seems wrong. It also seems wrong to
implement the WMI plumbing in the ACPI video driver, and export it so
that the EC backlight driver can use it, so I guess I can live with the
duplication of the relatively simple WMI stuff here, it would just be
nice to not have to define all of the API constants, structure, and GUID
twice.
> /* 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)
> @@ -518,6 +547,7 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
> static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
> {
> static DEFINE_MUTEX(init_mutex);
> + static bool nvidia_wmi_ec_present;
> static bool native_available;
> static bool init_done;
> static long video_caps;
> @@ -530,6 +560,7 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
> 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;
> }
> if (native)
> @@ -547,6 +578,10 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
> 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;
Should there also be a change to the EC backlight driver to call
acpi_video_get_backlight_type() and make sure we get
acpi_backlight_nvidia_wmi_ec? I don't see such a change in this patch
series; I could implement it (and test it) against your patch if there's
some reason you didn't do so with the current patchset.
> +
> /* On systems with ACPI video use either native or ACPI video. */
> if (video_caps & ACPI_VIDEO_BACKLIGHT) {
> /*
> diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
> index 0cff20265f97..807b989e3c77 100644
> --- a/drivers/gpu/drm/gma500/Kconfig
> +++ b/drivers/gpu/drm/gma500/Kconfig
> @@ -7,6 +7,8 @@ config DRM_GMA500
> select ACPI_VIDEO if ACPI
> select BACKLIGHT_CLASS_DEVICE if ACPI
> select INPUT if ACPI
> + select X86_PLATFORM_DEVICES if ACPI
> + select ACPI_WMI if ACPI
I'm not sure I understand why the Intel DRM drivers pick up the
additional platform/x86 and WMI dependencies here. ACPI_VIDEO already
depends on these, doesn't it? If Kconfig doesn't otherwise automatically
pull in an option's dependencies when selecting that option, then
shouldn't Nouveau's Kconfig get updated as well? It selects ACPI_VIDEO
in some configuration cases. (It looks like amdgpu doesn't currently
select ACPI_VIDEO, maybe because it doesn't depend on it the way the
Intel drivers do: there are several AMD+NVIDIA iGPU/dGPU designs out
there which use this backlight interface.)
> help
> Say yes for an experimental 2D KMS framebuffer driver for the
> Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 7ae3b7d67fcf..3efce05d7b57 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -23,6 +23,8 @@ config DRM_I915
> # but for select to work, need to select ACPI_VIDEO's dependencies, ick
> select BACKLIGHT_CLASS_DEVICE if ACPI
> select INPUT if ACPI
> + select X86_PLATFORM_DEVICES if ACPI
> + select ACPI_WMI if ACPI
> select ACPI_VIDEO if ACPI
> select ACPI_BUTTON if ACPI
> select SYNC_FILE
> diff --git a/include/acpi/video.h b/include/acpi/video.h
> index 0625806d3bbd..91578e77ac4e 100644
> --- a/include/acpi/video.h
> +++ b/include/acpi/video.h
> @@ -48,6 +48,7 @@ enum acpi_backlight_type {
> acpi_backlight_video,
> acpi_backlight_vendor,
> acpi_backlight_native,
> + acpi_backlight_nvidia_wmi_ec,
> };
>
> #if IS_ENABLED(CONFIG_ACPI_VIDEO)
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 16/29] ACPI: video: Add Nvidia WMI EC brightness control detection
2022-07-12 20:13 ` Daniel Dadap
@ 2022-07-15 11:59 ` Hans de Goede
2022-07-15 15:32 ` Daniel Dadap
2022-08-17 12:22 ` Hans de Goede
0 siblings, 2 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-15 11:59 UTC (permalink / raw)
To: Daniel Dadap, Ben Skeggs, Karol Herbst, Lyude, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Hi Daniel,
On 7/12/22 22:13, Daniel Dadap wrote:
> Thanks, Hans:
>
> On 7/12/22 14:38, Hans de Goede wrote:
>> On some new laptop designs a new Nvidia specific WMI interface is present
>> which gives info about panel brightness control and may allow controlling
>> the brightness through this interface when the embedded controller is used
>> for brightness control.
>>
>> When this WMI interface is present and indicates that the EC is used,
>> then this interface should be used for brightness control.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/acpi/Kconfig | 1 +
>> drivers/acpi/video_detect.c | 35 ++++++++++++++++++++++++++++++++++
>> drivers/gpu/drm/gma500/Kconfig | 2 ++
>> drivers/gpu/drm/i915/Kconfig | 2 ++
>> include/acpi/video.h | 1 +
>> 5 files changed, 41 insertions(+)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 1e34f846508f..c372385cfc3f 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -212,6 +212,7 @@ config ACPI_VIDEO
>> tristate "Video"
>> depends on X86 && BACKLIGHT_CLASS_DEVICE
>> depends on INPUT
>> + depends on ACPI_WMI
>> select THERMAL
>> help
>> This driver implements the ACPI Extensions For Display Adapters
>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>> index 8c2863403040..7b89dc9a04a2 100644
>> --- a/drivers/acpi/video_detect.c
>> +++ b/drivers/acpi/video_detect.c
>> @@ -75,6 +75,35 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv)
>> return AE_OK;
>> }
>> +#define WMI_BRIGHTNESS_METHOD_SOURCE 2
>> +#define WMI_BRIGHTNESS_MODE_GET 0
>> +#define WMI_BRIGHTNESS_SOURCE_EC 2
>> +
>> +struct wmi_brightness_args {
>> + u32 mode;
>> + u32 val;
>> + u32 ret;
>> + u32 ignored[3];
>> +};
>> +
>> +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("603E9613-EF25-4338-A3D0-C46177516DB7", 0,
>> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf);
>> + if (ACPI_FAILURE(status))
>> + return false;
>> +
>> + return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
>> +}
>> +
>
>
> The code duplication here with nvidia-wmi-ec-backlight.c is a little unfortunate. Can we move the constants, struct definition, and WMI GUID from that file to a header file that's used both by the EC backlight driver and the ACPI video driver?
Yes that is a good idea. I suggest using include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
to move the shared definitions there.
If you can submit 2 patches on top of this series:
1. Moving the definitions from drivers/platform/x86/nvidia-wmi-ec-backlight.c to
include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
2. Switching the code from this patch over to using the new nvidia-wmi-ec-backlight.h
Then for the next version I'll add patch 1. to the series and squash patch 2.
into this one.
> I was thinking it might be nice to add a wrapper around wmi_brightness_notify() in nvidia-wmi-ec-backlight.c that does this source == WMI_BRIGHTNESS_SOURCE_EC test, and then export it so that it can be called both here and in the EC backlight driver's probe routine, but then I guess that would make video.ko depend on nvidia-wmi-ec-backlight.ko, which seems wrong. It also seems wrong to implement the WMI plumbing in the ACPI video driver, and export it so that the EC backlight driver can use it, so I guess I can live with the duplication of the relatively simple WMI stuff here, it would just be nice to not have to define all of the API constants, structure, and GUID twice.
Agreed.
>
>
>> /* 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)
>> @@ -518,6 +547,7 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
>> static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>> {
>> static DEFINE_MUTEX(init_mutex);
>> + static bool nvidia_wmi_ec_present;
>> static bool native_available;
>> static bool init_done;
>> static long video_caps;
>> @@ -530,6 +560,7 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>> 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;
>> }
>> if (native)
>> @@ -547,6 +578,10 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>> 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;
>
>
> Should there also be a change to the EC backlight driver to call acpi_video_get_backlight_type() and make sure we get acpi_backlight_nvidia_wmi_ec? I don't see such a change in this patch series; I could implement it (and test it) against your patch if there's some reason you didn't do so with the current patchset.
I was thinking about this myself too and I decided it was not necessary since
acpi_video_get_backlight_type() will always return acpi_backlight_nvidia_wmi_ec.
But thinking more about this, that is not true, a user might try to force
using a different backlight firmware interface by e.g. adding:
acpi_backlight=video on the kernel commandline.
So yes a patch adding something like this:
if (acpi_video_get_backlight_type() != acpi_backlight_nvidia_wmi_ec)
return -ENODEV;
to the EC backlight driver would be very welcome.
>
>
>> +
>> /* On systems with ACPI video use either native or ACPI video. */
>> if (video_caps & ACPI_VIDEO_BACKLIGHT) {
>> /*
>> diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
>> index 0cff20265f97..807b989e3c77 100644
>> --- a/drivers/gpu/drm/gma500/Kconfig
>> +++ b/drivers/gpu/drm/gma500/Kconfig
>> @@ -7,6 +7,8 @@ config DRM_GMA500
>> select ACPI_VIDEO if ACPI
>> select BACKLIGHT_CLASS_DEVICE if ACPI
>> select INPUT if ACPI
>> + select X86_PLATFORM_DEVICES if ACPI
>> + select ACPI_WMI if ACPI
>
>
> I'm not sure I understand why the Intel DRM drivers pick up the additional platform/x86 and WMI dependencies here. ACPI_VIDEO already depends on these, doesn't it?
It does.
> If Kconfig doesn't otherwise automatically pull in an option's dependencies when selecting that option
Right that is the reason why this is done, for select the Kconfig block must also select all deps
> then shouldn't Nouveau's Kconfig get updated as well?
> It selects ACPI_VIDEO in some configuration cases.
nouveau's Kconfig block already selects ACPI_WMI:
config DRM_NOUVEAU
tristate "Nouveau (NVIDIA) cards"
...
select X86_PLATFORM_DEVICES if ACPI && X86
select ACPI_WMI if ACPI && X86
...
select ACPI_VIDEO if ACPI && X86
That is why this patch does not add this.
> (It looks like amdgpu doesn't currently select ACPI_VIDEO, maybe because it doesn't depend on it the way the Intel drivers do: there are several AMD+NVIDIA iGPU/dGPU designs out there which use this backlight interface.)
Correct, but with this series amdgpu/radeon also start using ACPI_VIDEO
functions so these patches:
https://patchwork.freedesktop.org/patch/493650/
https://patchwork.freedesktop.org/patch/493653/
Add the necessary selects and I cheated a bit and also made
them select ACPI_WMI already even though that is only
necessary after this patch (which comes later in the series).
I hope this answers al your questions...
Regards,
Hans
>
>
>> help
>> Say yes for an experimental 2D KMS framebuffer driver for the
>> Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and
>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> index 7ae3b7d67fcf..3efce05d7b57 100644
>> --- a/drivers/gpu/drm/i915/Kconfig
>> +++ b/drivers/gpu/drm/i915/Kconfig
>> @@ -23,6 +23,8 @@ config DRM_I915
>> # but for select to work, need to select ACPI_VIDEO's dependencies, ick
>> select BACKLIGHT_CLASS_DEVICE if ACPI
>> select INPUT if ACPI
>> + select X86_PLATFORM_DEVICES if ACPI
>> + select ACPI_WMI if ACPI
>> select ACPI_VIDEO if ACPI
>> select ACPI_BUTTON if ACPI
>> select SYNC_FILE
>> diff --git a/include/acpi/video.h b/include/acpi/video.h
>> index 0625806d3bbd..91578e77ac4e 100644
>> --- a/include/acpi/video.h
>> +++ b/include/acpi/video.h
>> @@ -48,6 +48,7 @@ enum acpi_backlight_type {
>> acpi_backlight_video,
>> acpi_backlight_vendor,
>> acpi_backlight_native,
>> + acpi_backlight_nvidia_wmi_ec,
>> };
>> #if IS_ENABLED(CONFIG_ACPI_VIDEO)
>
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 16/29] ACPI: video: Add Nvidia WMI EC brightness control detection
2022-07-15 11:59 ` Hans de Goede
@ 2022-07-15 15:32 ` Daniel Dadap
2022-07-15 16:04 ` Hans de Goede
2022-08-17 12:22 ` Hans de Goede
1 sibling, 1 reply; 58+ messages in thread
From: Daniel Dadap @ 2022-07-15 15:32 UTC (permalink / raw)
To: Hans de Goede
Cc: Ben Skeggs, Karol Herbst, Lyude, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko, nouveau, Daniel Vetter,
David Airlie, intel-gfx, dri-devel, amd-gfx, Len Brown,
linux-acpi, platform-driver-x86
> On Jul 15, 2022, at 06:59, Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi Daniel,
>
>> On 7/12/22 22:13, Daniel Dadap wrote:
>> Thanks, Hans:
>>
>>> On 7/12/22 14:38, Hans de Goede wrote:
>>> On some new laptop designs a new Nvidia specific WMI interface is present
>>> which gives info about panel brightness control and may allow controlling
>>> the brightness through this interface when the embedded controller is used
>>> for brightness control.
>>>
>>> When this WMI interface is present and indicates that the EC is used,
>>> then this interface should be used for brightness control.
>>>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> ---
>>> drivers/acpi/Kconfig | 1 +
>>> drivers/acpi/video_detect.c | 35 ++++++++++++++++++++++++++++++++++
>>> drivers/gpu/drm/gma500/Kconfig | 2 ++
>>> drivers/gpu/drm/i915/Kconfig | 2 ++
>>> include/acpi/video.h | 1 +
>>> 5 files changed, 41 insertions(+)
>>>
>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>> index 1e34f846508f..c372385cfc3f 100644
>>> --- a/drivers/acpi/Kconfig
>>> +++ b/drivers/acpi/Kconfig
>>> @@ -212,6 +212,7 @@ config ACPI_VIDEO
>>> tristate "Video"
>>> depends on X86 && BACKLIGHT_CLASS_DEVICE
>>> depends on INPUT
>>> + depends on ACPI_WMI
>>> select THERMAL
>>> help
>>> This driver implements the ACPI Extensions For Display Adapters
>>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>>> index 8c2863403040..7b89dc9a04a2 100644
>>> --- a/drivers/acpi/video_detect.c
>>> +++ b/drivers/acpi/video_detect.c
>>> @@ -75,6 +75,35 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv)
>>> return AE_OK;
>>> }
>>> +#define WMI_BRIGHTNESS_METHOD_SOURCE 2
>>> +#define WMI_BRIGHTNESS_MODE_GET 0
>>> +#define WMI_BRIGHTNESS_SOURCE_EC 2
>>> +
>>> +struct wmi_brightness_args {
>>> + u32 mode;
>>> + u32 val;
>>> + u32 ret;
>>> + u32 ignored[3];
>>> +};
>>> +
>>> +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("603E9613-EF25-4338-A3D0-C46177516DB7", 0,
>>> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf);
>>> + if (ACPI_FAILURE(status))
>>> + return false;
>>> +
>>> + return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
>>> +}
>>> +
>>
>>
>> The code duplication here with nvidia-wmi-ec-backlight.c is a little unfortunate. Can we move the constants, struct definition, and WMI GUID from that file to a header file that's used both by the EC backlight driver and the ACPI video driver?
>
> Yes that is a good idea. I suggest using include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
> to move the shared definitions there.
>
> If you can submit 2 patches on top of this series:
>
> 1. Moving the definitions from drivers/platform/x86/nvidia-wmi-ec-backlight.c to
> include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
>
> 2. Switching the code from this patch over to using the new nvidia-wmi-ec-backlight.h
>
> Then for the next version I'll add patch 1. to the series and squash patch 2.
> into this one.
>
>> I was thinking it might be nice to add a wrapper around wmi_brightness_notify() in nvidia-wmi-ec-backlight.c that does this source == WMI_BRIGHTNESS_SOURCE_EC test, and then export it so that it can be called both here and in the EC backlight driver's probe routine, but then I guess that would make video.ko depend on nvidia-wmi-ec-backlight.ko, which seems wrong. It also seems wrong to implement the WMI plumbing in the ACPI video driver, and export it so that the EC backlight driver can use it, so I guess I can live with the duplication of the relatively simple WMI stuff here, it would just be nice to not have to define all of the API constants, structure, and GUID twice.
>
> Agreed.
>
>>
>>
>>> /* 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)
>>> @@ -518,6 +547,7 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
>>> static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>> {
>>> static DEFINE_MUTEX(init_mutex);
>>> + static bool nvidia_wmi_ec_present;
>>> static bool native_available;
>>> static bool init_done;
>>> static long video_caps;
>>> @@ -530,6 +560,7 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>> 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;
>>> }
>>> if (native)
>>> @@ -547,6 +578,10 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>> 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;
>>
>>
>> Should there also be a change to the EC backlight driver to call acpi_video_get_backlight_type() and make sure we get acpi_backlight_nvidia_wmi_ec? I don't see such a change in this patch series; I could implement it (and test it) against your patch if there's some reason you didn't do so with the current patchset.
>
> I was thinking about this myself too and I decided it was not necessary since
> acpi_video_get_backlight_type() will always return acpi_backlight_nvidia_wmi_ec.
>
> But thinking more about this, that is not true, a user might try to force
> using a different backlight firmware interface by e.g. adding:
> acpi_backlight=video on the kernel commandline.
>
> So yes a patch adding something like this:
>
> if (acpi_video_get_backlight_type() != acpi_backlight_nvidia_wmi_ec)
> return -ENODEV;
>
> to the EC backlight driver would be very welcome.
>
>>
>>
>>> +
>>> /* On systems with ACPI video use either native or ACPI video. */
>>> if (video_caps & ACPI_VIDEO_BACKLIGHT) {
>>> /*
>>> diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
>>> index 0cff20265f97..807b989e3c77 100644
>>> --- a/drivers/gpu/drm/gma500/Kconfig
>>> +++ b/drivers/gpu/drm/gma500/Kconfig
>>> @@ -7,6 +7,8 @@ config DRM_GMA500
>>> select ACPI_VIDEO if ACPI
>>> select BACKLIGHT_CLASS_DEVICE if ACPI
>>> select INPUT if ACPI
>>> + select X86_PLATFORM_DEVICES if ACPI
>>> + select ACPI_WMI if ACPI
>>
>>
>> I'm not sure I understand why the Intel DRM drivers pick up the additional platform/x86 and WMI dependencies here. ACPI_VIDEO already depends on these, doesn't it?
>
> It does.
>
>> If Kconfig doesn't otherwise automatically pull in an option's dependencies when selecting that option
>
> Right that is the reason why this is done, for select the Kconfig block must also select all deps
>
>> then shouldn't Nouveau's Kconfig get updated as well?
>> It selects ACPI_VIDEO in some configuration cases.
>
> nouveau's Kconfig block already selects ACPI_WMI:
>
> config DRM_NOUVEAU
> tristate "Nouveau (NVIDIA) cards"
> ...
> select X86_PLATFORM_DEVICES if ACPI && X86
> select ACPI_WMI if ACPI && X86
> ...
> select ACPI_VIDEO if ACPI && X86
>
> That is why this patch does not add this.
>
>> (It looks like amdgpu doesn't currently select ACPI_VIDEO, maybe because it doesn't depend on it the way the Intel drivers do: there are several AMD+NVIDIA iGPU/dGPU designs out there which use this backlight interface.)
>
> Correct, but with this series amdgpu/radeon also start using ACPI_VIDEO
> functions so these patches:
>
> https://patchwork.freedesktop.org/patch/493650/
> https://patchwork.freedesktop.org/patch/493653/
>
> Add the necessary selects and I cheated a bit and also made
> them select ACPI_WMI already even though that is only
> necessary after this patch (which comes later in the series).
>
> I hope this answers al your questions...
>
Yes, thank you. I don’t have to work with Kconfig much, but that reasoning lined up with my best guess. Sorry for not looking at the other patches in the series, or at Nouveau’s Kconfig more closely.
I will work on and test the three patches we discussed above. Would you prefer if I sent them and set In-reply-to a message in this thread, or as a separate message with no In-reply-to?
> Regards,
>
> Hans
>
>
>
>>
>>
>>> help
>>> Say yes for an experimental 2D KMS framebuffer driver for the
>>> Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and
>>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>>> index 7ae3b7d67fcf..3efce05d7b57 100644
>>> --- a/drivers/gpu/drm/i915/Kconfig
>>> +++ b/drivers/gpu/drm/i915/Kconfig
>>> @@ -23,6 +23,8 @@ config DRM_I915
>>> # but for select to work, need to select ACPI_VIDEO's dependencies, ick
>>> select BACKLIGHT_CLASS_DEVICE if ACPI
>>> select INPUT if ACPI
>>> + select X86_PLATFORM_DEVICES if ACPI
>>> + select ACPI_WMI if ACPI
>>> select ACPI_VIDEO if ACPI
>>> select ACPI_BUTTON if ACPI
>>> select SYNC_FILE
>>> diff --git a/include/acpi/video.h b/include/acpi/video.h
>>> index 0625806d3bbd..91578e77ac4e 100644
>>> --- a/include/acpi/video.h
>>> +++ b/include/acpi/video.h
>>> @@ -48,6 +48,7 @@ enum acpi_backlight_type {
>>> acpi_backlight_video,
>>> acpi_backlight_vendor,
>>> acpi_backlight_native,
>>> + acpi_backlight_nvidia_wmi_ec,
>>> };
>>> #if IS_ENABLED(CONFIG_ACPI_VIDEO)
>>
>
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 16/29] ACPI: video: Add Nvidia WMI EC brightness control detection
2022-07-15 15:32 ` Daniel Dadap
@ 2022-07-15 16:04 ` Hans de Goede
0 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-15 16:04 UTC (permalink / raw)
To: Daniel Dadap
Cc: Ben Skeggs, Karol Herbst, Lyude, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko, nouveau, Daniel Vetter,
David Airlie, intel-gfx, dri-devel, amd-gfx, Len Brown,
linux-acpi, platform-driver-x86
Hi,
On 7/15/22 17:32, Daniel Dadap wrote:
>
>
>> On Jul 15, 2022, at 06:59, Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi Daniel,
>>
>>> On 7/12/22 22:13, Daniel Dadap wrote:
>>> Thanks, Hans:
>>>
>>>> On 7/12/22 14:38, Hans de Goede wrote:
>>>> On some new laptop designs a new Nvidia specific WMI interface is present
>>>> which gives info about panel brightness control and may allow controlling
>>>> the brightness through this interface when the embedded controller is used
>>>> for brightness control.
>>>>
>>>> When this WMI interface is present and indicates that the EC is used,
>>>> then this interface should be used for brightness control.
>>>>
>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>> ---
>>>> drivers/acpi/Kconfig | 1 +
>>>> drivers/acpi/video_detect.c | 35 ++++++++++++++++++++++++++++++++++
>>>> drivers/gpu/drm/gma500/Kconfig | 2 ++
>>>> drivers/gpu/drm/i915/Kconfig | 2 ++
>>>> include/acpi/video.h | 1 +
>>>> 5 files changed, 41 insertions(+)
>>>>
>>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>>> index 1e34f846508f..c372385cfc3f 100644
>>>> --- a/drivers/acpi/Kconfig
>>>> +++ b/drivers/acpi/Kconfig
>>>> @@ -212,6 +212,7 @@ config ACPI_VIDEO
>>>> tristate "Video"
>>>> depends on X86 && BACKLIGHT_CLASS_DEVICE
>>>> depends on INPUT
>>>> + depends on ACPI_WMI
>>>> select THERMAL
>>>> help
>>>> This driver implements the ACPI Extensions For Display Adapters
>>>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>>>> index 8c2863403040..7b89dc9a04a2 100644
>>>> --- a/drivers/acpi/video_detect.c
>>>> +++ b/drivers/acpi/video_detect.c
>>>> @@ -75,6 +75,35 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv)
>>>> return AE_OK;
>>>> }
>>>> +#define WMI_BRIGHTNESS_METHOD_SOURCE 2
>>>> +#define WMI_BRIGHTNESS_MODE_GET 0
>>>> +#define WMI_BRIGHTNESS_SOURCE_EC 2
>>>> +
>>>> +struct wmi_brightness_args {
>>>> + u32 mode;
>>>> + u32 val;
>>>> + u32 ret;
>>>> + u32 ignored[3];
>>>> +};
>>>> +
>>>> +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("603E9613-EF25-4338-A3D0-C46177516DB7", 0,
>>>> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf);
>>>> + if (ACPI_FAILURE(status))
>>>> + return false;
>>>> +
>>>> + return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
>>>> +}
>>>> +
>>>
>>>
>>> The code duplication here with nvidia-wmi-ec-backlight.c is a little unfortunate. Can we move the constants, struct definition, and WMI GUID from that file to a header file that's used both by the EC backlight driver and the ACPI video driver?
>>
>> Yes that is a good idea. I suggest using include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
>> to move the shared definitions there.
>>
>> If you can submit 2 patches on top of this series:
>>
>> 1. Moving the definitions from drivers/platform/x86/nvidia-wmi-ec-backlight.c to
>> include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
>>
>> 2. Switching the code from this patch over to using the new nvidia-wmi-ec-backlight.h
>>
>> Then for the next version I'll add patch 1. to the series and squash patch 2.
>> into this one.
>>
>>> I was thinking it might be nice to add a wrapper around wmi_brightness_notify() in nvidia-wmi-ec-backlight.c that does this source == WMI_BRIGHTNESS_SOURCE_EC test, and then export it so that it can be called both here and in the EC backlight driver's probe routine, but then I guess that would make video.ko depend on nvidia-wmi-ec-backlight.ko, which seems wrong. It also seems wrong to implement the WMI plumbing in the ACPI video driver, and export it so that the EC backlight driver can use it, so I guess I can live with the duplication of the relatively simple WMI stuff here, it would just be nice to not have to define all of the API constants, structure, and GUID twice.
>>
>> Agreed.
>>
>>>
>>>
>>>> /* 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)
>>>> @@ -518,6 +547,7 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
>>>> static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>>> {
>>>> static DEFINE_MUTEX(init_mutex);
>>>> + static bool nvidia_wmi_ec_present;
>>>> static bool native_available;
>>>> static bool init_done;
>>>> static long video_caps;
>>>> @@ -530,6 +560,7 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>>> 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;
>>>> }
>>>> if (native)
>>>> @@ -547,6 +578,10 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>>> 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;
>>>
>>>
>>> Should there also be a change to the EC backlight driver to call acpi_video_get_backlight_type() and make sure we get acpi_backlight_nvidia_wmi_ec? I don't see such a change in this patch series; I could implement it (and test it) against your patch if there's some reason you didn't do so with the current patchset.
>>
>> I was thinking about this myself too and I decided it was not necessary since
>> acpi_video_get_backlight_type() will always return acpi_backlight_nvidia_wmi_ec.
>>
>> But thinking more about this, that is not true, a user might try to force
>> using a different backlight firmware interface by e.g. adding:
>> acpi_backlight=video on the kernel commandline.
>>
>> So yes a patch adding something like this:
>>
>> if (acpi_video_get_backlight_type() != acpi_backlight_nvidia_wmi_ec)
>> return -ENODEV;
>>
>> to the EC backlight driver would be very welcome.
>>
>>>
>>>
>>>> +
>>>> /* On systems with ACPI video use either native or ACPI video. */
>>>> if (video_caps & ACPI_VIDEO_BACKLIGHT) {
>>>> /*
>>>> diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
>>>> index 0cff20265f97..807b989e3c77 100644
>>>> --- a/drivers/gpu/drm/gma500/Kconfig
>>>> +++ b/drivers/gpu/drm/gma500/Kconfig
>>>> @@ -7,6 +7,8 @@ config DRM_GMA500
>>>> select ACPI_VIDEO if ACPI
>>>> select BACKLIGHT_CLASS_DEVICE if ACPI
>>>> select INPUT if ACPI
>>>> + select X86_PLATFORM_DEVICES if ACPI
>>>> + select ACPI_WMI if ACPI
>>>
>>>
>>> I'm not sure I understand why the Intel DRM drivers pick up the additional platform/x86 and WMI dependencies here. ACPI_VIDEO already depends on these, doesn't it?
>>
>> It does.
>>
>>> If Kconfig doesn't otherwise automatically pull in an option's dependencies when selecting that option
>>
>> Right that is the reason why this is done, for select the Kconfig block must also select all deps
>>
>>> then shouldn't Nouveau's Kconfig get updated as well?
>>> It selects ACPI_VIDEO in some configuration cases.
>>
>> nouveau's Kconfig block already selects ACPI_WMI:
>>
>> config DRM_NOUVEAU
>> tristate "Nouveau (NVIDIA) cards"
>> ...
>> select X86_PLATFORM_DEVICES if ACPI && X86
>> select ACPI_WMI if ACPI && X86
>> ...
>> select ACPI_VIDEO if ACPI && X86
>>
>> That is why this patch does not add this.
>>
>>> (It looks like amdgpu doesn't currently select ACPI_VIDEO, maybe because it doesn't depend on it the way the Intel drivers do: there are several AMD+NVIDIA iGPU/dGPU designs out there which use this backlight interface.)
>>
>> Correct, but with this series amdgpu/radeon also start using ACPI_VIDEO
>> functions so these patches:
>>
>> https://patchwork.freedesktop.org/patch/493650/
>> https://patchwork.freedesktop.org/patch/493653/
>>
>> Add the necessary selects and I cheated a bit and also made
>> them select ACPI_WMI already even though that is only
>> necessary after this patch (which comes later in the series).
>>
>> I hope this answers al your questions...
>>
>
> Yes, thank you. I don’t have to work with Kconfig much, but that reasoning lined up with my best guess. Sorry for not looking at the other patches in the series, or at Nouveau’s Kconfig more closely.
>
> I will work on and test the three patches we discussed above. Would you prefer if I sent them and set In-reply-to a message in this thread, or as a separate message with no In-reply-to?
I have no real preference. Whatever is easiest for you.
Regards,
Hans
>>>> help
>>>> Say yes for an experimental 2D KMS framebuffer driver for the
>>>> Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and
>>>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>>>> index 7ae3b7d67fcf..3efce05d7b57 100644
>>>> --- a/drivers/gpu/drm/i915/Kconfig
>>>> +++ b/drivers/gpu/drm/i915/Kconfig
>>>> @@ -23,6 +23,8 @@ config DRM_I915
>>>> # but for select to work, need to select ACPI_VIDEO's dependencies, ick
>>>> select BACKLIGHT_CLASS_DEVICE if ACPI
>>>> select INPUT if ACPI
>>>> + select X86_PLATFORM_DEVICES if ACPI
>>>> + select ACPI_WMI if ACPI
>>>> select ACPI_VIDEO if ACPI
>>>> select ACPI_BUTTON if ACPI
>>>> select SYNC_FILE
>>>> diff --git a/include/acpi/video.h b/include/acpi/video.h
>>>> index 0625806d3bbd..91578e77ac4e 100644
>>>> --- a/include/acpi/video.h
>>>> +++ b/include/acpi/video.h
>>>> @@ -48,6 +48,7 @@ enum acpi_backlight_type {
>>>> acpi_backlight_video,
>>>> acpi_backlight_vendor,
>>>> acpi_backlight_native,
>>>> + acpi_backlight_nvidia_wmi_ec,
>>>> };
>>>> #if IS_ENABLED(CONFIG_ACPI_VIDEO)
>>>
>>
^ permalink raw reply [flat|nested] 58+ messages in thread
* Re: [PATCH v2 16/29] ACPI: video: Add Nvidia WMI EC brightness control detection
2022-07-15 11:59 ` Hans de Goede
2022-07-15 15:32 ` Daniel Dadap
@ 2022-08-17 12:22 ` Hans de Goede
2022-08-17 16:57 ` Daniel Dadap
1 sibling, 1 reply; 58+ messages in thread
From: Hans de Goede @ 2022-08-17 12:22 UTC (permalink / raw)
To: Daniel Dadap, Ben Skeggs, Karol Herbst, Lyude, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Hi Daniel,
On 7/15/22 13:59, Hans de Goede wrote:
> Hi Daniel,
>
> On 7/12/22 22:13, Daniel Dadap wrote:
>> Thanks, Hans:
>>
>> On 7/12/22 14:38, Hans de Goede wrote:
>>> On some new laptop designs a new Nvidia specific WMI interface is present
>>> which gives info about panel brightness control and may allow controlling
>>> the brightness through this interface when the embedded controller is used
>>> for brightness control.
>>>
>>> When this WMI interface is present and indicates that the EC is used,
>>> then this interface should be used for brightness control.
>>>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>> ---
>>> drivers/acpi/Kconfig | 1 +
>>> drivers/acpi/video_detect.c | 35 ++++++++++++++++++++++++++++++++++
>>> drivers/gpu/drm/gma500/Kconfig | 2 ++
>>> drivers/gpu/drm/i915/Kconfig | 2 ++
>>> include/acpi/video.h | 1 +
>>> 5 files changed, 41 insertions(+)
>>>
>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>> index 1e34f846508f..c372385cfc3f 100644
>>> --- a/drivers/acpi/Kconfig
>>> +++ b/drivers/acpi/Kconfig
>>> @@ -212,6 +212,7 @@ config ACPI_VIDEO
>>> tristate "Video"
>>> depends on X86 && BACKLIGHT_CLASS_DEVICE
>>> depends on INPUT
>>> + depends on ACPI_WMI
>>> select THERMAL
>>> help
>>> This driver implements the ACPI Extensions For Display Adapters
>>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>>> index 8c2863403040..7b89dc9a04a2 100644
>>> --- a/drivers/acpi/video_detect.c
>>> +++ b/drivers/acpi/video_detect.c
>>> @@ -75,6 +75,35 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv)
>>> return AE_OK;
>>> }
>>> +#define WMI_BRIGHTNESS_METHOD_SOURCE 2
>>> +#define WMI_BRIGHTNESS_MODE_GET 0
>>> +#define WMI_BRIGHTNESS_SOURCE_EC 2
>>> +
>>> +struct wmi_brightness_args {
>>> + u32 mode;
>>> + u32 val;
>>> + u32 ret;
>>> + u32 ignored[3];
>>> +};
>>> +
>>> +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("603E9613-EF25-4338-A3D0-C46177516DB7", 0,
>>> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf);
>>> + if (ACPI_FAILURE(status))
>>> + return false;
>>> +
>>> + return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
>>> +}
>>> +
>>
>>
>> The code duplication here with nvidia-wmi-ec-backlight.c is a little unfortunate. Can we move the constants, struct definition, and WMI GUID from that file to a header file that's used both by the EC backlight driver and the ACPI video driver?
>
> Yes that is a good idea. I suggest using include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
> to move the shared definitions there.
>
> If you can submit 2 patches on top of this series:
>
> 1. Moving the definitions from drivers/platform/x86/nvidia-wmi-ec-backlight.c to
> include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
>
> 2. Switching the code from this patch over to using the new nvidia-wmi-ec-backlight.h
>
> Then for the next version I'll add patch 1. to the series and squash patch 2.
> into this one.
Note: I'm preparing a v3 of the series and I've made these changes myself now.
>> I was thinking it might be nice to add a wrapper around wmi_brightness_notify() in nvidia-wmi-ec-backlight.c that does this source == WMI_BRIGHTNESS_SOURCE_EC test, and then export it so that it can be called both here and in the EC backlight driver's probe routine, but then I guess that would make video.ko depend on nvidia-wmi-ec-backlight.ko, which seems wrong. It also seems wrong to implement the WMI plumbing in the ACPI video driver, and export it so that the EC backlight driver can use it, so I guess I can live with the duplication of the relatively simple WMI stuff here, it would just be nice to not have to define all of the API constants, structure, and GUID twice.
>
> Agreed.
>
>>
>>
>>> /* 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)
>>> @@ -518,6 +547,7 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
>>> static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>> {
>>> static DEFINE_MUTEX(init_mutex);
>>> + static bool nvidia_wmi_ec_present;
>>> static bool native_available;
>>> static bool init_done;
>>> static long video_caps;
>>> @@ -530,6 +560,7 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>> 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;
>>> }
>>> if (native)
>>> @@ -547,6 +578,10 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>> 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;
>>
>>
>> Should there also be a change to the EC backlight driver to call acpi_video_get_backlight_type() and make sure we get acpi_backlight_nvidia_wmi_ec? I don't see such a change in this patch series; I could implement it (and test it) against your patch if there's some reason you didn't do so with the current patchset.
>
> I was thinking about this myself too and I decided it was not necessary since
> acpi_video_get_backlight_type() will always return acpi_backlight_nvidia_wmi_ec.
>
> But thinking more about this, that is not true, a user might try to force
> using a different backlight firmware interface by e.g. adding:
> acpi_backlight=video on the kernel commandline.
>
> So yes a patch adding something like this:
>
> if (acpi_video_get_backlight_type() != acpi_backlight_nvidia_wmi_ec)
> return -ENODEV;
>
> to the EC backlight driver would be very welcome.
I will also add a patch for this to v3 of the series myself.
Regards,
Hans
>
>>
>>
>>> +
>>> /* On systems with ACPI video use either native or ACPI video. */
>>> if (video_caps & ACPI_VIDEO_BACKLIGHT) {
>>> /*
>>> diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
>>> index 0cff20265f97..807b989e3c77 100644
>>> --- a/drivers/gpu/drm/gma500/Kconfig
>>> +++ b/drivers/gpu/drm/gma500/Kconfig
>>> @@ -7,6 +7,8 @@ config DRM_GMA500
>>> select ACPI_VIDEO if ACPI
>>> select BACKLIGHT_CLASS_DEVICE if ACPI
>>> select INPUT if ACPI
>>> + select X86_PLATFORM_DEVICES if ACPI
>>> + select ACPI_WMI if ACPI
>>
>>
>> I'm not sure I understand why the Intel DRM drivers pick up the additional platform/x86 and WMI dependencies here. ACPI_VIDEO already depends on these, doesn't it?
>
> It does.
>
>> If Kconfig doesn't otherwise automatically pull in an option's dependencies when selecting that option
>
> Right that is the reason why this is done, for select the Kconfig block must also select all deps
>
>> then shouldn't Nouveau's Kconfig get updated as well?
>> It selects ACPI_VIDEO in some configuration cases.
>
> nouveau's Kconfig block already selects ACPI_WMI:
>
> config DRM_NOUVEAU
> tristate "Nouveau (NVIDIA) cards"
> ...
> select X86_PLATFORM_DEVICES if ACPI && X86
> select ACPI_WMI if ACPI && X86
> ...
> select ACPI_VIDEO if ACPI && X86
>
> That is why this patch does not add this.
>
>> (It looks like amdgpu doesn't currently select ACPI_VIDEO, maybe because it doesn't depend on it the way the Intel drivers do: there are several AMD+NVIDIA iGPU/dGPU designs out there which use this backlight interface.)
>
> Correct, but with this series amdgpu/radeon also start using ACPI_VIDEO
> functions so these patches:
>
> https://patchwork.freedesktop.org/patch/493650/
> https://patchwork.freedesktop.org/patch/493653/
>
> Add the necessary selects and I cheated a bit and also made
> them select ACPI_WMI already even though that is only
> necessary after this patch (which comes later in the series).
>
> I hope this answers al your questions...
>
> Regards,
>
> Hans
>
>
>
>>
>>
>>> help
>>> Say yes for an experimental 2D KMS framebuffer driver for the
>>> Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and
>>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>>> index 7ae3b7d67fcf..3efce05d7b57 100644
>>> --- a/drivers/gpu/drm/i915/Kconfig
>>> +++ b/drivers/gpu/drm/i915/Kconfig
>>> @@ -23,6 +23,8 @@ config DRM_I915
>>> # but for select to work, need to select ACPI_VIDEO's dependencies, ick
>>> select BACKLIGHT_CLASS_DEVICE if ACPI
>>> select INPUT if ACPI
>>> + select X86_PLATFORM_DEVICES if ACPI
>>> + select ACPI_WMI if ACPI
>>> select ACPI_VIDEO if ACPI
>>> select ACPI_BUTTON if ACPI
>>> select SYNC_FILE
>>> diff --git a/include/acpi/video.h b/include/acpi/video.h
>>> index 0625806d3bbd..91578e77ac4e 100644
>>> --- a/include/acpi/video.h
>>> +++ b/include/acpi/video.h
>>> @@ -48,6 +48,7 @@ enum acpi_backlight_type {
>>> acpi_backlight_video,
>>> acpi_backlight_vendor,
>>> acpi_backlight_native,
>>> + acpi_backlight_nvidia_wmi_ec,
>>> };
>>> #if IS_ENABLED(CONFIG_ACPI_VIDEO)
>>
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 16/29] ACPI: video: Add Nvidia WMI EC brightness control detection
2022-08-17 12:22 ` Hans de Goede
@ 2022-08-17 16:57 ` Daniel Dadap
0 siblings, 0 replies; 58+ messages in thread
From: Daniel Dadap @ 2022-08-17 16:57 UTC (permalink / raw)
To: Hans de Goede, Ben Skeggs, Karol Herbst, Lyude,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher,
Christian König, Xinhui, Rafael J . Wysocki,
Mika Westerberg, Lukas Wunner, Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
On 8/17/22 7:22 AM, Hans de Goede wrote:
> Hi Daniel,
>
> On 7/15/22 13:59, Hans de Goede wrote:
>> Hi Daniel,
>>
>> On 7/12/22 22:13, Daniel Dadap wrote:
>>> Thanks, Hans:
>>>
>>> On 7/12/22 14:38, Hans de Goede wrote:
>>>> On some new laptop designs a new Nvidia specific WMI interface is present
>>>> which gives info about panel brightness control and may allow controlling
>>>> the brightness through this interface when the embedded controller is used
>>>> for brightness control.
>>>>
>>>> When this WMI interface is present and indicates that the EC is used,
>>>> then this interface should be used for brightness control.
>>>>
>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>> ---
>>>> drivers/acpi/Kconfig | 1 +
>>>> drivers/acpi/video_detect.c | 35 ++++++++++++++++++++++++++++++++++
>>>> drivers/gpu/drm/gma500/Kconfig | 2 ++
>>>> drivers/gpu/drm/i915/Kconfig | 2 ++
>>>> include/acpi/video.h | 1 +
>>>> 5 files changed, 41 insertions(+)
>>>>
>>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>>> index 1e34f846508f..c372385cfc3f 100644
>>>> --- a/drivers/acpi/Kconfig
>>>> +++ b/drivers/acpi/Kconfig
>>>> @@ -212,6 +212,7 @@ config ACPI_VIDEO
>>>> tristate "Video"
>>>> depends on X86 && BACKLIGHT_CLASS_DEVICE
>>>> depends on INPUT
>>>> + depends on ACPI_WMI
>>>> select THERMAL
>>>> help
>>>> This driver implements the ACPI Extensions For Display Adapters
>>>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>>>> index 8c2863403040..7b89dc9a04a2 100644
>>>> --- a/drivers/acpi/video_detect.c
>>>> +++ b/drivers/acpi/video_detect.c
>>>> @@ -75,6 +75,35 @@ find_video(acpi_handle handle, u32 lvl, void *context, void **rv)
>>>> return AE_OK;
>>>> }
>>>> +#define WMI_BRIGHTNESS_METHOD_SOURCE 2
>>>> +#define WMI_BRIGHTNESS_MODE_GET 0
>>>> +#define WMI_BRIGHTNESS_SOURCE_EC 2
>>>> +
>>>> +struct wmi_brightness_args {
>>>> + u32 mode;
>>>> + u32 val;
>>>> + u32 ret;
>>>> + u32 ignored[3];
>>>> +};
>>>> +
>>>> +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("603E9613-EF25-4338-A3D0-C46177516DB7", 0,
>>>> + WMI_BRIGHTNESS_METHOD_SOURCE, &buf, &buf);
>>>> + if (ACPI_FAILURE(status))
>>>> + return false;
>>>> +
>>>> + return args.ret == WMI_BRIGHTNESS_SOURCE_EC;
>>>> +}
>>>> +
>>>
>>> The code duplication here with nvidia-wmi-ec-backlight.c is a little unfortunate. Can we move the constants, struct definition, and WMI GUID from that file to a header file that's used both by the EC backlight driver and the ACPI video driver?
>> Yes that is a good idea. I suggest using include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
>> to move the shared definitions there.
>>
>> If you can submit 2 patches on top of this series:
>>
>> 1. Moving the definitions from drivers/platform/x86/nvidia-wmi-ec-backlight.c to
>> include/linux/platform_data/x86/nvidia-wmi-ec-backlight.h
>>
>> 2. Switching the code from this patch over to using the new nvidia-wmi-ec-backlight.h
>>
>> Then for the next version I'll add patch 1. to the series and squash patch 2.
>> into this one.
> Note: I'm preparing a v3 of the series and I've made these changes myself now.
Okay, thanks. Sorry, I had started on this but then got distracted by
other work.
>>> I was thinking it might be nice to add a wrapper around wmi_brightness_notify() in nvidia-wmi-ec-backlight.c that does this source == WMI_BRIGHTNESS_SOURCE_EC test, and then export it so that it can be called both here and in the EC backlight driver's probe routine, but then I guess that would make video.ko depend on nvidia-wmi-ec-backlight.ko, which seems wrong. It also seems wrong to implement the WMI plumbing in the ACPI video driver, and export it so that the EC backlight driver can use it, so I guess I can live with the duplication of the relatively simple WMI stuff here, it would just be nice to not have to define all of the API constants, structure, and GUID twice.
>> Agreed.
>>
>>>
>>>> /* 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)
>>>> @@ -518,6 +547,7 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
>>>> static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>>> {
>>>> static DEFINE_MUTEX(init_mutex);
>>>> + static bool nvidia_wmi_ec_present;
>>>> static bool native_available;
>>>> static bool init_done;
>>>> static long video_caps;
>>>> @@ -530,6 +560,7 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>>> 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;
>>>> }
>>>> if (native)
>>>> @@ -547,6 +578,10 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
>>>> 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;
>>>
>>> Should there also be a change to the EC backlight driver to call acpi_video_get_backlight_type() and make sure we get acpi_backlight_nvidia_wmi_ec? I don't see such a change in this patch series; I could implement it (and test it) against your patch if there's some reason you didn't do so with the current patchset.
>> I was thinking about this myself too and I decided it was not necessary since
>> acpi_video_get_backlight_type() will always return acpi_backlight_nvidia_wmi_ec.
>>
>> But thinking more about this, that is not true, a user might try to force
>> using a different backlight firmware interface by e.g. adding:
>> acpi_backlight=video on the kernel commandline.
>>
>> So yes a patch adding something like this:
>>
>> if (acpi_video_get_backlight_type() != acpi_backlight_nvidia_wmi_ec)
>> return -ENODEV;
>>
>> to the EC backlight driver would be very welcome.
> I will also add a patch for this to v3 of the series myself.
Thanks. I have already done testing against v2; I will retest when you
send out v3. As we discussed in another thread, the NVIDIA proprietary
driver does need some minor changes for backlight control to work after
these changes - I am tracking this work internally, and plan to get the
required changes added to the NVIDIA proprietary driver once your
changes have made it to the relevant subsystem tree(s), with the hopes
of having at least one public driver release include updated backlight
support by the time upstream kernels start shipping with the backlight
changes.
> Regards,
>
> Hans
>
>
>
>>>
>>>> +
>>>> /* On systems with ACPI video use either native or ACPI video. */
>>>> if (video_caps & ACPI_VIDEO_BACKLIGHT) {
>>>> /*
>>>> diff --git a/drivers/gpu/drm/gma500/Kconfig b/drivers/gpu/drm/gma500/Kconfig
>>>> index 0cff20265f97..807b989e3c77 100644
>>>> --- a/drivers/gpu/drm/gma500/Kconfig
>>>> +++ b/drivers/gpu/drm/gma500/Kconfig
>>>> @@ -7,6 +7,8 @@ config DRM_GMA500
>>>> select ACPI_VIDEO if ACPI
>>>> select BACKLIGHT_CLASS_DEVICE if ACPI
>>>> select INPUT if ACPI
>>>> + select X86_PLATFORM_DEVICES if ACPI
>>>> + select ACPI_WMI if ACPI
>>>
>>> I'm not sure I understand why the Intel DRM drivers pick up the additional platform/x86 and WMI dependencies here. ACPI_VIDEO already depends on these, doesn't it?
>> It does.
>>
>>> If Kconfig doesn't otherwise automatically pull in an option's dependencies when selecting that option
>> Right that is the reason why this is done, for select the Kconfig block must also select all deps
>>
>>> then shouldn't Nouveau's Kconfig get updated as well?
>>> It selects ACPI_VIDEO in some configuration cases.
>> nouveau's Kconfig block already selects ACPI_WMI:
>>
>> config DRM_NOUVEAU
>> tristate "Nouveau (NVIDIA) cards"
>> ...
>> select X86_PLATFORM_DEVICES if ACPI && X86
>> select ACPI_WMI if ACPI && X86
>> ...
>> select ACPI_VIDEO if ACPI && X86
>>
>> That is why this patch does not add this.
>>
>>> (It looks like amdgpu doesn't currently select ACPI_VIDEO, maybe because it doesn't depend on it the way the Intel drivers do: there are several AMD+NVIDIA iGPU/dGPU designs out there which use this backlight interface.)
>> Correct, but with this series amdgpu/radeon also start using ACPI_VIDEO
>> functions so these patches:
>>
>> https://patchwork.freedesktop.org/patch/493650/
>> https://patchwork.freedesktop.org/patch/493653/
>>
>> Add the necessary selects and I cheated a bit and also made
>> them select ACPI_WMI already even though that is only
>> necessary after this patch (which comes later in the series).
>>
>> I hope this answers al your questions...
>>
>> Regards,
>>
>> Hans
>>
>>
>>
>>>
>>>> help
>>>> Say yes for an experimental 2D KMS framebuffer driver for the
>>>> Intel GMA500 (Poulsbo), Intel GMA600 (Moorestown/Oak Trail) and
>>>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>>>> index 7ae3b7d67fcf..3efce05d7b57 100644
>>>> --- a/drivers/gpu/drm/i915/Kconfig
>>>> +++ b/drivers/gpu/drm/i915/Kconfig
>>>> @@ -23,6 +23,8 @@ config DRM_I915
>>>> # but for select to work, need to select ACPI_VIDEO's dependencies, ick
>>>> select BACKLIGHT_CLASS_DEVICE if ACPI
>>>> select INPUT if ACPI
>>>> + select X86_PLATFORM_DEVICES if ACPI
>>>> + select ACPI_WMI if ACPI
>>>> select ACPI_VIDEO if ACPI
>>>> select ACPI_BUTTON if ACPI
>>>> select SYNC_FILE
>>>> diff --git a/include/acpi/video.h b/include/acpi/video.h
>>>> index 0625806d3bbd..91578e77ac4e 100644
>>>> --- a/include/acpi/video.h
>>>> +++ b/include/acpi/video.h
>>>> @@ -48,6 +48,7 @@ enum acpi_backlight_type {
>>>> acpi_backlight_video,
>>>> acpi_backlight_vendor,
>>>> acpi_backlight_native,
>>>> + acpi_backlight_nvidia_wmi_ec,
>>>> };
>>>> #if IS_ENABLED(CONFIG_ACPI_VIDEO)
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v2 17/29] ACPI: video: Add Apple GMUX brightness control detection
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (15 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 16/29] ACPI: video: Add Nvidia WMI EC brightness control detection Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-12 19:38 ` [PATCH v2 18/29] platform/x86: apple-gmux: Stop calling acpi/video.h functions Hans de Goede
` (13 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
On Apple laptops with an Apple GMUX using this for brightness control,
should take precedence of any other brightness control methods.
Add apple-gmux detection to acpi_video_get_backlight_type() using
the already existing apple_gmux_present() helper function.
This will allow removig the (ab)use of:
acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
Inside the apple-gmux driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/video_detect.c | 4 ++++
include/acpi/video.h | 1 +
2 files changed, 5 insertions(+)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 7b89dc9a04a2..ce96cd7abe0b 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -28,6 +28,7 @@
#include <linux/export.h>
#include <linux/acpi.h>
+#include <linux/apple-gmux.h>
#include <linux/backlight.h>
#include <linux/dmi.h>
#include <linux/module.h>
@@ -582,6 +583,9 @@ static enum acpi_backlight_type __acpi_video_get_backlight_type(bool native)
if (nvidia_wmi_ec_present)
return acpi_backlight_nvidia_wmi_ec;
+ 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) {
/*
diff --git a/include/acpi/video.h b/include/acpi/video.h
index 91578e77ac4e..dbd48cb8bd23 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -49,6 +49,7 @@ enum acpi_backlight_type {
acpi_backlight_vendor,
acpi_backlight_native,
acpi_backlight_nvidia_wmi_ec,
+ acpi_backlight_apple_gmux,
};
#if IS_ENABLED(CONFIG_ACPI_VIDEO)
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 18/29] platform/x86: apple-gmux: Stop calling acpi/video.h functions
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (16 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 17/29] ACPI: video: Add Apple GMUX " Hans de Goede
@ 2022-07-12 19:38 ` Hans de Goede
2022-07-12 19:39 ` [PATCH v2 19/29] platform/x86: toshiba_acpi: Stop using acpi_video_set_dmi_backlight_type() Hans de Goede
` (12 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:38 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Now that acpi_video_get_backlight_type() has apple-gmux detection (using
apple_gmux_present()), it is no longer necessary for the apple-gmux code
to manually remove possibly conflicting drivers.
So remove the handling for this from the apple-gmux driver.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/platform/x86/apple-gmux.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/platform/x86/apple-gmux.c b/drivers/platform/x86/apple-gmux.c
index 57553f9b4d1d..071a5ffcb2b7 100644
--- a/drivers/platform/x86/apple-gmux.c
+++ b/drivers/platform/x86/apple-gmux.c
@@ -21,7 +21,6 @@
#include <linux/delay.h>
#include <linux/pci.h>
#include <linux/vga_switcheroo.h>
-#include <acpi/video.h>
#include <asm/io.h>
/**
@@ -697,7 +696,6 @@ static int gmux_probe(struct pnp_dev *pnp, const struct pnp_device_id *id)
* backlight control and supports more levels than other options.
* Disable the other backlight choices.
*/
- acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
apple_bl_unregister();
gmux_data->power_state = VGA_SWITCHEROO_ON;
@@ -807,7 +805,6 @@ static void gmux_remove(struct pnp_dev *pnp)
apple_gmux_data = NULL;
kfree(gmux_data);
- acpi_video_register();
apple_bl_register();
}
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 19/29] platform/x86: toshiba_acpi: Stop using acpi_video_set_dmi_backlight_type()
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (17 preceding siblings ...)
2022-07-12 19:38 ` [PATCH v2 18/29] platform/x86: apple-gmux: Stop calling acpi/video.h functions Hans de Goede
@ 2022-07-12 19:39 ` Hans de Goede
2022-07-12 19:39 ` [PATCH v2 20/29] platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c Hans de Goede
` (11 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:39 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight, acpi_video_set_dmi_backlight_type()
actually calls acpi_video_unregister_backlight() since that is often
probed earlier, leading to userspace seeing the acpi_video0 class
device being briefly available, leading to races in userspace where
udev probe-rules try to access the device and it is already gone.
In case of toshiba_acpi there are no DMI quirks to move to
acpi/video_detect.c, but it also (ab)uses it for transflective
displays. Adding transflective display support to video_detect.c would
be quite involved. But luckily there are only 2 known models with
a transflective display, so we can just add DMI quirks for those.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/video_detect.c | 19 +++++++++++++++++++
drivers/platform/x86/toshiba_acpi.c | 16 ----------------
2 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index ce96cd7abe0b..a514adaec14d 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -188,6 +188,25 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
},
},
+ /*
+ * Toshiba models with Transflective display, these need to use
+ * the toshiba_acpi vendor driver for proper Transflective handling.
+ */
+ {
+ .callback = video_detect_force_vendor,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R500"),
+ },
+ },
+ {
+ .callback = video_detect_force_vendor,
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "PORTEGE R600"),
+ },
+ },
+
/*
* These models have a working acpi_video backlight control, and using
* native backlight causes a regression where backlight does not work
diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/toshiba_acpi.c
index 0fc9e8b8827b..030dc37d50b8 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -271,14 +271,6 @@ static const struct key_entry toshiba_acpi_alt_keymap[] = {
{ KE_END, 0 },
};
-/*
- * List of models which have a broken acpi-video backlight interface and thus
- * need to use the toshiba (vendor) interface instead.
- */
-static const struct dmi_system_id toshiba_vendor_backlight_dmi[] = {
- {}
-};
-
/*
* Utility
*/
@@ -2881,14 +2873,6 @@ static int toshiba_acpi_setup_backlight(struct toshiba_acpi_dev *dev)
return 0;
}
- /*
- * Tell acpi-video-detect code to prefer vendor backlight on all
- * systems with transflective backlight and on dmi matched systems.
- */
- if (dev->tr_backlight_supported ||
- dmi_check_system(toshiba_vendor_backlight_dmi))
- acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
-
if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
return 0;
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 20/29] platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (18 preceding siblings ...)
2022-07-12 19:39 ` [PATCH v2 19/29] platform/x86: toshiba_acpi: Stop using acpi_video_set_dmi_backlight_type() Hans de Goede
@ 2022-07-12 19:39 ` Hans de Goede
2022-07-12 20:24 ` Daniel Dadap
2022-07-12 19:39 ` [PATCH v2 21/29] platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling Hans de Goede
` (10 subsequent siblings)
30 siblings, 1 reply; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:39 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Move the backlight DMI quirks to acpi/video_detect.c, so that
the driver no longer needs to call acpi_video_set_dmi_backlight_type().
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Note that even though the DMI quirk table name was video_vendor_dmi_table,
5/6 quirks were actually quirks to use the GPU native backlight.
These 5 quirks also had a callback in their dmi_system_id entry which
disabled the acer-wmi vendor driver; and any DMI match resulted in:
acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
which disabled the acpi_video driver, so only the native driver was left.
The new entries for these 5/6 devices correctly marks these as needing
the native backlight driver.
Also note that other changes in this series change the native backlight
drivers to no longer unconditionally register their backlight. Instead
these drivers now do this check:
if (acpi_video_get_backlight_type(false) != acpi_backlight_native)
return 0; /* bail */
which without this patch would have broken these 5/6 "special" quirks.
Since I had to look at all the commits adding the quirks anyways, to make
sure that I understood the code correctly, I've also added links to
the various original bugzillas for these quirks to the new entries.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/video_detect.c | 53 ++++++++++++++++++++++++++
drivers/platform/x86/acer-wmi.c | 66 ---------------------------------
2 files changed, 53 insertions(+), 66 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index a514adaec14d..cd51cb0d7821 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -147,6 +147,15 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
DMI_MATCH(DMI_BOARD_NAME, "X360"),
},
},
+ {
+ /* https://bugzilla.redhat.com/show_bug.cgi?id=1128309 */
+ .callback = video_detect_force_vendor,
+ /* Acer KAV80 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "KAV80"),
+ },
+ },
{
.callback = video_detect_force_vendor,
/* Asus UL30VT */
@@ -427,6 +436,41 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
DMI_MATCH(DMI_BOARD_NAME, "JV50"),
},
},
+ {
+ /* https://bugzilla.redhat.com/show_bug.cgi?id=1012674 */
+ .callback = video_detect_force_native,
+ /* Acer Aspire 5741 */
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"),
+ },
+ },
+ {
+ /* https://bugzilla.kernel.org/show_bug.cgi?id=42993 */
+ .callback = video_detect_force_native,
+ /* Acer Aspire 5750 */
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"),
+ },
+ },
+ {
+ /* https://bugzilla.kernel.org/show_bug.cgi?id=42833 */
+ .callback = video_detect_force_native,
+ /* Acer Extensa 5235 */
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5235"),
+ },
+ },
+ {
+ .callback = video_detect_force_native,
+ /* Acer TravelMate 4750 */
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
+ },
+ },
{
/* https://bugzilla.kernel.org/show_bug.cgi?id=207835 */
.callback = video_detect_force_native,
@@ -437,6 +481,15 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
DMI_MATCH(DMI_BOARD_NAME, "BA51_MV"),
},
},
+ {
+ /* https://bugzilla.kernel.org/show_bug.cgi?id=36322 */
+ .callback = video_detect_force_native,
+ /* Acer TravelMate 5760 */
+ .matches = {
+ DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
+ DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5760"),
+ },
+ },
{
.callback = video_detect_force_native,
/* ASUSTeK COMPUTER INC. GA401 */
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
index 9c6943e401a6..c08eeb1e0e05 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -643,69 +643,6 @@ static const struct dmi_system_id non_acer_quirks[] __initconst = {
{}
};
-static int __init
-video_set_backlight_video_vendor(const struct dmi_system_id *d)
-{
- interface->capability &= ~ACER_CAP_BRIGHTNESS;
- pr_info("Brightness must be controlled by generic video driver\n");
- return 0;
-}
-
-static const struct dmi_system_id video_vendor_dmi_table[] __initconst = {
- {
- .callback = video_set_backlight_video_vendor,
- .ident = "Acer TravelMate 4750",
- .matches = {
- DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
- DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
- },
- },
- {
- .callback = video_set_backlight_video_vendor,
- .ident = "Acer Extensa 5235",
- .matches = {
- DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
- DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5235"),
- },
- },
- {
- .callback = video_set_backlight_video_vendor,
- .ident = "Acer TravelMate 5760",
- .matches = {
- DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
- DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5760"),
- },
- },
- {
- .callback = video_set_backlight_video_vendor,
- .ident = "Acer Aspire 5750",
- .matches = {
- DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
- DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"),
- },
- },
- {
- .callback = video_set_backlight_video_vendor,
- .ident = "Acer Aspire 5741",
- .matches = {
- DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
- DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"),
- },
- },
- {
- /*
- * Note no video_set_backlight_video_vendor, we must use the
- * acer interface, as there is no native backlight interface.
- */
- .ident = "Acer KAV80",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
- DMI_MATCH(DMI_PRODUCT_NAME, "KAV80"),
- },
- },
- {}
-};
-
/* Find which quirks are needed for a particular vendor/ model pair */
static void __init find_quirks(void)
{
@@ -2482,9 +2419,6 @@ static int __init acer_wmi_init(void)
set_quirks();
- if (dmi_check_system(video_vendor_dmi_table))
- acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
-
if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
interface->capability &= ~ACER_CAP_BRIGHTNESS;
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v2 20/29] platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c
2022-07-12 19:39 ` [PATCH v2 20/29] platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c Hans de Goede
@ 2022-07-12 20:24 ` Daniel Dadap
2022-07-15 12:01 ` Hans de Goede
0 siblings, 1 reply; 58+ messages in thread
From: Daniel Dadap @ 2022-07-12 20:24 UTC (permalink / raw)
To: Hans de Goede, Ben Skeggs, Karol Herbst, Lyude,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher,
Christian König, Xinhui, Rafael J . Wysocki,
Mika Westerberg, Lukas Wunner, Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
I'll ask around to see if there's some DMI property we can match in
order to detect whether a system is expected to use the EC backlight
driver: if so, maybe we can avoid the WMI interactions in patch 16/29 of
this series. Although I suppose even if there were a DMI property, we'd
still need to call the WMI-wrapped ACPI method to check whether the
system is currently configured to drive the backlight through the EC,
unless the system somehow exports a different DMI table depending on the
current backlight control configuration, which I imagine to be unlikely.
This change looks fine to me, although I suppose somebody who maintains
the acer-wmi driver should comment. The bugzilla links are a nice touch.
On 7/12/22 14:39, Hans de Goede wrote:
> Move the backlight DMI quirks to acpi/video_detect.c, so that
> the driver no longer needs to call acpi_video_set_dmi_backlight_type().
>
> acpi_video_set_dmi_backlight_type() is troublesome because it may end up
> getting called after other backlight drivers have already called
> acpi_video_get_backlight_type() resulting in the other drivers
> already being registered even though they should not.
>
> Note that even though the DMI quirk table name was video_vendor_dmi_table,
> 5/6 quirks were actually quirks to use the GPU native backlight.
>
> These 5 quirks also had a callback in their dmi_system_id entry which
> disabled the acer-wmi vendor driver; and any DMI match resulted in:
>
> acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
>
> which disabled the acpi_video driver, so only the native driver was left.
> The new entries for these 5/6 devices correctly marks these as needing
> the native backlight driver.
>
> Also note that other changes in this series change the native backlight
> drivers to no longer unconditionally register their backlight. Instead
> these drivers now do this check:
>
> if (acpi_video_get_backlight_type(false) != acpi_backlight_native)
> return 0; /* bail */
>
> which without this patch would have broken these 5/6 "special" quirks.
>
> Since I had to look at all the commits adding the quirks anyways, to make
> sure that I understood the code correctly, I've also added links to
> the various original bugzillas for these quirks to the new entries.
>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
> ---
> drivers/acpi/video_detect.c | 53 ++++++++++++++++++++++++++
> drivers/platform/x86/acer-wmi.c | 66 ---------------------------------
> 2 files changed, 53 insertions(+), 66 deletions(-)
>
> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
> index a514adaec14d..cd51cb0d7821 100644
> --- a/drivers/acpi/video_detect.c
> +++ b/drivers/acpi/video_detect.c
> @@ -147,6 +147,15 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
> DMI_MATCH(DMI_BOARD_NAME, "X360"),
> },
> },
> + {
> + /* https://bugzilla.redhat.com/show_bug.cgi?id=1128309 */
> + .callback = video_detect_force_vendor,
> + /* Acer KAV80 */
> + .matches = {
> + DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "KAV80"),
> + },
> + },
> {
> .callback = video_detect_force_vendor,
> /* Asus UL30VT */
> @@ -427,6 +436,41 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
> DMI_MATCH(DMI_BOARD_NAME, "JV50"),
> },
> },
> + {
> + /* https://bugzilla.redhat.com/show_bug.cgi?id=1012674 */
> + .callback = video_detect_force_native,
> + /* Acer Aspire 5741 */
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"),
> + },
> + },
> + {
> + /* https://bugzilla.kernel.org/show_bug.cgi?id=42993 */
> + .callback = video_detect_force_native,
> + /* Acer Aspire 5750 */
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"),
> + },
> + },
> + {
> + /* https://bugzilla.kernel.org/show_bug.cgi?id=42833 */
> + .callback = video_detect_force_native,
> + /* Acer Extensa 5235 */
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5235"),
> + },
> + },
> + {
> + .callback = video_detect_force_native,
> + /* Acer TravelMate 4750 */
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
> + },
> + },
> {
> /* https://bugzilla.kernel.org/show_bug.cgi?id=207835 */
> .callback = video_detect_force_native,
> @@ -437,6 +481,15 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
> DMI_MATCH(DMI_BOARD_NAME, "BA51_MV"),
> },
> },
> + {
> + /* https://bugzilla.kernel.org/show_bug.cgi?id=36322 */
> + .callback = video_detect_force_native,
> + /* Acer TravelMate 5760 */
> + .matches = {
> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> + DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5760"),
> + },
> + },
> {
> .callback = video_detect_force_native,
> /* ASUSTeK COMPUTER INC. GA401 */
> diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
> index 9c6943e401a6..c08eeb1e0e05 100644
> --- a/drivers/platform/x86/acer-wmi.c
> +++ b/drivers/platform/x86/acer-wmi.c
> @@ -643,69 +643,6 @@ static const struct dmi_system_id non_acer_quirks[] __initconst = {
> {}
> };
>
> -static int __init
> -video_set_backlight_video_vendor(const struct dmi_system_id *d)
> -{
> - interface->capability &= ~ACER_CAP_BRIGHTNESS;
> - pr_info("Brightness must be controlled by generic video driver\n");
> - return 0;
> -}
> -
> -static const struct dmi_system_id video_vendor_dmi_table[] __initconst = {
> - {
> - .callback = video_set_backlight_video_vendor,
> - .ident = "Acer TravelMate 4750",
> - .matches = {
> - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> - DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
> - },
> - },
> - {
> - .callback = video_set_backlight_video_vendor,
> - .ident = "Acer Extensa 5235",
> - .matches = {
> - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> - DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5235"),
> - },
> - },
> - {
> - .callback = video_set_backlight_video_vendor,
> - .ident = "Acer TravelMate 5760",
> - .matches = {
> - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> - DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5760"),
> - },
> - },
> - {
> - .callback = video_set_backlight_video_vendor,
> - .ident = "Acer Aspire 5750",
> - .matches = {
> - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> - DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"),
> - },
> - },
> - {
> - .callback = video_set_backlight_video_vendor,
> - .ident = "Acer Aspire 5741",
> - .matches = {
> - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
> - DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"),
> - },
> - },
> - {
> - /*
> - * Note no video_set_backlight_video_vendor, we must use the
> - * acer interface, as there is no native backlight interface.
> - */
> - .ident = "Acer KAV80",
> - .matches = {
> - DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
> - DMI_MATCH(DMI_PRODUCT_NAME, "KAV80"),
> - },
> - },
> - {}
> -};
> -
> /* Find which quirks are needed for a particular vendor/ model pair */
> static void __init find_quirks(void)
> {
> @@ -2482,9 +2419,6 @@ static int __init acer_wmi_init(void)
>
> set_quirks();
>
> - if (dmi_check_system(video_vendor_dmi_table))
> - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
> -
> if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
> interface->capability &= ~ACER_CAP_BRIGHTNESS;
>
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 20/29] platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c
2022-07-12 20:24 ` Daniel Dadap
@ 2022-07-15 12:01 ` Hans de Goede
0 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-15 12:01 UTC (permalink / raw)
To: Daniel Dadap, Ben Skeggs, Karol Herbst, Lyude, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Hi,
On 7/12/22 22:24, Daniel Dadap wrote:
> I'll ask around to see if there's some DMI property we can match in order to detect whether a system is expected to use the EC backlight driver: if so, maybe we can avoid the WMI interactions in patch 16/29 of this series. Although I suppose even if there were a DMI property, we'd still need to call the WMI-wrapped ACPI method to check whether the system is currently configured to drive the backlight through the EC, unless the system somehow exports a different DMI table depending on the current backlight control configuration, which I imagine to be unlikely.
IMHO the duplication is fine, it is also important that
the video_detect.c code and the actual backlight driver use
the same detection mechanism where possible.
Otherwise acpi_video_get_backlight_type() may return
acpi_backlight_nvidia_wmi_ec while the EC backlight driver
refuses to load...
Regards,
Hans
>
> This change looks fine to me, although I suppose somebody who maintains the acer-wmi driver should comment. The bugzilla links are a nice touch.
>
> On 7/12/22 14:39, Hans de Goede wrote:
>> Move the backlight DMI quirks to acpi/video_detect.c, so that
>> the driver no longer needs to call acpi_video_set_dmi_backlight_type().
>>
>> acpi_video_set_dmi_backlight_type() is troublesome because it may end up
>> getting called after other backlight drivers have already called
>> acpi_video_get_backlight_type() resulting in the other drivers
>> already being registered even though they should not.
>>
>> Note that even though the DMI quirk table name was video_vendor_dmi_table,
>> 5/6 quirks were actually quirks to use the GPU native backlight.
>>
>> These 5 quirks also had a callback in their dmi_system_id entry which
>> disabled the acer-wmi vendor driver; and any DMI match resulted in:
>>
>> acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
>>
>> which disabled the acpi_video driver, so only the native driver was left.
>> The new entries for these 5/6 devices correctly marks these as needing
>> the native backlight driver.
>>
>> Also note that other changes in this series change the native backlight
>> drivers to no longer unconditionally register their backlight. Instead
>> these drivers now do this check:
>>
>> if (acpi_video_get_backlight_type(false) != acpi_backlight_native)
>> return 0; /* bail */
>>
>> which without this patch would have broken these 5/6 "special" quirks.
>>
>> Since I had to look at all the commits adding the quirks anyways, to make
>> sure that I understood the code correctly, I've also added links to
>> the various original bugzillas for these quirks to the new entries.
>>
>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>> ---
>> drivers/acpi/video_detect.c | 53 ++++++++++++++++++++++++++
>> drivers/platform/x86/acer-wmi.c | 66 ---------------------------------
>> 2 files changed, 53 insertions(+), 66 deletions(-)
>>
>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>> index a514adaec14d..cd51cb0d7821 100644
>> --- a/drivers/acpi/video_detect.c
>> +++ b/drivers/acpi/video_detect.c
>> @@ -147,6 +147,15 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
>> DMI_MATCH(DMI_BOARD_NAME, "X360"),
>> },
>> },
>> + {
>> + /* https://bugzilla.redhat.com/show_bug.cgi?id=1128309 */
>> + .callback = video_detect_force_vendor,
>> + /* Acer KAV80 */
>> + .matches = {
>> + DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "KAV80"),
>> + },
>> + },
>> {
>> .callback = video_detect_force_vendor,
>> /* Asus UL30VT */
>> @@ -427,6 +436,41 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
>> DMI_MATCH(DMI_BOARD_NAME, "JV50"),
>> },
>> },
>> + {
>> + /* https://bugzilla.redhat.com/show_bug.cgi?id=1012674 */
>> + .callback = video_detect_force_native,
>> + /* Acer Aspire 5741 */
>> + .matches = {
>> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"),
>> + },
>> + },
>> + {
>> + /* https://bugzilla.kernel.org/show_bug.cgi?id=42993 */
>> + .callback = video_detect_force_native,
>> + /* Acer Aspire 5750 */
>> + .matches = {
>> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"),
>> + },
>> + },
>> + {
>> + /* https://bugzilla.kernel.org/show_bug.cgi?id=42833 */
>> + .callback = video_detect_force_native,
>> + /* Acer Extensa 5235 */
>> + .matches = {
>> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5235"),
>> + },
>> + },
>> + {
>> + .callback = video_detect_force_native,
>> + /* Acer TravelMate 4750 */
>> + .matches = {
>> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
>> + },
>> + },
>> {
>> /* https://bugzilla.kernel.org/show_bug.cgi?id=207835 */
>> .callback = video_detect_force_native,
>> @@ -437,6 +481,15 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
>> DMI_MATCH(DMI_BOARD_NAME, "BA51_MV"),
>> },
>> },
>> + {
>> + /* https://bugzilla.kernel.org/show_bug.cgi?id=36322 */
>> + .callback = video_detect_force_native,
>> + /* Acer TravelMate 5760 */
>> + .matches = {
>> + DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5760"),
>> + },
>> + },
>> {
>> .callback = video_detect_force_native,
>> /* ASUSTeK COMPUTER INC. GA401 */
>> diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wmi.c
>> index 9c6943e401a6..c08eeb1e0e05 100644
>> --- a/drivers/platform/x86/acer-wmi.c
>> +++ b/drivers/platform/x86/acer-wmi.c
>> @@ -643,69 +643,6 @@ static const struct dmi_system_id non_acer_quirks[] __initconst = {
>> {}
>> };
>> -static int __init
>> -video_set_backlight_video_vendor(const struct dmi_system_id *d)
>> -{
>> - interface->capability &= ~ACER_CAP_BRIGHTNESS;
>> - pr_info("Brightness must be controlled by generic video driver\n");
>> - return 0;
>> -}
>> -
>> -static const struct dmi_system_id video_vendor_dmi_table[] __initconst = {
>> - {
>> - .callback = video_set_backlight_video_vendor,
>> - .ident = "Acer TravelMate 4750",
>> - .matches = {
>> - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
>> - DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 4750"),
>> - },
>> - },
>> - {
>> - .callback = video_set_backlight_video_vendor,
>> - .ident = "Acer Extensa 5235",
>> - .matches = {
>> - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
>> - DMI_MATCH(DMI_PRODUCT_NAME, "Extensa 5235"),
>> - },
>> - },
>> - {
>> - .callback = video_set_backlight_video_vendor,
>> - .ident = "Acer TravelMate 5760",
>> - .matches = {
>> - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
>> - DMI_MATCH(DMI_PRODUCT_NAME, "TravelMate 5760"),
>> - },
>> - },
>> - {
>> - .callback = video_set_backlight_video_vendor,
>> - .ident = "Acer Aspire 5750",
>> - .matches = {
>> - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
>> - DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5750"),
>> - },
>> - },
>> - {
>> - .callback = video_set_backlight_video_vendor,
>> - .ident = "Acer Aspire 5741",
>> - .matches = {
>> - DMI_MATCH(DMI_BOARD_VENDOR, "Acer"),
>> - DMI_MATCH(DMI_PRODUCT_NAME, "Aspire 5741"),
>> - },
>> - },
>> - {
>> - /*
>> - * Note no video_set_backlight_video_vendor, we must use the
>> - * acer interface, as there is no native backlight interface.
>> - */
>> - .ident = "Acer KAV80",
>> - .matches = {
>> - DMI_MATCH(DMI_SYS_VENDOR, "Acer"),
>> - DMI_MATCH(DMI_PRODUCT_NAME, "KAV80"),
>> - },
>> - },
>> - {}
>> -};
>> -
>> /* Find which quirks are needed for a particular vendor/ model pair */
>> static void __init find_quirks(void)
>> {
>> @@ -2482,9 +2419,6 @@ static int __init acer_wmi_init(void)
>> set_quirks();
>> - if (dmi_check_system(video_vendor_dmi_table))
>> - acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
>> -
>> if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
>> interface->capability &= ~ACER_CAP_BRIGHTNESS;
>>
>
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v2 21/29] platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (19 preceding siblings ...)
2022-07-12 19:39 ` [PATCH v2 20/29] platform/x86: acer-wmi: Move backlight DMI quirks to acpi/video_detect.c Hans de Goede
@ 2022-07-12 19:39 ` Hans de Goede
2022-07-12 19:39 ` [PATCH v2 22/29] platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI video_detect.c Hans de Goede
` (9 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:39 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Remove this check from the asus-wmi backlight handling:
/* Some Asus desktop boards export an acpi-video backlight interface,
stop this from showing up */
chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
if (chassis_type && !strcmp(chassis_type, "3"))
acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
This acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) call must be
removed because other changes in this series change the native backlight
drivers to no longer unconditionally register their backlight. Instead
these drivers now do this check:
if (acpi_video_get_backlight_type(false) != acpi_backlight_native)
return 0; /* bail */
So leaving this in place can break things on laptops with a broken
DMI chassis-type, which would have GPU native brightness control before
the addition of the acpi_video_get_backlight_type() != native check.
Removing this should be ok now, since the ACPI video code has improved
heuristics for this itself now (which includes a chassis-type check).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/platform/x86/asus-wmi.c | 7 -------
1 file changed, 7 deletions(-)
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 62ce198a3463..9dab0998cd20 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3528,7 +3528,6 @@ static int asus_wmi_add(struct platform_device *pdev)
struct platform_driver *pdrv = to_platform_driver(pdev->dev.driver);
struct asus_wmi_driver *wdrv = to_asus_wmi_driver(pdrv);
struct asus_wmi *asus;
- const char *chassis_type;
acpi_status status;
int err;
u32 result;
@@ -3610,12 +3609,6 @@ static int asus_wmi_add(struct platform_device *pdev)
if (asus->driver->quirks->wmi_force_als_set)
asus_wmi_set_als();
- /* Some Asus desktop boards export an acpi-video backlight interface,
- stop this from showing up */
- chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
- if (chassis_type && !strcmp(chassis_type, "3"))
- acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
-
if (asus->driver->quirks->wmi_backlight_power)
acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 22/29] platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI video_detect.c
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (20 preceding siblings ...)
2022-07-12 19:39 ` [PATCH v2 21/29] platform/x86: asus-wmi: Drop DMI chassis-type check from backlight handling Hans de Goede
@ 2022-07-12 19:39 ` Hans de Goede
2022-07-12 19:39 ` [PATCH v2 23/29] platform/x86: asus-wmi: Move acpi_backlight=native " Hans de Goede
` (8 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:39 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Remove the asus-wmi quirk_entry.wmi_backlight_power quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_vendor callback.
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Note no entries are dropped from the dmi_system_id table in asus-nb-wmi.c.
This is because the entries using the removed wmi_backlight_power flag
also use other model specific quirks from the asus-wmi quirk_entry struct.
So the quirk_asus_x55u struct and the entries pointing to it cannot be
dropped.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/video_detect.c | 40 ++++++++++++++++++++++++++++++
drivers/platform/x86/asus-nb-wmi.c | 7 ------
drivers/platform/x86/asus-wmi.c | 3 ---
drivers/platform/x86/asus-wmi.h | 1 -
drivers/platform/x86/eeepc-wmi.c | 25 +------------------
5 files changed, 41 insertions(+), 35 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index cd51cb0d7821..5d5215969f1d 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -172,6 +172,46 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"),
},
},
+ {
+ .callback = video_detect_force_vendor,
+ /* Asus X55U */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X55U"),
+ },
+ },
+ {
+ .callback = video_detect_force_vendor,
+ /* Asus X101CH */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X101CH"),
+ },
+ },
+ {
+ .callback = video_detect_force_vendor,
+ /* Asus X401U */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X401U"),
+ },
+ },
+ {
+ .callback = video_detect_force_vendor,
+ /* Asus X501U */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "X501U"),
+ },
+ },
+ {
+ .callback = video_detect_force_vendor,
+ /* Asus 1015CX */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "1015CX"),
+ },
+ },
{
.callback = video_detect_force_vendor,
/* GIGABYTE GB-BXBT-2807 */
diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index 57a07db659cb..074b4764ee8a 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -79,12 +79,10 @@ static struct quirk_entry quirk_asus_q500a = {
/*
* For those machines that need software to control bt/wifi status
- * and can't adjust brightness through ACPI interface
* and have duplicate events(ACPI and WMI) for display toggle
*/
static struct quirk_entry quirk_asus_x55u = {
.wapf = 4,
- .wmi_backlight_power = true,
.wmi_backlight_set_devstate = true,
.no_display_toggle = true,
};
@@ -147,11 +145,6 @@ static const struct dmi_system_id asus_quirks[] = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "U32U"),
},
- /*
- * Note this machine has a Brazos APU, and most Brazos Asus
- * machines need quirk_asus_x55u / wmi_backlight_power but
- * here acpi-video seems to work fine for backlight control.
- */
.driver_data = &quirk_asus_wapf4,
},
{
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index 9dab0998cd20..ac3f5606e267 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3609,9 +3609,6 @@ static int asus_wmi_add(struct platform_device *pdev)
if (asus->driver->quirks->wmi_force_als_set)
asus_wmi_set_als();
- if (asus->driver->quirks->wmi_backlight_power)
- acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
-
if (asus->driver->quirks->wmi_backlight_native)
acpi_video_set_dmi_backlight_type(acpi_backlight_native);
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index b302415bf1d9..30770e411301 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -29,7 +29,6 @@ struct quirk_entry {
bool hotplug_wireless;
bool scalar_panel_brightness;
bool store_backlight_power;
- bool wmi_backlight_power;
bool wmi_backlight_native;
bool wmi_backlight_set_devstate;
bool wmi_force_als_set;
diff --git a/drivers/platform/x86/eeepc-wmi.c b/drivers/platform/x86/eeepc-wmi.c
index ce86d84ee796..32d9f0ba6be3 100644
--- a/drivers/platform/x86/eeepc-wmi.c
+++ b/drivers/platform/x86/eeepc-wmi.c
@@ -96,11 +96,6 @@ static struct quirk_entry quirk_asus_et2012_type3 = {
.store_backlight_power = true,
};
-static struct quirk_entry quirk_asus_x101ch = {
- /* We need this when ACPI function doesn't do this well */
- .wmi_backlight_power = true,
-};
-
static struct quirk_entry *quirks;
static void et2012_quirks(void)
@@ -151,25 +146,7 @@ static const struct dmi_system_id asus_quirks[] = {
},
.driver_data = &quirk_asus_unknown,
},
- {
- .callback = dmi_matched,
- .ident = "ASUSTeK Computer INC. X101CH",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
- DMI_MATCH(DMI_PRODUCT_NAME, "X101CH"),
- },
- .driver_data = &quirk_asus_x101ch,
- },
- {
- .callback = dmi_matched,
- .ident = "ASUSTeK Computer INC. 1015CX",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
- DMI_MATCH(DMI_PRODUCT_NAME, "1015CX"),
- },
- .driver_data = &quirk_asus_x101ch,
- },
- {},
+ {}
};
static void eeepc_wmi_key_filter(struct asus_wmi_driver *asus_wmi, int *code,
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 23/29] platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI video_detect.c
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (21 preceding siblings ...)
2022-07-12 19:39 ` [PATCH v2 22/29] platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI video_detect.c Hans de Goede
@ 2022-07-12 19:39 ` Hans de Goede
2022-07-12 19:39 ` [PATCH v2 24/29] platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] " Hans de Goede
` (7 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:39 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Remove the asus-wmi quirk_entry.wmi_backlight_native quirk-flag, which
called acpi_video_set_dmi_backlight_type(acpi_backlight_native) and replace
it with acpi/video_detect.c video_detect_dmi_table[] entries using the
video_detect_force_native callback.
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/video_detect.c | 8 ++++++++
drivers/platform/x86/asus-nb-wmi.c | 14 --------------
drivers/platform/x86/asus-wmi.c | 3 ---
drivers/platform/x86/asus-wmi.h | 1 -
4 files changed, 8 insertions(+), 18 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 5d5215969f1d..a92322f4caff 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -554,6 +554,14 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "GA503"),
},
},
+ {
+ .callback = video_detect_force_native,
+ /* Asus UX303UB */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
+ },
+ },
/*
* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
* working native and video interface. However the default detection
diff --git a/drivers/platform/x86/asus-nb-wmi.c b/drivers/platform/x86/asus-nb-wmi.c
index 074b4764ee8a..325ccd030a32 100644
--- a/drivers/platform/x86/asus-nb-wmi.c
+++ b/drivers/platform/x86/asus-nb-wmi.c
@@ -97,11 +97,6 @@ static struct quirk_entry quirk_asus_x200ca = {
.wmi_backlight_set_devstate = true,
};
-static struct quirk_entry quirk_asus_ux303ub = {
- .wmi_backlight_native = true,
- .wmi_backlight_set_devstate = true,
-};
-
static struct quirk_entry quirk_asus_x550lb = {
.wmi_backlight_set_devstate = true,
.xusb2pr = 0x01D9,
@@ -372,15 +367,6 @@ static const struct dmi_system_id asus_quirks[] = {
},
.driver_data = &quirk_asus_x200ca,
},
- {
- .callback = dmi_matched,
- .ident = "ASUSTeK COMPUTER INC. UX303UB",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
- DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
- },
- .driver_data = &quirk_asus_ux303ub,
- },
{
.callback = dmi_matched,
.ident = "ASUSTeK COMPUTER INC. UX330UAK",
diff --git a/drivers/platform/x86/asus-wmi.c b/drivers/platform/x86/asus-wmi.c
index ac3f5606e267..a0df14d35574 100644
--- a/drivers/platform/x86/asus-wmi.c
+++ b/drivers/platform/x86/asus-wmi.c
@@ -3609,9 +3609,6 @@ static int asus_wmi_add(struct platform_device *pdev)
if (asus->driver->quirks->wmi_force_als_set)
asus_wmi_set_als();
- if (asus->driver->quirks->wmi_backlight_native)
- acpi_video_set_dmi_backlight_type(acpi_backlight_native);
-
if (asus->driver->quirks->xusb2pr)
asus_wmi_set_xusb2pr(asus);
diff --git a/drivers/platform/x86/asus-wmi.h b/drivers/platform/x86/asus-wmi.h
index 30770e411301..f30252efe1db 100644
--- a/drivers/platform/x86/asus-wmi.h
+++ b/drivers/platform/x86/asus-wmi.h
@@ -29,7 +29,6 @@ struct quirk_entry {
bool hotplug_wireless;
bool scalar_panel_brightness;
bool store_backlight_power;
- bool wmi_backlight_native;
bool wmi_backlight_set_devstate;
bool wmi_force_als_set;
bool use_kbd_dock_devid;
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 24/29] platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] quirks to ACPI video_detect.c
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (22 preceding siblings ...)
2022-07-12 19:39 ` [PATCH v2 23/29] platform/x86: asus-wmi: Move acpi_backlight=native " Hans de Goede
@ 2022-07-12 19:39 ` Hans de Goede
2022-07-12 19:39 ` [PATCH v2 25/29] ACPI: video: Remove acpi_video_set_dmi_backlight_type() Hans de Goede
` (6 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:39 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
acpi_video_set_dmi_backlight_type() is troublesome because it may end up
getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
Move all the acpi_backlight=[vendor|native] quirks from samsung-laptop to
drivers/acpi/video_detect.c .
Note the X360 -> acpi_backlight=native quirk is not moved because that
already was present in drivers/acpi/video_detect.c .
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/video_detect.c | 54 +++++++++++++++++
drivers/platform/x86/samsung-laptop.c | 87 ---------------------------
2 files changed, 54 insertions(+), 87 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index a92322f4caff..84dce2c113ef 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -220,6 +220,33 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
},
},
+ {
+ .callback = video_detect_force_vendor,
+ /* Samsung N150/N210/N220 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "N150/N210/N220"),
+ DMI_MATCH(DMI_BOARD_NAME, "N150/N210/N220"),
+ },
+ },
+ {
+ .callback = video_detect_force_vendor,
+ /* Samsung NF110/NF210/NF310 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "NF110/NF210/NF310"),
+ DMI_MATCH(DMI_BOARD_NAME, "NF110/NF210/NF310"),
+ },
+ },
+ {
+ .callback = video_detect_force_vendor,
+ /* Samsung NC210 */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "NC210/NC110"),
+ DMI_MATCH(DMI_BOARD_NAME, "NC210/NC110"),
+ },
+ },
{
.callback = video_detect_force_vendor,
/* Sony VPCEH3U1E */
@@ -562,6 +589,33 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
DMI_MATCH(DMI_PRODUCT_NAME, "UX303UB"),
},
},
+ {
+ .callback = video_detect_force_native,
+ /* Samsung N150P */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "N150P"),
+ DMI_MATCH(DMI_BOARD_NAME, "N150P"),
+ },
+ },
+ {
+ .callback = video_detect_force_native,
+ /* Samsung N145P/N250P/N260P */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "N145P/N250P/N260P"),
+ DMI_MATCH(DMI_BOARD_NAME, "N145P/N250P/N260P"),
+ },
+ },
+ {
+ .callback = video_detect_force_native,
+ /* Samsung N250P */
+ .matches = {
+ DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
+ DMI_MATCH(DMI_PRODUCT_NAME, "N250P"),
+ DMI_MATCH(DMI_BOARD_NAME, "N250P"),
+ },
+ },
/*
* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
* working native and video interface. However the default detection
diff --git a/drivers/platform/x86/samsung-laptop.c b/drivers/platform/x86/samsung-laptop.c
index c187dcdf82f0..cc30cf08f32d 100644
--- a/drivers/platform/x86/samsung-laptop.c
+++ b/drivers/platform/x86/samsung-laptop.c
@@ -356,23 +356,13 @@ struct samsung_laptop {
};
struct samsung_quirks {
- bool broken_acpi_video;
bool four_kbd_backlight_levels;
bool enable_kbd_backlight;
- bool use_native_backlight;
bool lid_handling;
};
static struct samsung_quirks samsung_unknown = {};
-static struct samsung_quirks samsung_broken_acpi_video = {
- .broken_acpi_video = true,
-};
-
-static struct samsung_quirks samsung_use_native_backlight = {
- .use_native_backlight = true,
-};
-
static struct samsung_quirks samsung_np740u3e = {
.four_kbd_backlight_levels = true,
.enable_kbd_backlight = true,
@@ -1540,76 +1530,6 @@ static const struct dmi_system_id samsung_dmi_table[] __initconst = {
},
},
/* Specific DMI ids for laptop with quirks */
- {
- .callback = samsung_dmi_matched,
- .ident = "N150P",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
- DMI_MATCH(DMI_PRODUCT_NAME, "N150P"),
- DMI_MATCH(DMI_BOARD_NAME, "N150P"),
- },
- .driver_data = &samsung_use_native_backlight,
- },
- {
- .callback = samsung_dmi_matched,
- .ident = "N145P/N250P/N260P",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
- DMI_MATCH(DMI_PRODUCT_NAME, "N145P/N250P/N260P"),
- DMI_MATCH(DMI_BOARD_NAME, "N145P/N250P/N260P"),
- },
- .driver_data = &samsung_use_native_backlight,
- },
- {
- .callback = samsung_dmi_matched,
- .ident = "N150/N210/N220",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
- DMI_MATCH(DMI_PRODUCT_NAME, "N150/N210/N220"),
- DMI_MATCH(DMI_BOARD_NAME, "N150/N210/N220"),
- },
- .driver_data = &samsung_broken_acpi_video,
- },
- {
- .callback = samsung_dmi_matched,
- .ident = "NF110/NF210/NF310",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
- DMI_MATCH(DMI_PRODUCT_NAME, "NF110/NF210/NF310"),
- DMI_MATCH(DMI_BOARD_NAME, "NF110/NF210/NF310"),
- },
- .driver_data = &samsung_broken_acpi_video,
- },
- {
- .callback = samsung_dmi_matched,
- .ident = "X360",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
- DMI_MATCH(DMI_PRODUCT_NAME, "X360"),
- DMI_MATCH(DMI_BOARD_NAME, "X360"),
- },
- .driver_data = &samsung_broken_acpi_video,
- },
- {
- .callback = samsung_dmi_matched,
- .ident = "N250P",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
- DMI_MATCH(DMI_PRODUCT_NAME, "N250P"),
- DMI_MATCH(DMI_BOARD_NAME, "N250P"),
- },
- .driver_data = &samsung_use_native_backlight,
- },
- {
- .callback = samsung_dmi_matched,
- .ident = "NC210",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD."),
- DMI_MATCH(DMI_PRODUCT_NAME, "NC210/NC110"),
- DMI_MATCH(DMI_BOARD_NAME, "NC210/NC110"),
- },
- .driver_data = &samsung_broken_acpi_video,
- },
{
.callback = samsung_dmi_matched,
.ident = "730U3E/740U3E",
@@ -1654,15 +1574,8 @@ static int __init samsung_init(void)
samsung->handle_backlight = true;
samsung->quirks = quirks;
-#ifdef CONFIG_ACPI
- if (samsung->quirks->broken_acpi_video)
- acpi_video_set_dmi_backlight_type(acpi_backlight_vendor);
- if (samsung->quirks->use_native_backlight)
- acpi_video_set_dmi_backlight_type(acpi_backlight_native);
-
if (acpi_video_get_backlight_type() != acpi_backlight_vendor)
samsung->handle_backlight = false;
-#endif
ret = samsung_platform_init(samsung);
if (ret)
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 25/29] ACPI: video: Remove acpi_video_set_dmi_backlight_type()
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (23 preceding siblings ...)
2022-07-12 19:39 ` [PATCH v2 24/29] platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native] " Hans de Goede
@ 2022-07-12 19:39 ` Hans de Goede
2022-07-12 19:39 ` [PATCH v2 26/29] ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk Hans de Goede
` (5 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:39 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
acpi_video_set_dmi_backlight_type() is troublesome because it may end
up getting called after other backlight drivers have already called
acpi_video_get_backlight_type() resulting in the other drivers
already being registered even though they should not.
In case of the acpi_video backlight, acpi_video_set_dmi_backlight_type()
actually calls acpi_video_unregister_backlight() since that is often
probed earlier, leading to userspace seeing the acpi_video0 class
device being briefly available, leading to races in userspace where
udev probe-rules try to access the device and it is already gone.
All callers have been fixed to no longer call it, so remove
acpi_video_set_dmi_backlight_type() now.
This means we now also no longer need acpi_video_unregister_backlight()
for the remove acpi_video backlight after it was wrongly registered hack,
so remove that too.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/acpi_video.c | 10 ----------
drivers/acpi/video_detect.c | 16 ----------------
include/acpi/video.h | 4 ----
3 files changed, 30 deletions(-)
diff --git a/drivers/acpi/acpi_video.c b/drivers/acpi/acpi_video.c
index 4fc2a8100865..dc3c037d6313 100644
--- a/drivers/acpi/acpi_video.c
+++ b/drivers/acpi/acpi_video.c
@@ -2297,16 +2297,6 @@ void acpi_video_register_backlight(void)
}
EXPORT_SYMBOL(acpi_video_register_backlight);
-void acpi_video_unregister_backlight(void)
-{
- struct acpi_video_bus *video;
-
- mutex_lock(&video_list_lock);
- list_for_each_entry(video, &video_bus_head, entry)
- acpi_video_bus_unregister_backlight(video);
- mutex_unlock(&video_list_lock);
-}
-
bool acpi_video_handles_brightness_key_presses(void)
{
return has_backlight &&
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 84dce2c113ef..351bd6335d7a 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -37,8 +37,6 @@
#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;
@@ -792,17 +790,3 @@ bool acpi_video_backlight_use_native(void)
return __acpi_video_get_backlight_type(true) == acpi_backlight_native;
}
EXPORT_SYMBOL(acpi_video_backlight_use_native);
-
-/*
- * 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);
diff --git a/include/acpi/video.h b/include/acpi/video.h
index dbd48cb8bd23..a275c35e5249 100644
--- a/include/acpi/video.h
+++ b/include/acpi/video.h
@@ -60,7 +60,6 @@ extern int acpi_video_get_edid(struct acpi_device *device, int type,
int device_id, void **edid);
extern enum acpi_backlight_type acpi_video_get_backlight_type(void);
extern bool acpi_video_backlight_use_native(void);
-extern void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type);
/*
* Note: The value returned by acpi_video_handles_brightness_key_presses()
* may change over time and should not be cached.
@@ -86,9 +85,6 @@ static inline bool acpi_video_backlight_use_native(void)
{
return true;
}
-static inline void acpi_video_set_dmi_backlight_type(enum acpi_backlight_type type)
-{
-}
static inline bool acpi_video_handles_brightness_key_presses(void)
{
return false;
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 26/29] ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (24 preceding siblings ...)
2022-07-12 19:39 ` [PATCH v2 25/29] ACPI: video: Remove acpi_video_set_dmi_backlight_type() Hans de Goede
@ 2022-07-12 19:39 ` Hans de Goede
2022-07-12 19:39 ` [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native quirks Hans de Goede
` (4 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:39 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
acpi_backlight=native is the default for the "Samsung X360", but as
the comment explains the quirk was still necessary because even
briefly registering the acpi_video0 backlight; and then unregistering
it once the native driver showed up, was leading to issues.
After the "ACPI: video: Make backlight class device registration
a separate step" patch from earlier in this patch-series, we no
longer briefly register the acpi_video0 backlight on systems where
the native driver should be used.
So this is no longer an issue an the quirk is no longer needed.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/video_detect.c | 15 ---------------
1 file changed, 15 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 351bd6335d7a..2a4d376a703e 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -130,21 +130,6 @@ static int video_detect_force_none(const struct dmi_system_id *d)
}
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"),
- },
- },
{
/* https://bugzilla.redhat.com/show_bug.cgi?id=1128309 */
.callback = video_detect_force_vendor,
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native quirks
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (25 preceding siblings ...)
2022-07-12 19:39 ` [PATCH v2 26/29] ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk Hans de Goede
@ 2022-07-12 19:39 ` Hans de Goede
2022-07-13 17:07 ` Werner Sembach
2022-07-12 19:39 ` [PATCH v2 28/29] ACPI: video: Fix indentation of video_detect_dmi_table[] entries Hans de Goede
` (3 subsequent siblings)
30 siblings, 1 reply; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:39 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86,
Werner Sembach
acpi_backlight=native is the default for these, but as the comment
explains the quirk was still necessary because even briefly registering
the acpi_video0 backlight; and then unregistering it once the native
driver showed up, was leading to issues.
After the "ACPI: video: Make backlight class device registration
a separate step" patch from earlier in this patch-series, we no
longer briefly register the acpi_video0 backlight on systems where
the native driver should be used.
So this is no longer an issue an the quirks are no longer needed.
Cc: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/video_detect.c | 75 -------------------------------------
1 file changed, 75 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 2a4d376a703e..4b9395d1bda7 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -599,81 +599,6 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
DMI_MATCH(DMI_BOARD_NAME, "N250P"),
},
},
- /*
- * 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_SYS_VENDOR, "TUXEDO"),
- DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "Clevo NL5xRU",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"),
- DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "Clevo NL5xRU",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
- 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_SYS_VENDOR, "TUXEDO"),
- DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "Clevo NL5xNU",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"),
- DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
- },
- },
- {
- .callback = video_detect_force_native,
- .ident = "Clevo NL5xNU",
- .matches = {
- DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
- DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
- },
- },
/*
* Desktops which falsely report a backlight and which our heuristics
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native quirks
2022-07-12 19:39 ` [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native quirks Hans de Goede
@ 2022-07-13 17:07 ` Werner Sembach
2022-07-13 17:21 ` Limonciello, Mario
0 siblings, 1 reply; 58+ messages in thread
From: Werner Sembach @ 2022-07-13 17:07 UTC (permalink / raw)
To: Hans de Goede, Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher,
Christian König, Pan, Xinhui, Rafael J . Wysocki,
Mika Westerberg, Lukas Wunner, Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Hi,
On 7/12/22 21:39, Hans de Goede wrote:
> acpi_backlight=native is the default for these, but as the comment
> explains the quirk was still necessary because even briefly registering
> the acpi_video0 backlight; and then unregistering it once the native
> driver showed up, was leading to issues.
>
> After the "ACPI: video: Make backlight class device registration
> a separate step" patch from earlier in this patch-series, we no
> longer briefly register the acpi_video0 backlight on systems where
> the native driver should be used.
>
> So this is no longer an issue an the quirks are no longer needed.
>
> Cc: Werner Sembach <wse@tuxedocomputers.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested and can confirm: The quirks are no longer needed with this Patchset.
Tested-by: Werner Sembach <wse@tuxedocomputers.com>
Kind Regards,
Werner Sembach
> ---
> drivers/acpi/video_detect.c | 75 -------------------------------------
> 1 file changed, 75 deletions(-)
>
> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
> index 2a4d376a703e..4b9395d1bda7 100644
> --- a/drivers/acpi/video_detect.c
> +++ b/drivers/acpi/video_detect.c
> @@ -599,81 +599,6 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
> DMI_MATCH(DMI_BOARD_NAME, "N250P"),
> },
> },
> - /*
> - * 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_SYS_VENDOR, "TUXEDO"),
> - DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
> - },
> - },
> - {
> - .callback = video_detect_force_native,
> - .ident = "Clevo NL5xRU",
> - .matches = {
> - DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"),
> - DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
> - },
> - },
> - {
> - .callback = video_detect_force_native,
> - .ident = "Clevo NL5xRU",
> - .matches = {
> - DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
> - 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_SYS_VENDOR, "TUXEDO"),
> - DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
> - },
> - },
> - {
> - .callback = video_detect_force_native,
> - .ident = "Clevo NL5xNU",
> - .matches = {
> - DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"),
> - DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
> - },
> - },
> - {
> - .callback = video_detect_force_native,
> - .ident = "Clevo NL5xNU",
> - .matches = {
> - DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
> - DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
> - },
> - },
>
> /*
> * Desktops which falsely report a backlight and which our heuristics
^ permalink raw reply [flat|nested] 58+ messages in thread* RE: [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native quirks
2022-07-13 17:07 ` Werner Sembach
@ 2022-07-13 17:21 ` Limonciello, Mario
2022-07-14 19:43 ` Hans de Goede
0 siblings, 1 reply; 58+ messages in thread
From: Limonciello, Mario @ 2022-07-13 17:21 UTC (permalink / raw)
To: Werner Sembach, Hans de Goede, Ben Skeggs, Karol Herbst, Lyude,
Daniel Dadap, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Deucher, Alexander, Koenig, Christian, Pan, Pan,
Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
[Public]
> -----Original Message-----
> From: Werner Sembach <wse@tuxedocomputers.com>
> Sent: Wednesday, July 13, 2022 12:08
> To: Hans de Goede <hdegoede@redhat.com>; Ben Skeggs
> <bskeggs@redhat.com>; Karol Herbst <kherbst@redhat.com>; Lyude
> <lyude@redhat.com>; Daniel Dadap <ddadap@nvidia.com>; Maarten
> Lankhorst <maarten.lankhorst@linux.intel.com>; Maxime Ripard
> <mripard@kernel.org>; Thomas Zimmermann <tzimmermann@suse.de>;
> Jani Nikula <jani.nikula@linux.intel.com>; Joonas Lahtinen
> <joonas.lahtinen@linux.intel.com>; Rodrigo Vivi <rodrigo.vivi@intel.com>;
> Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>; Deucher, Alexander
> <Alexander.Deucher@amd.com>; Koenig, Christian
> <Christian.Koenig@amd.com>; Pan@vger.kernel.org; Pan, Xinhui
> <Xinhui.Pan@amd.com>; Rafael J . Wysocki <rafael@kernel.org>; Mika
> Westerberg <mika.westerberg@linux.intel.com>; Lukas Wunner
> <lukas@wunner.de>; Mark Gross <markgross@kernel.org>; Andy
> Shevchenko <andy@kernel.org>
> Cc: nouveau@lists.freedesktop.org; Daniel Vetter <daniel@ffwll.ch>; David
> Airlie <airlied@linux.ie>; intel-gfx <intel-gfx@lists.freedesktop.org>; dri-
> devel@lists.freedesktop.org; amd-gfx@lists.freedesktop.org; Len Brown
> <lenb@kernel.org>; linux-acpi@vger.kernel.org; platform-driver-
> x86@vger.kernel.org
> Subject: Re: [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and
> NL5xNU acpi_backlight=native quirks
>
> Hi,
>
> On 7/12/22 21:39, Hans de Goede wrote:
> > acpi_backlight=native is the default for these, but as the comment
> > explains the quirk was still necessary because even briefly registering
> > the acpi_video0 backlight; and then unregistering it once the native
> > driver showed up, was leading to issues.
> >
> > After the "ACPI: video: Make backlight class device registration
> > a separate step" patch from earlier in this patch-series, we no
> > longer briefly register the acpi_video0 backlight on systems where
> > the native driver should be used.
> >
> > So this is no longer an issue an the quirks are no longer needed.
> >
> > Cc: Werner Sembach <wse@tuxedocomputers.com>
> > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> Tested and can confirm: The quirks are no longer needed with this Patchset.
>
> Tested-by: Werner Sembach <wse@tuxedocomputers.com>
Probably should include this link tag in this commit too then as it fixes
the Tong Fang systems too.
Link: https://bugzilla.kernel.org/show_bug.cgi?id=215683
>
> Kind Regards,
>
> Werner Sembach
>
> > ---
> > drivers/acpi/video_detect.c | 75 -------------------------------------
> > 1 file changed, 75 deletions(-)
> >
> > diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
> > index 2a4d376a703e..4b9395d1bda7 100644
> > --- a/drivers/acpi/video_detect.c
> > +++ b/drivers/acpi/video_detect.c
> > @@ -599,81 +599,6 @@ static const struct dmi_system_id
> video_detect_dmi_table[] = {
> > DMI_MATCH(DMI_BOARD_NAME, "N250P"),
> > },
> > },
> > - /*
> > - * 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_SYS_VENDOR, "TUXEDO"),
> > - DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
> > - },
> > - },
> > - {
> > - .callback = video_detect_force_native,
> > - .ident = "Clevo NL5xRU",
> > - .matches = {
> > - DMI_MATCH(DMI_SYS_VENDOR,
> "SchenkerTechnologiesGmbH"),
> > - DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
> > - },
> > - },
> > - {
> > - .callback = video_detect_force_native,
> > - .ident = "Clevo NL5xRU",
> > - .matches = {
> > - DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
> > - 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_SYS_VENDOR, "TUXEDO"),
> > - DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
> > - },
> > - },
> > - {
> > - .callback = video_detect_force_native,
> > - .ident = "Clevo NL5xNU",
> > - .matches = {
> > - DMI_MATCH(DMI_SYS_VENDOR,
> "SchenkerTechnologiesGmbH"),
> > - DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
> > - },
> > - },
> > - {
> > - .callback = video_detect_force_native,
> > - .ident = "Clevo NL5xNU",
> > - .matches = {
> > - DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
> > - DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
> > - },
> > - },
> >
> > /*
> > * Desktops which falsely report a backlight and which our heuristics
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native quirks
2022-07-13 17:21 ` Limonciello, Mario
@ 2022-07-14 19:43 ` Hans de Goede
0 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-14 19:43 UTC (permalink / raw)
To: Limonciello, Mario, Werner Sembach, Ben Skeggs, Karol Herbst,
Lyude, Daniel Dadap, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Jani Nikula, Joonas Lahtinen, Rodrigo Vivi,
Tvrtko Ursulin, Deucher, Alexander, Koenig, Christian, Pan, Pan,
Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Hi,
On 7/13/22 19:21, Limonciello, Mario wrote:
> [Public]
>
>
>
>> -----Original Message-----
>> From: Werner Sembach <wse@tuxedocomputers.com>
>> Sent: Wednesday, July 13, 2022 12:08
>> To: Hans de Goede <hdegoede@redhat.com>; Ben Skeggs
>> <bskeggs@redhat.com>; Karol Herbst <kherbst@redhat.com>; Lyude
>> <lyude@redhat.com>; Daniel Dadap <ddadap@nvidia.com>; Maarten
>> Lankhorst <maarten.lankhorst@linux.intel.com>; Maxime Ripard
>> <mripard@kernel.org>; Thomas Zimmermann <tzimmermann@suse.de>;
>> Jani Nikula <jani.nikula@linux.intel.com>; Joonas Lahtinen
>> <joonas.lahtinen@linux.intel.com>; Rodrigo Vivi <rodrigo.vivi@intel.com>;
>> Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>; Deucher, Alexander
>> <Alexander.Deucher@amd.com>; Koenig, Christian
>> <Christian.Koenig@amd.com>; Pan@vger.kernel.org; Pan, Xinhui
>> <Xinhui.Pan@amd.com>; Rafael J . Wysocki <rafael@kernel.org>; Mika
>> Westerberg <mika.westerberg@linux.intel.com>; Lukas Wunner
>> <lukas@wunner.de>; Mark Gross <markgross@kernel.org>; Andy
>> Shevchenko <andy@kernel.org>
>> Cc: nouveau@lists.freedesktop.org; Daniel Vetter <daniel@ffwll.ch>; David
>> Airlie <airlied@linux.ie>; intel-gfx <intel-gfx@lists.freedesktop.org>; dri-
>> devel@lists.freedesktop.org; amd-gfx@lists.freedesktop.org; Len Brown
>> <lenb@kernel.org>; linux-acpi@vger.kernel.org; platform-driver-
>> x86@vger.kernel.org
>> Subject: Re: [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and
>> NL5xNU acpi_backlight=native quirks
>>
>> Hi,
>>
>> On 7/12/22 21:39, Hans de Goede wrote:
>>> acpi_backlight=native is the default for these, but as the comment
>>> explains the quirk was still necessary because even briefly registering
>>> the acpi_video0 backlight; and then unregistering it once the native
>>> driver showed up, was leading to issues.
>>>
>>> After the "ACPI: video: Make backlight class device registration
>>> a separate step" patch from earlier in this patch-series, we no
>>> longer briefly register the acpi_video0 backlight on systems where
>>> the native driver should be used.
>>>
>>> So this is no longer an issue an the quirks are no longer needed.
>>>
>>> Cc: Werner Sembach <wse@tuxedocomputers.com>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>
>> Tested and can confirm: The quirks are no longer needed with this Patchset.
>>
>> Tested-by: Werner Sembach <wse@tuxedocomputers.com>
>
> Probably should include this link tag in this commit too then as it fixes
> the Tong Fang systems too.
>
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=215683
Good point, I've added this to the version in my personal tree.
Regards,
Hans
>
>>
>> Kind Regards,
>>
>> Werner Sembach
>>
>>> ---
>>> drivers/acpi/video_detect.c | 75 -------------------------------------
>>> 1 file changed, 75 deletions(-)
>>>
>>> diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
>>> index 2a4d376a703e..4b9395d1bda7 100644
>>> --- a/drivers/acpi/video_detect.c
>>> +++ b/drivers/acpi/video_detect.c
>>> @@ -599,81 +599,6 @@ static const struct dmi_system_id
>> video_detect_dmi_table[] = {
>>> DMI_MATCH(DMI_BOARD_NAME, "N250P"),
>>> },
>>> },
>>> - /*
>>> - * 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_SYS_VENDOR, "TUXEDO"),
>>> - DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
>>> - },
>>> - },
>>> - {
>>> - .callback = video_detect_force_native,
>>> - .ident = "Clevo NL5xRU",
>>> - .matches = {
>>> - DMI_MATCH(DMI_SYS_VENDOR,
>> "SchenkerTechnologiesGmbH"),
>>> - DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
>>> - },
>>> - },
>>> - {
>>> - .callback = video_detect_force_native,
>>> - .ident = "Clevo NL5xRU",
>>> - .matches = {
>>> - DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
>>> - 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_SYS_VENDOR, "TUXEDO"),
>>> - DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
>>> - },
>>> - },
>>> - {
>>> - .callback = video_detect_force_native,
>>> - .ident = "Clevo NL5xNU",
>>> - .matches = {
>>> - DMI_MATCH(DMI_SYS_VENDOR,
>> "SchenkerTechnologiesGmbH"),
>>> - DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
>>> - },
>>> - },
>>> - {
>>> - .callback = video_detect_force_native,
>>> - .ident = "Clevo NL5xNU",
>>> - .matches = {
>>> - DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
>>> - DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
>>> - },
>>> - },
>>>
>>> /*
>>> * Desktops which falsely report a backlight and which our heuristics
^ permalink raw reply [flat|nested] 58+ messages in thread
* [PATCH v2 28/29] ACPI: video: Fix indentation of video_detect_dmi_table[] entries
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (26 preceding siblings ...)
2022-07-12 19:39 ` [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native quirks Hans de Goede
@ 2022-07-12 19:39 ` Hans de Goede
2022-07-12 19:39 ` [PATCH v2 29/29] drm/todo: Add entry about dealing with brightness control on devices with > 1 panel Hans de Goede
` (2 subsequent siblings)
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:39 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
The video_detect_dmi_table[] uses an unusual indentation for
before the ".name = ..." named struct initializers.
Instead of being indented with an extra tab compared to
the previous line's '{' these are indented to with only
a single space to allow for long DMI_MATCH() lines without
wrapping.
But over time some entries did not event have the single space
indent in front of the ".name = ..." lines.
Make things consistent by using a single space indent for these
lines everywhere.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
drivers/acpi/video_detect.c | 48 ++++++++++++++++++-------------------
1 file changed, 24 insertions(+), 24 deletions(-)
diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 4b9395d1bda7..60d6fb056cac 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -140,17 +140,17 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
},
},
{
- .callback = video_detect_force_vendor,
- /* Asus UL30VT */
- .matches = {
+ .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 = {
+ .callback = video_detect_force_vendor,
+ /* Asus UL30A */
+ .matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer Inc."),
DMI_MATCH(DMI_PRODUCT_NAME, "UL30A"),
},
@@ -196,9 +196,9 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
},
},
{
- .callback = video_detect_force_vendor,
- /* GIGABYTE GB-BXBT-2807 */
- .matches = {
+ .callback = video_detect_force_vendor,
+ /* GIGABYTE GB-BXBT-2807 */
+ .matches = {
DMI_MATCH(DMI_SYS_VENDOR, "GIGABYTE"),
DMI_MATCH(DMI_PRODUCT_NAME, "GB-BXBT-2807"),
},
@@ -231,17 +231,17 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
},
},
{
- .callback = video_detect_force_vendor,
- /* Sony VPCEH3U1E */
- .matches = {
+ .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_vendor,
- /* Xiaomi Mi Pad 2 */
- .matches = {
+ .callback = video_detect_force_vendor,
+ /* Xiaomi Mi Pad 2 */
+ .matches = {
DMI_MATCH(DMI_SYS_VENDOR, "Xiaomi Inc"),
DMI_MATCH(DMI_PRODUCT_NAME, "Mipad2"),
},
@@ -541,25 +541,25 @@ static const struct dmi_system_id video_detect_dmi_table[] = {
},
},
{
- .callback = video_detect_force_native,
- /* ASUSTeK COMPUTER INC. GA401 */
- .matches = {
+ .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 = {
+ .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 = {
+ .callback = video_detect_force_native,
+ /* ASUSTeK COMPUTER INC. GA503 */
+ .matches = {
DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
DMI_MATCH(DMI_PRODUCT_NAME, "GA503"),
},
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* [PATCH v2 29/29] drm/todo: Add entry about dealing with brightness control on devices with > 1 panel
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (27 preceding siblings ...)
2022-07-12 19:39 ` [PATCH v2 28/29] ACPI: video: Fix indentation of video_detect_dmi_table[] entries Hans de Goede
@ 2022-07-12 19:39 ` Hans de Goede
2022-07-14 18:42 ` [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Rafael J. Wysocki
2022-07-14 21:49 ` Lyude Paul
30 siblings, 0 replies; 58+ messages in thread
From: Hans de Goede @ 2022-07-12 19:39 UTC (permalink / raw)
To: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Pan, Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko
Cc: Hans de Goede, nouveau, Daniel Vetter, David Airlie, intel-gfx,
dri-devel, amd-gfx, Len Brown, linux-acpi, platform-driver-x86
Add an entry summarizing the discussion about dealing with brightness
control on devices with more then 1 internal panel.
The original discussion can be found here:
https://lore.kernel.org/dri-devel/20220517152331.16217-1-hdegoede@redhat.com/
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Documentation/gpu/todo.rst | 68 ++++++++++++++++++++++++++++++++++++++
1 file changed, 68 insertions(+)
diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
index 10bfb50908d1..8548bab88062 100644
--- a/Documentation/gpu/todo.rst
+++ b/Documentation/gpu/todo.rst
@@ -704,6 +704,74 @@ Contact: Sam Ravnborg
Level: Advanced
+Brightness handling on devices with multiple internal panels
+============================================================
+
+On x86/ACPI devices there can be multiple backlight firmware interfaces:
+(ACPI) video, vendor specific and others. As well as direct/native (PWM)
+register programming by the KMS driver.
+
+To deal with this backlight drivers used on x86/ACPI call
+acpi_video_get_backlight_type() which has heuristics (+quirks) to select
+which backlight interface to use; and backlight drivers which do not match
+the returned type will not register themselves, so that only one backlight
+device gets registered (in a single GPU setup, see below).
+
+At the moment this more or less assumes that there will only
+be 1 (internal) panel on a system.
+
+On systems with 2 panels this may be a problem, depending on
+what interface acpi_video_get_backlight_type() selects:
+
+1. native: in this case the KMS driver is expected to know which backlight
+ device belongs to which output so everything should just work.
+2. video: this does support controlling multiple backlights, but some work
+ will need to be done to get the output <-> backlight device mapping
+
+The above assumes both panels will require the same backlight interface type.
+Things will break on systems with multiple panels where the 2 panels need
+a different type of control. E.g. one panel needs ACPI video backlight control,
+where as the other is using native backlight control. Currently in this case
+only one of the 2 required backlight devices will get registered, based on
+the acpi_video_get_backlight_type() return value.
+
+If this (theoretical) case ever shows up, then supporting this will need some
+work. A possible solution here would be to pass a device and connector-name
+to acpi_video_get_backlight_type() so that it can deal with this.
+
+Note in a way we already have a case where userspace sees 2 panels,
+in dual GPU laptop setups with a mux. On those systems we may see
+either 2 native backlight devices; or 2 native backlight devices.
+
+Userspace already has code to deal with this by detecting if the related
+panel is active (iow which way the mux between the GPU and the panels
+points) and then uses that backlight device. Userspace here very much
+assumes a single panel though. It picks only 1 of the 2 backlight devices
+and then only uses that one.
+
+Note that all userspace code (that I know off) is currently hardcoded
+to assume a single panel.
+
+Before the recent changes to not register multiple (e.g. video + native)
+/sys/class/backlight devices for a single panel (on a single GPU laptop),
+userspace would see multiple backlight devices all controlling the same
+backlight.
+
+To deal with this userspace had to always picks one preferred device under
+/sys/class/backlight and will ignore the others. So to support brightness
+control on multiple panels userspace will need to be updated too.
+
+There are plans to allow brightness control through the KMS API by adding
+a "display brightness" property to drm_connector objects for panels. This
+solves a number of issues with the /sys/class/backlight API, including not
+being able to map a sysfs backlight device to a specific connector. Any
+userspace changes to add support for brightness control on devices with
+multiple panels really should build on top of this new KMS property.
+
+Contact: Hans de Goede
+
+Level: Advanced
+
Outside DRM
===========
--
2.36.0
^ permalink raw reply related [flat|nested] 58+ messages in thread* Re: [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (28 preceding siblings ...)
2022-07-12 19:39 ` [PATCH v2 29/29] drm/todo: Add entry about dealing with brightness control on devices with > 1 panel Hans de Goede
@ 2022-07-14 18:42 ` Rafael J. Wysocki
2022-07-14 21:49 ` Lyude Paul
30 siblings, 0 replies; 58+ messages in thread
From: Rafael J. Wysocki @ 2022-07-14 18:42 UTC (permalink / raw)
To: Hans de Goede
Cc: Ben Skeggs, Karol Herbst, Lyude, Daniel Dadap, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Jani Nikula, Joonas Lahtinen,
Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher, Christian König,
Xinhui, Rafael J . Wysocki, Mika Westerberg, Lukas Wunner,
Mark Gross, Andy Shevchenko, nouveau, Daniel Vetter,
David Airlie, intel-gfx, dri-devel, amd-gfx list, Len Brown,
ACPI Devel Maling List, Platform Driver
On Tue, Jul 12, 2022 at 9:39 PM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi All,
>
> As mentioned in my RFC titled "drm/kms: control display brightness through
> drm_connector properties":
> https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fee2d@redhat.com/
>
> The first step towards this is to deal with some existing technical debt
> in backlight handling on x86/ACPI boards, specifically we need to stop
> registering multiple /sys/class/backlight devs for a single display.
>
> This series implements my RFC describing my plan for these cleanups:
> https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343158@redhat.com/
>
> This new version addresses the few small remarks made on version 1 (mainly
> changing patch 1/29) and more importantly this finishes the refactoring by
> else addressing all the bits from the "Other issues" section of
> the refactor RFC (resulting in patches 15-29 which are new in v2).
>
> Please review and test! I hope to be able to make an immutable branch
> based on 5.20-rc1 + this series available for merging into the various
> touched subsystems once 5.20-rc2 is out.
Please feel free to add
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
to all of the ACPI video patches in this series.
Thanks!
> Hans de Goede (29):
> ACPI: video: Add acpi_video_backlight_use_native() helper
> drm/i915: Don't register backlight when another backlight should be
> used
> drm/amdgpu: Don't register backlight when another backlight should be
> used
> drm/radeon: Don't register backlight when another backlight should be
> used
> drm/nouveau: Don't register backlight when another backlight should be
> used
> ACPI: video: Drop backlight_device_get_by_type() call from
> acpi_video_get_backlight_type()
> ACPI: video: Remove acpi_video_bus from list before tearing it down
> ACPI: video: Simplify acpi_video_unregister_backlight()
> ACPI: video: Make backlight class device registration a separate step
> ACPI: video: Remove code to unregister acpi_video backlight when a
> native backlight registers
> drm/i915: Call acpi_video_register_backlight() (v2)
> drm/nouveau: Register ACPI video backlight when nv_backlight
> registration fails
> drm/amdgpu: Register ACPI video backlight when skipping amdgpu
> backlight registration
> drm/radeon: Register ACPI video backlight when skipping radeon
> backlight registration
> ACPI: video: Refactor acpi_video_get_backlight_type() a bit
> ACPI: video: Add Nvidia WMI EC brightness control detection
> ACPI: video: Add Apple GMUX brightness control detection
> platform/x86: apple-gmux: Stop calling acpi/video.h functions
> platform/x86: toshiba_acpi: Stop using
> acpi_video_set_dmi_backlight_type()
> platform/x86: acer-wmi: Move backlight DMI quirks to
> acpi/video_detect.c
> platform/x86: asus-wmi: Drop DMI chassis-type check from backlight
> handling
> platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI
> video_detect.c
> platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI
> video_detect.c
> platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native]
> quirks to ACPI video_detect.c
> ACPI: video: Remove acpi_video_set_dmi_backlight_type()
> ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk
> ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native
> quirks
> ACPI: video: Fix indentation of video_detect_dmi_table[] entries
> drm/todo: Add entry about dealing with brightness control on devices
> with > 1 panel
>
> Documentation/gpu/todo.rst | 68 +++
> drivers/acpi/Kconfig | 1 +
> drivers/acpi/acpi_video.c | 59 ++-
> drivers/acpi/video_detect.c | 415 +++++++++++-------
> drivers/gpu/drm/Kconfig | 12 +
> .../gpu/drm/amd/amdgpu/atombios_encoders.c | 14 +-
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +
> drivers/gpu/drm/gma500/Kconfig | 2 +
> drivers/gpu/drm/i915/Kconfig | 2 +
> .../gpu/drm/i915/display/intel_backlight.c | 7 +
> drivers/gpu/drm/i915/display/intel_display.c | 8 +
> drivers/gpu/drm/i915/display/intel_panel.c | 3 +
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 14 +
> drivers/gpu/drm/radeon/atombios_encoders.c | 7 +
> drivers/gpu/drm/radeon/radeon_encoders.c | 11 +-
> .../gpu/drm/radeon/radeon_legacy_encoders.c | 7 +
> drivers/platform/x86/acer-wmi.c | 66 ---
> drivers/platform/x86/apple-gmux.c | 3 -
> drivers/platform/x86/asus-nb-wmi.c | 21 -
> drivers/platform/x86/asus-wmi.c | 13 -
> drivers/platform/x86/asus-wmi.h | 2 -
> drivers/platform/x86/eeepc-wmi.c | 25 +-
> drivers/platform/x86/samsung-laptop.c | 87 ----
> drivers/platform/x86/toshiba_acpi.c | 16 -
> include/acpi/video.h | 9 +-
> 26 files changed, 468 insertions(+), 415 deletions(-)
>
> --
> 2.36.0
>
^ permalink raw reply [flat|nested] 58+ messages in thread* Re: [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display
2022-07-12 19:38 [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Hans de Goede
` (29 preceding siblings ...)
2022-07-14 18:42 ` [PATCH v2 00/29] drm/kms: Stop registering multiple /sys/class/backlight devs for a single display Rafael J. Wysocki
@ 2022-07-14 21:49 ` Lyude Paul
30 siblings, 0 replies; 58+ messages in thread
From: Lyude Paul @ 2022-07-14 21:49 UTC (permalink / raw)
To: Hans de Goede, Ben Skeggs, Karol Herbst, Daniel Dadap,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Jani Nikula,
Joonas Lahtinen, Rodrigo Vivi, Tvrtko Ursulin, Alex Deucher,
Christian König, Pan, Xinhui, Xinhui, Rafael J . Wysocki,
Mika Westerberg, Lukas Wunner, Mark Gross, Andy Shevchenko
Cc: nouveau, Daniel Vetter, David Airlie, intel-gfx, dri-devel,
amd-gfx, Len Brown, linux-acpi, platform-driver-x86
I assume you're probably good on review for the non-nouveau stuff, but if you
end up needing any help with that feel free to poke me!
On Tue, 2022-07-12 at 21:38 +0200, Hans de Goede wrote:
> Hi All,
>
> As mentioned in my RFC titled "drm/kms: control display brightness through
> drm_connector properties":
> https://lore.kernel.org/dri-devel/0d188965-d809-81b5-74ce-7d30c49fee2d@redhat.com/
>
> The first step towards this is to deal with some existing technical debt
> in backlight handling on x86/ACPI boards, specifically we need to stop
> registering multiple /sys/class/backlight devs for a single display.
>
> This series implements my RFC describing my plan for these cleanups:
> https://lore.kernel.org/dri-devel/98519ba0-7f18-201a-ea34-652f50343158@redhat.com/
>
> This new version addresses the few small remarks made on version 1 (mainly
> changing patch 1/29) and more importantly this finishes the refactoring by
> else addressing all the bits from the "Other issues" section of
> the refactor RFC (resulting in patches 15-29 which are new in v2).
>
> Please review and test! I hope to be able to make an immutable branch
> based on 5.20-rc1 + this series available for merging into the various
> touched subsystems once 5.20-rc2 is out.
>
> Regards,
>
> Hans
>
>
> Hans de Goede (29):
> ACPI: video: Add acpi_video_backlight_use_native() helper
> drm/i915: Don't register backlight when another backlight should be
> used
> drm/amdgpu: Don't register backlight when another backlight should be
> used
> drm/radeon: Don't register backlight when another backlight should be
> used
> drm/nouveau: Don't register backlight when another backlight should be
> used
> ACPI: video: Drop backlight_device_get_by_type() call from
> acpi_video_get_backlight_type()
> ACPI: video: Remove acpi_video_bus from list before tearing it down
> ACPI: video: Simplify acpi_video_unregister_backlight()
> ACPI: video: Make backlight class device registration a separate step
> ACPI: video: Remove code to unregister acpi_video backlight when a
> native backlight registers
> drm/i915: Call acpi_video_register_backlight() (v2)
> drm/nouveau: Register ACPI video backlight when nv_backlight
> registration fails
> drm/amdgpu: Register ACPI video backlight when skipping amdgpu
> backlight registration
> drm/radeon: Register ACPI video backlight when skipping radeon
> backlight registration
> ACPI: video: Refactor acpi_video_get_backlight_type() a bit
> ACPI: video: Add Nvidia WMI EC brightness control detection
> ACPI: video: Add Apple GMUX brightness control detection
> platform/x86: apple-gmux: Stop calling acpi/video.h functions
> platform/x86: toshiba_acpi: Stop using
> acpi_video_set_dmi_backlight_type()
> platform/x86: acer-wmi: Move backlight DMI quirks to
> acpi/video_detect.c
> platform/x86: asus-wmi: Drop DMI chassis-type check from backlight
> handling
> platform/x86: asus-wmi: Move acpi_backlight=vendor quirks to ACPI
> video_detect.c
> platform/x86: asus-wmi: Move acpi_backlight=native quirks to ACPI
> video_detect.c
> platform/x86: samsung-laptop: Move acpi_backlight=[vendor|native]
> quirks to ACPI video_detect.c
> ACPI: video: Remove acpi_video_set_dmi_backlight_type()
> ACPI: video: Drop "Samsung X360" acpi_backlight=native quirk
> ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native
> quirks
> ACPI: video: Fix indentation of video_detect_dmi_table[] entries
> drm/todo: Add entry about dealing with brightness control on devices
> with > 1 panel
>
> Documentation/gpu/todo.rst | 68 +++
> drivers/acpi/Kconfig | 1 +
> drivers/acpi/acpi_video.c | 59 ++-
> drivers/acpi/video_detect.c | 415 +++++++++++-------
> drivers/gpu/drm/Kconfig | 12 +
> .../gpu/drm/amd/amdgpu/atombios_encoders.c | 14 +-
> .../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +
> drivers/gpu/drm/gma500/Kconfig | 2 +
> drivers/gpu/drm/i915/Kconfig | 2 +
> .../gpu/drm/i915/display/intel_backlight.c | 7 +
> drivers/gpu/drm/i915/display/intel_display.c | 8 +
> drivers/gpu/drm/i915/display/intel_panel.c | 3 +
> drivers/gpu/drm/i915/i915_drv.h | 2 +
> drivers/gpu/drm/nouveau/nouveau_backlight.c | 14 +
> drivers/gpu/drm/radeon/atombios_encoders.c | 7 +
> drivers/gpu/drm/radeon/radeon_encoders.c | 11 +-
> .../gpu/drm/radeon/radeon_legacy_encoders.c | 7 +
> drivers/platform/x86/acer-wmi.c | 66 ---
> drivers/platform/x86/apple-gmux.c | 3 -
> drivers/platform/x86/asus-nb-wmi.c | 21 -
> drivers/platform/x86/asus-wmi.c | 13 -
> drivers/platform/x86/asus-wmi.h | 2 -
> drivers/platform/x86/eeepc-wmi.c | 25 +-
> drivers/platform/x86/samsung-laptop.c | 87 ----
> drivers/platform/x86/toshiba_acpi.c | 16 -
> include/acpi/video.h | 9 +-
> 26 files changed, 468 insertions(+), 415 deletions(-)
>
--
Cheers,
Lyude Paul (she/her)
Software Engineer at Red Hat
^ permalink raw reply [flat|nested] 58+ messages in thread