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. Acked-by: Rafael J. Wysocki <rafael.j.wysocki@xxxxxxxxx> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx> --- 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 67a0211c07b4..af2833b57b8b 100644 --- a/drivers/acpi/video_detect.c +++ b/drivers/acpi/video_detect.c @@ -132,21 +132,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.37.2