| Message ID | 20220517152331.16217-12-hdegoede@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | [01/14] ACPI: video: Add a native function parameter to acpi_video_get_backlight_type() | expand |
diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 85fbf59e0f58..500659c51e8d 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -10672,6 +10672,7 @@ void intel_display_driver_register(struct drm_i915_private *i915) /* Must be done after probing outputs */ intel_opregion_register(i915); acpi_video_register(); + acpi_video_register_backlight(); intel_audio_init(i915);
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. Signed-off-by: Hans de Goede <hdegoede@redhat.com> --- drivers/gpu/drm/i915/display/intel_display.c | 1 + 1 file changed, 1 insertion(+)