acpi: blacklist win8 OSI for ASUS Zenbok Prime UX31A

Since v3.7 the acpi backlight driver doesn't work at all on this machine because presumably the ACPI code contains stub code when Windows 8 OSI is reported.

The commit ea45ea7 (in v3.11-rc2) tried to fix this problem by using the intel backlight driver, however, on this machine it turns the backlight completely off when it reaches level 0%, after which the user might have a lot trouble trying to bring it back.

This patch fixes both regressions by blacklisting the win8 OSI, so we are back to v3.6 behavior, and it should remain that way until the intel backlight driver is fixed.

Since v3.7, users have been forced to fix the initial regression by modifying the boot arguments [1].

[1] https://wiki.archlinux.org/index.php/ASUS_Zenbook_Prime_UX31A

Signed-off-by Felipe Contreras <felipe.contreras@xxxxxxxxx>

---
 drivers/acpi/blacklist.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

drivers/acpi/blacklist.c +14 -0

index cb96296..a404127 100644
@@ -192,6 +192,12 @@ static int __init dmi_disable_osi_win7(const struct dmi_system_id *d)
 	acpi_osi_setup("!Windows 2009");
 	return 0;
 }
+static int __init dmi_disable_osi_win8(const struct dmi_system_id *d)
+{
+	printk(KERN_NOTICE PREFIX "DMI detected: %s\n", d->ident);
+	acpi_osi_setup("!Windows 2012");
+	return 0;
+}
 
 static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 	{

@@ -267,6 +273,14 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 		     DMI_MATCH(DMI_PRODUCT_NAME, "Satellite P305D"),
 		},
 	},
