Since v3.7 the acpi backlight driver doesn't work correctly in several machines because ACPI code has different code for Windows 8, and the rest. The commit ea45ea7 (in v3.11-rc2) tried to fix this problem by using the intel backlight driver, however it introduced several other issues in different machines. 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 (acpi_osi="!Windows 2012"). Once the Intel backlight driver works correctly for all machines, this blacklist can be removed and that driver can be used instead. References: https://bugzilla.kernel.org/show_bug.cgi?id=60682 Reported-by: Danny Baumann <dannybaumann@web.de> Reported-by: Philipp Richter <richterphilipp.pops@gmail.com> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Since v3.7 the ACPI backlight driver doesn't work at all on this machine, because presumably the backlight AML code in the ACPI tables contains a code path that triggers when the OS identifies itself as compatible with Windows 8 (which the kernel started to do in 3.7). That code path is never used by Windows and on this particular machine it turns out to be unusable at all. Work around this problem by blacklisting the win8 OSI, so we are back to v3.6 behavior (that is, we don't tell the BIOS that we are compatible with Windows 8). Since v3.7, users have been forced to work around the initial regression by modifying the boot arguments [1]. [1] https://wiki.archlinux.org/index.php/ASUS_Zenbook_Prime_UX31A [rjw: Changelog] Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Files which aren't actually using infrastructure from module.h shouldn't include it, as it is a big header with lots of child includes spawned off. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
The brightness control hotkey don't work with Vista compatibility because the MSI GX723 includes an infinite while loop in DSDT when brightness control hotkey pressed. The MSI GX723 uses Nvidia video. Perhaps the loop is specific to the Nvidia Vista driver... This patch should be reverted once nouveau grows support to call the ACPI NVIF method. Signed-off-by: Lee, Chun-Yi <jlee@novell.com> Signed-off-by: Len Brown <len.brown@intel.com>
Disable the Windows Vista (SP1) compatibility for Toshiba P305D. http://bugzilla.kernel.org/show_bug.cgi?id=14736 Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>
https://bugzilla.kernel.org/show_bug.cgi?id=12641 Signed-off-by: Len Brown <len.brown@intel.com>
When we claim incompatibility with Vista, include both Vista SP1 and SP2. https://bugzilla.kernel.org/show_bug.cgi?id=12641 Signed-off-by: Len Brown <len.brown@intel.com>
Fix string mismatch for Sony SR290 laptop. https://bugzilla.kernel.org/show_bug.cgi?id=12904#c45 Signed-off-by: Nik A. Melchior <melchior+kernel@cmu.edu> Signed-off-by: Len Brown <len.brown@intel.com>
Disable Vista compatibility for Sony VGN-NS50B_L. https://bugzilla.kernel.org/show_bug.cgi?id=12904#c46 Note that this change is a workaround, not a permanent fix. For the permanent fix is to figure out what compatibility means and to actually be compatible... Tested-by: Voldemar <harestomper@gmail.com> Signed-off-by: Zhang Rui <rui.zhang@intel.com> Signed-off-by: Len Brown <len.brown@intel.com>