"Windows 2012" OSI causes backlight problems on current ThinkPad firmware

"Windows 2012" OSI causes backlight problems on current ThinkPad firmware

[Ben Jencks]

The addition of "Windows 2012" to the OSI strings in the 3.7 cycle has
caused backlight brightness adjustment to break on my ThinkPad T530.

Without "Windows 2012" _BCL returns the actual 16 brightness levels:

5, 10, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 80, 90, 100

When "Windows 2012" is present, it returns 101 levels 0-100, but _BCM
rounds any value up to one of the real values above.

This interacts badly with gnome-settings-daemon, which attempts to
change brightness in increments of 5 (1/20 of 100). If brightness is
currently 100, it attempts to decrement it to 95, but it gets rounded
back up to 100, so it's impossible to decrease the brightness.

Booting with acpi_osi="!Windows 2012" fixes the problem, though I'm not
sure if it introduces others; I see several other things depend on WIN8
in DSDT.

Perhaps this should be fixed in gnome-settings-daemon, but since it
appears on the surface to be a kernel regression (3.6 works, 3.7 broken)
I thought I'd report it here first.

ThinkPad T530, BIOS 2.07, booting with pure UEFI (BIOS compatibility
module disabled). I can provide all or part of acpidump output if needed.

-Ben

Not subscribed, please copy me on replies.

Re: "Windows 2012" OSI causes backlight problems on current ThinkPad firmware

[joeyli]

於 一，2012-12-24 於 16:32 -0500，Ben Jencks 提到：
> The addition of "Windows 2012" to the OSI strings in the 3.7 cycle has
> caused backlight brightness adjustment to break on my ThinkPad T530.
> 
> Without "Windows 2012" _BCL returns the actual 16 brightness levels:
> 
> 5, 10, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 80, 90, 100
> 
> When "Windows 2012" is present, it returns 101 levels 0-100, but _BCM
> rounds any value up to one of the real values above.
> 
> This interacts badly with gnome-settings-daemon, which attempts to
> change brightness in increments of 5 (1/20 of 100). If brightness is
> currently 100, it attempts to decrement it to 95, but it gets rounded
> back up to 100, so it's impossible to decrease the brightness.
> 
> Booting with acpi_osi="!Windows 2012" fixes the problem, though I'm
> not
> sure if it introduces others; I see several other things depend on
> WIN8
> in DSDT.
> 
> Perhaps this should be fixed in gnome-settings-daemon, but since it
> appears on the surface to be a kernel regression (3.6 works, 3.7
> broken)
> I thought I'd report it here first. 

Yes, this is g-s-d's problem, g-s-d should adapt to more levels of
brightness:

plugins/power/gsd-power-manager.c

/* on ACPI machines we have 4-16 levels, on others it's ~150 */
#define BRIGHTNESS_STEP_AMOUNT(max) ((max) < 20 ? 1 : (max) / 20)



Thanks a lot!
Joey Lee

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

Re: "Windows 2012" OSI causes backlight problems on current ThinkPad firmware

[Ben Jencks]

On 12/24/2012 06:05 PM, joeyli wrote:
> 於 一，2012-12-24 於 16:32 -0500，Ben Jencks 提到：
>> The addition of "Windows 2012" to the OSI strings in the 3.7 cycle has
>> caused backlight brightness adjustment to break on my ThinkPad T530.
>>
>> Without "Windows 2012" _BCL returns the actual 16 brightness levels:
>>
>> 5, 10, 20, 25, 30, 35, 40, 45, 50, 55, 60, 65, 70, 80, 90, 100
>>
>> When "Windows 2012" is present, it returns 101 levels 0-100, but _BCM
>> rounds any value up to one of the real values above.
>>
>> This interacts badly with gnome-settings-daemon, which attempts to
>> change brightness in increments of 5 (1/20 of 100). If brightness is
>> currently 100, it attempts to decrement it to 95, but it gets rounded
>> back up to 100, so it's impossible to decrease the brightness.
>>
>> Booting with acpi_osi="!Windows 2012" fixes the problem, though I'm
>> not
>> sure if it introduces others; I see several other things depend on
>> WIN8
>> in DSDT.
>>
>> Perhaps this should be fixed in gnome-settings-daemon, but since it
>> appears on the surface to be a kernel regression (3.6 works, 3.7
>> broken)
>> I thought I'd report it here first. 
> 
> Yes, this is g-s-d's problem, g-s-d should adapt to more levels of
> brightness:
> 
> plugins/power/gsd-power-manager.c
> 
> /* on ACPI machines we have 4-16 levels, on others it's ~150 */
> #define BRIGHTNESS_STEP_AMOUNT(max) ((max) < 20 ? 1 : (max) / 20)

Actually, thinking about this some more, I'm not sure what g-s-d could
do about this. It could behave better if brightness changes don't
"stick", but as long as the hardware/kernel is lying to userspace about
how many brightness levels are available the experience can't be
completely right.

If the exact brightness levels aren't exposed, pressing the brightness
up/down keys will skip a real level or not change the real level at all
in some cases.

Would it be possible to add a quirk in to exclude "Windows 2012" on this
hardware/bios?

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