+	{
+	.callback = dmi_disable_osi_win8,
+	.ident = "ASUS Zenbook Prime UX31A",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "UX31A"),
+		},
+	},
 
 	/*
 	 * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.

Signature · 1 line

1.8.3.4

Quoted 58 lines

Since v3.7 the acpi backlight driver doesn't work at all on this machine because presumably the ACPI code contains stub code when Windows 8 OSI is reported.

The commit ea45ea7 (in v3.11-rc2) tried to fix this problem by using the intel backlight driver, however, on this machine it turns the backlight completely off when it reaches level 0%, after which the user might have a lot trouble trying to bring it back.

This patch fixes both regressions by blacklisting the win8 OSI, so we are back to v3.6 behavior, and it should remain that way until the intel backlight driver is fixed.

Since v3.7, users have been forced to fix the initial regression by modifying the boot arguments [1].

[1] https://wiki.archlinux.org/index.php/ASUS_Zenbook_Prime_UX31A

Signed-off-by Felipe Contreras <felipe.contreras@xxxxxxxxx>

---
 drivers/acpi/blacklist.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

drivers/acpi/blacklist.c +14 -0

index cb96296..a404127 100644
@@ -192,6 +192,12 @@ static int __init dmi_disable_osi_win7(const struct dmi_system_id *d)
 	acpi_osi_setup("!Windows 2009");
 	return 0;
 }
+static int __init dmi_disable_osi_win8(const struct dmi_system_id *d)
+{
+	printk(KERN_NOTICE PREFIX "DMI detected: %s\n", d->ident);
+	acpi_osi_setup("!Windows 2012");
+	return 0;
+}
 
 static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 	{

@@ -267,6 +273,14 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 		     DMI_MATCH(DMI_PRODUCT_NAME, "Satellite P305D"),
 		},
 	},
+	{
+	.callback = dmi_disable_osi_win8,
+	.ident = "ASUS Zenbook Prime UX31A",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "UX31A"),
+		},
+	},
 
 	/*
 	 * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.

Signature · 1 line

1.8.3.4

Felipe, Rafaël,

I wonder if this quirk is still needed‽ I'm the owner of an Asus UX31A and of course, I used to set acpi_osi="!Windows 2012" on the kernel command line in order to change the backlight level. *However* since Linux 3.11, this kernel parameter is not needed anymore to influence it. The following commit seems to be the one that fixed (or at least inhibited) the issue:

commit efaa14c7e981bdf8d3c8d39d3ed12bdc60faabb8
ACPI / video: no automatic brightness changes by win8-compatible firmware

Indeed, I reverted it on top of 3.11.6 and I can't change the backlight level anymore on this system!

Please see [1] for more information on what does that commit change in the way to control the backlight level.

So, is this inherent to my system? thought?

Cheers,
Vincent

[1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702188

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 73 lines · Vincent Blut

Quoted 58 lines

Since v3.7 the acpi backlight driver doesn't work at all on this machine because presumably the ACPI code contains stub code when Windows 8 OSI is reported.

The commit ea45ea7 (in v3.11-rc2) tried to fix this problem by using the intel backlight driver, however, on this machine it turns the backlight completely off when it reaches level 0%, after which the user might have a lot trouble trying to bring it back.

This patch fixes both regressions by blacklisting the win8 OSI, so we are back to v3.6 behavior, and it should remain that way until the intel backlight driver is fixed.

Since v3.7, users have been forced to fix the initial regression by modifying the boot arguments [1].

[1] https://wiki.archlinux.org/index.php/ASUS_Zenbook_Prime_UX31A

Signed-off-by Felipe Contreras <felipe.contreras@xxxxxxxxx>

---
 drivers/acpi/blacklist.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

drivers/acpi/blacklist.c +14 -0

index cb96296..a404127 100644
@@ -192,6 +192,12 @@ static int __init dmi_disable_osi_win7(const struct dmi_system_id *d)
 	acpi_osi_setup("!Windows 2009");
 	return 0;
 }
+static int __init dmi_disable_osi_win8(const struct dmi_system_id *d)
+{
+	printk(KERN_NOTICE PREFIX "DMI detected: %s\n", d->ident);
+	acpi_osi_setup("!Windows 2012");
+	return 0;
+}
 
 static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 	{

@@ -267,6 +273,14 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 		     DMI_MATCH(DMI_PRODUCT_NAME, "Satellite P305D"),
 		},
 	},
+	{
+	.callback = dmi_disable_osi_win8,
+	.ident = "ASUS Zenbook Prime UX31A",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "UX31A"),
+		},
+	},
 
 	/*
 	 * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.

Signature · 1 line

1.8.3.4

Felipe, Rafaël,

I wonder if this quirk is still needed‽ I'm the owner of an Asus UX31A and of course, I used to set acpi_osi="!Windows 2012" on the kernel command line in order to change the backlight level. *However* since Linux 3.11, this kernel parameter is not needed anymore to influence it. The following commit seems to be the one that fixed (or at least inhibited) the issue:

commit efaa14c7e981bdf8d3c8d39d3ed12bdc60faabb8
ACPI / video: no automatic brightness changes by win8-compatible firmware

Indeed, I reverted it on top of 3.11.6 and I can't change the backlight level anymore on this system!

Quoted 4 lines

Please see [1] for more information on what does that commit change in the way to control the backlight level.

So, is this inherent to my system? thought?

I don't think ASUS UX31A needs that quirk anymore.

Thanks,
Aaron

Quoted 13 lines

Cheers,
Vincent

[1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=702188

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Quoted 79 lines · Aaron Lu

Quoted 77 lines · Vincent Blut

Quoted 58 lines

Since v3.7 the acpi backlight driver doesn't work at all on this machine because presumably the ACPI code contains stub code when Windows 8 OSI is reported.

The commit ea45ea7 (in v3.11-rc2) tried to fix this problem by using the intel backlight driver, however, on this machine it turns the backlight completely off when it reaches level 0%, after which the user might have a lot trouble trying to bring it back.

This patch fixes both regressions by blacklisting the win8 OSI, so we are back to v3.6 behavior, and it should remain that way until the intel backlight driver is fixed.

Since v3.7, users have been forced to fix the initial regression by modifying the boot arguments [1].

[1] https://wiki.archlinux.org/index.php/ASUS_Zenbook_Prime_UX31A

Signed-off-by Felipe Contreras <felipe.contreras@xxxxxxxxx>

---
 drivers/acpi/blacklist.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

drivers/acpi/blacklist.c +14 -0

index cb96296..a404127 100644
@@ -192,6 +192,12 @@ static int __init dmi_disable_osi_win7(const struct dmi_system_id *d)
 	acpi_osi_setup("!Windows 2009");
 	return 0;
 }
+static int __init dmi_disable_osi_win8(const struct dmi_system_id *d)
+{
+	printk(KERN_NOTICE PREFIX "DMI detected: %s\n", d->ident);
+	acpi_osi_setup("!Windows 2012");
+	return 0;
+}
 
 static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 	{

@@ -267,6 +273,14 @@ static struct dmi_system_id acpi_osi_dmi_table[] __initdata = {
 		     DMI_MATCH(DMI_PRODUCT_NAME, "Satellite P305D"),
 		},
 	},
+	{
+	.callback = dmi_disable_osi_win8,
+	.ident = "ASUS Zenbook Prime UX31A",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK COMPUTER INC."),
+		     DMI_MATCH(DMI_PRODUCT_NAME, "UX31A"),
+		},
+	},
 
 	/*
 	 * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.

Signature · 1 line

1.8.3.4

Felipe, Rafaël,

I wonder if this quirk is still needed‽ I'm the owner of an Asus UX31A and of course, I used to set acpi_osi="!Windows 2012" on the kernel command line in order to change the backlight level. *However* since Linux 3.11, this kernel parameter is not needed anymore to influence it. The following commit seems to be the one that fixed (or at least inhibited) the issue:

commit efaa14c7e981bdf8d3c8d39d3ed12bdc60faabb8
ACPI / video: no automatic brightness changes by win8-compatible firmware

Indeed, I reverted it on top of 3.11.6 and I can't change the backlight level anymore on this system!

Please see [1] for more information on what does that commit change in the way to control the backlight level.

So, is this inherent to my system? thought?

Quoted 1 line

I don't think ASUS UX31A needs that quirk anymore.

Hi Aaron,

Thanks for your answer. Btw I'd like to know if there is a reason that you didn't cc your patch (commit efaa14c7) to <[email protected]>, however I didn't test if it'd apply cleanly!

I wonder if this quirk is still needed‽ I'm the owner of an Asus UX31A and of course, I used to set acpi_osi="!Windows 2012" on the kernel command line in order to change the backlight level. *However* since Linux 3.11, this kernel parameter is not needed anymore to influence it. The following commit seems to be the one that fixed (or at least inhibited) the issue:

commit efaa14c7e981bdf8d3c8d39d3ed12bdc60faabb8
ACPI / video: no automatic brightness changes by win8-compatible firmware

But yeah, it should work in v3.11, but when you set the level to 0, the backlight is turned off, isn't it?

Quoted 2 lines · Felipe Contreras

But yeah, it should work in v3.11, but when you set the level to 0, the backlight is turned off, isn't it?

That's a valid thing for the backlight system to do.

Quoted 6 lines · Matthew Garrett

Quoted 2 lines · Felipe Contreras

But yeah, it should work in v3.11, but when you set the level to 0, the backlight is turned off, isn't it?

That's a valid thing for the backlight system to do.

In your opinion.