On 04/03/2013 03:04 PM, Ben Jencks wrote: > On 04/02/2013 09:00 AM, Seth Forshee wrote: >> On Tue, Apr 02, 2013 at 05:08:23PM +0800, Aaron Lu wrote: >>> On 04/01/2013 09:03 PM, Seth Forshee wrote: >>>> On Mon, Apr 01, 2013 at 09:53:36AM +0800, Aaron Lu wrote: >>>>> On 02/12/2013 12:21 AM, Seth Forshee wrote: >>>>>> The AML implementation for brightness control on several ThinkPads >>>>>> contains a workaround to meet a Windows 8 requirement of 101 brightness >>>>>> levels [1]. The implementation is flawed, as only 16 of the brighness >>>>>> values reported by _BCL affect a change in brightness. _BCM silently >>>>>> discards the rest of the values. Disabling Windows 8 compatibility on >>>>>> these machines reverts them to the old behavior, making _BCL only report >>>>>> the 16 brightness levels which actually work. Add a quirk to do this >>>>>> along with a dmi callback to disable Win8 compatibility. >>>>> >>>>> If we disable the _BQC(i.e. set cap._BQC=0) for these systems, will the >>>>> problem go away? If so, I think perhaps we can put these systems into a >>>>> _BQC quirk table and set cap._BQC=0 for them. >>>> >>>> That helps a little, but we're still left with only 16 of the 101 >>>> brightness levels causing any change in brightness. The firmware isn't >>>> rounding the "bad" values or anything like that; it just silently >>>> ignores them. >>> >>> I really wondered, how Windows handled this, it should have the same >>> problem, unless they are not using the acpi video interface? >> >> I can only guess. >> >> I think I remember reading that Windows 8 does smooth backlight >> transitions, so it may well hit every intermediate brightness value. >> Lenovo could also be supplying a driver which rounds values to the >> nearest working value or uses some other interface or something else. > > Just checked; Windows 8 doesn't use the ACPI interface. It seems to have > access to at least 100 distinct brightness levels. > > I'd guess it's using the same interface as > /sys/class/backlight/intel_backlight, which on my system has a > max_brightness of 4438 and all the values seem to be actually distinct, > if not necessarily discernible to the naked eye. Thanks for the information. If all these affected systems have gpu driver's interface, I think we can simply add them to the video_detect_dmi_table so that no acpi backlight interface will be created for them, and gpu's interface will be used by user space and hotkey processing can still be handled by acpi video driver. Best regards, Aaron -- 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