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@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 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
