On 01/21/2014 11:17 AM, Matthew Garrett wrote:

On Tue, 2014-01-21 at 10:24 +0800, Aaron Lu wrote:

quoted

On 01/20/2014 09:34 PM, Matthew Garrett wrote:

quoted

On Mon, 2014-01-20 at 16:12 +0800, Aaron Lu wrote:

quoted

1 remove the win8 OSI check, I've seen win7 laptops that also needs to
  have only the GPU interface left and checking win8 doesn't make much
  sense now;

Are we sure that those aren't simply some other bug?

Well, the firmware on that laptop makes use of EC to do backlight
control and the fact that the firmware interface doesn't work while the
GPU's work seems to indicate that the backlight control circuit is not
routed to EC. I think this is the same case as Win8 laptops.

We know that Windows 8 graphics drivers don't use the ACPI interface,
and that systems change their behaviour as a result, in some cases with
absolutely no way for the ACPI interface could possibly work. I haven't
seen any cases where that's obviously true for any non-Windows 8

Perhaps I'm not clear, I didn't mean non-Windows 8 systems will all favor
GPU's interface, I just meant for one specific win7 laptop I could re-use
the existing code to make the GPU's interface as the only one left. And to
achieve this, the Win8 OSI check in acpi_video_verify_backlight_support
has to be gone.

BTW, I actually think use_native_backlight param should mean "the native
backlight control interface will be the only one available on the system",
it doesn't need to go side by side with Win8 OSI check.

systems. EC interfaces that don't work are often due to Linux leaving
the hardware in a state other than the one expected by the firmware. We

Good to know this, thanks.

shouldn't assume that it's the same issue until we've investigated
further.

OK, but I honestly don't have any idea how to proceed, in case you have
some time, the bug is:
https://bugzilla.kernel.org/show_bug.cgi?id=66501