Le 21/10/2013 03:53, Aaron Lu a écrit : > On 10/21/2013 06:16 AM, Vincent Blut wrote: >> >>> 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(+) >>> >>> diff --git a/drivers/acpi/blacklist.c b/drivers/acpi/blacklist.c >>> index cb96296..a404127 100644 >>> --- a/drivers/acpi/blacklist.c >>> +++ b/drivers/acpi/blacklist.c >>> @@ -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. >>> -- >>> 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? > > 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 <stable@xxxxxxxxxxxxxxx>, however I didn't test if it'd apply cleanly! > > Thanks, > Aaron > >> >> 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 majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
