Ubuntu

Regression in brightness control on Lenovo Thinkpad X230 (+tablet) and X1 Carbon

Reported by Stéphane Graber on 2013-01-10
328
This bug affects 75 people
Affects Status Importance Assigned to Milestone
Linux
In Progress
Medium
linux (Fedora)
Unknown
Unknown
linux (Ubuntu)
Medium
Seth Forshee

Bug Description

== Raring SRU Justification ==

Impact: A number of ThinkPad models have a workaround in the ACPI
backlight implementation for Windows 8 that more or less completely
breaks backlight control.

Fix: Add an OSI quirk to no longer claim to be Windows 8 on these
machines, causing the firmware to revert to the older, working behavior.

Test Case: Verified on LP #1098216 and bugzill.kernel.org #51231.

---

Something changed between the 3.5 and the 3.7 kernel, leading to broken brightness control on my Thinkpad x230.

Here are some test results:
== 3.5.0-21-generic ==
=== Post-boot values ===
/sys/class/backlight:
  - intel-backlight
    + actual_brightness => 4438
    + bl_power => 0
    + brightness => 4438
    + max_brightness => 4438
  - acpi_video0
    + actual_brightness => 15
    + bl_power => 0
    + brightness => 15
    + max_brightness => 15

=== Tests ===
echo 0 > acpi_video0/brightness => works
echo 0 > intel_backlight/brightness => works

== 3.8.0-0-generic ==
=== Post-boot values ===
/sys/class/backlight:
  - intel-backlight
    + actual_brightness => 4438
    + bl_power => 0
    + brightness => 4438
    + max_brightness => 4438
  - acpi_video0
    + actual_brightness => 100
    + bl_power => 0
    + brightness => 100
    + max_brightness => 100

=== Tests ===
echo 0 > acpi_video0/brightness => doesn't do anything
echo 0 > intel_backlight/brightness => works
---
ApportVersion: 2.8-0ubuntu1
Architecture: amd64
CheckboxSubmission: 12108b8b8b67d760cdd84f1b9574e7f3
CheckboxSystem: bb422ca46d02494cdbc459927a98bc2f
DistroRelease: Ubuntu 13.04
InstallationDate: Installed on 2012-09-02 (129 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64 (20120902)
MarkForUpload: True
Package: linux (not installed)
ProcEnviron:
 LANGUAGE=en_US:en
 TERM=xterm
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 3.8.0-0.1-generic 3.8.0-rc3
Tags: raring
Uname: Linux 3.8.0-0-generic x86_64
UnreportableReason: The running kernel is not an Ubuntu kernel
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups:

WORKAROUND:

Add to /etc/default/grub
in the variable "GRUB_CMDLINE_LINUX_DEFAULT":

acpi_osi=\"!Windows 2012\"

e.g:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=\"!Windows 2012\""

Then run "sudo update-grub".

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1098216

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
tags: added: quantal
Stéphane Graber (stgraber) wrote :
  • acpi Edit (1.8 KiB, application/binary)
tags: added: apport-collected raring
description: updated
Stéphane Graber (stgraber) wrote :
Stéphane Graber (stgraber) wrote :
Stéphane Graber (stgraber) wrote :
Stéphane Graber (stgraber) wrote :
Stéphane Graber (stgraber) wrote :
Stéphane Graber (stgraber) wrote :
  • fwts Edit (50 bytes, application/binary)
Stéphane Graber (stgraber) wrote :
Stéphane Graber (stgraber) wrote :
Stéphane Graber (stgraber) wrote :
Stéphane Graber (stgraber) wrote :
Stéphane Graber (stgraber) wrote :
Stéphane Graber (stgraber) wrote :
Stéphane Graber (stgraber) wrote :
Stéphane Graber (stgraber) wrote :
Stéphane Graber (stgraber) wrote :
Joseph Salisbury (jsalisbury) wrote :

Do you happen to know the last good and first bad kernel versions? If so, I can perform a bisect to identify the commit that caused the regression.

If you don't know the first bad kernel, can you test the following kernels and report back? We are looking for the first kernel version that exhibits this bug:

v3.5.7: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.5.7-quantal/
v3.6 final: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.6-quantal/
v3.7-rc3: http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-rc3-raring/

You don't have to test every kernel, just up until the kernel that first has this bug.

Changed in linux (Ubuntu):
importance: Undecided → Medium
tags: added: performing-bisect
Stéphane Graber (stgraber) wrote :

Last 3.6 worked, first 3.7 didn't. Based on IRC discussion, that's because 3.7 now advertises win8 support in ACPI which triggers a change in the list of backlight values.

Changed in linux (Ubuntu):
status: Incomplete → Triaged
Stéphane Graber (stgraber) wrote :

For reference, the IRC discussion can be found at: http://irclogs.ubuntu.com/2013/01/10/%23ubuntu-kernel.html#t15:22

Seth Forshee (sforshee) wrote :

To summarize the root cause: If the OS reports itself as Windows 8, the firmware's _BCL returns a list of 101 brightness values, of which only 16 work. These 16 correspond to the values reported by _BCL if the OS does not claim to be Win8. Any brightness value passed to _BCM other than those 16 will be silently discarded without changing the brightness.

Changed in linux:
importance: Unknown → Medium
status: Unknown → Incomplete
Seth Forshee (sforshee) wrote :

I worked up a patch to disable Windows 8 compatibility on this machine (and the ThinkPad T430s as well since it was reported to have the same issue on the upstream bug report). A test build is available at:

http://people.canonical.com/~sforshee/lp1098216/linux-3.8.0-0.3~lp1098216v201301141657/

Changed in linux (Ubuntu):
assignee: nobody → Seth Forshee (sforshee)
status: Triaged → Incomplete
tags: removed: performing-bisect
Stéphane Graber (stgraber) wrote :

Test kernel works fine on the X230.

Changed in linux (Ubuntu):
status: Incomplete → Triaged
summary: - Regression in brightness control on Lenovo Thinkpad x230
+ Regression in brightness control on Lenovo Thinkpad X230 and X1 Carbon
Anmar Oueja (anmar) wrote :

From bug #1121951 we found that the bug happens between 3.6 and 3.7-rc1 . Are we going to bisect this further to find out the offending code change?

Seth Forshee (sforshee) wrote :

We already know what the offending commit is.

commit a57f7f9175b8ccbc9df83ac13860488913115de4
Author: Bob Moore <email address hidden>
Date: Fri Aug 17 10:55:02 2012 +0800

    ACPICA: Add Windows8/Server2012 string for _OSI method.

The problem is that when Linux starts reporting itself as Windows 8 some Lenovo firmware changes its behavior to indicate that the ACPI backlight interface reports 101 brightness levels (this is a requirement of Windows 8). But in reality the firmware ignores 85% of the values that it says are valid and only accepts the same 16 values that it says are valid when the OS reports it self as something other than Windows 8. Any other values are completely ignored.

I've gone back and forth with upstream on this issue, but the maintainers haven't been very responsive. I've got a patch series that's been sitting on the mailing list for a couple of weeks now without any review from the maintainers.

Nathaniel Roach (nroach44) wrote :

This bug also effects the ThinkPad EDGE E330 - I'm compiling 3.8.3 with a modified patch now.

Seth Forshee (sforshee) wrote :

Nathaniel: If you'll run 'sudo acpidump > e330-acpi-tables.txt' and attach the resulting file I can check to verify that it really is the same problem.

1 comments hidden view all 125 comments
Nathaniel Roach (nroach44) wrote :

Seth: The attached modified patch stops the behavior, so I'd say it's the bug.

Result and patch attached anyway.

tags: added: patch
ZiNk (cserpentis) wrote :

Same thing on Lenovo Thinkpad T430. Think it's safe to assume it affects whole lenovo *30 line, since they use same bios/uefi implementation.

Seth Forshee (sforshee) wrote :

Nathaniel, your problem is fundamentally very similar but a little different. I suspect that if you boot without "!Windows 2012" you'll find some ACPI error messages in dmesg. I'd appreciate it if you could give this a try and then attach your dmesg so I can verify that this is correct.

Nathaniel Roach (nroach44) wrote :

Seth, I'm more of a power user, what would I need to do to test that?

Seth Forshee (sforshee) wrote :

Nathaniel: You need to boot to a kernel where your backlight doesn't work, i.e. no special kernel patches and no passing acpi_osi="!Windows 2012". Then try to adjust the backlight several times. After that run "dmesg > dmesg.txt" in a terminal and attach dmesg.txt.

Nathaniel Roach (nroach44) wrote :

So basically build a the same kernel sans patch and any extra arguments?

Building one now.

Seth Forshee (sforshee) wrote :

Or if you still have other kernels installed even easier would be to boot to a kernel with which you experienced the issue.

Nathaniel Roach (nroach44) wrote :

Alright, here's the file.

Fresh extract of the tarball, but using the same config.

Seth Forshee (sforshee) wrote :

Nathaniel: You did try to change the brightness before collecting dmesg, and it did not change the brightness? I'm not seeing the errors I expected, though I'm confident they should occur because they happen when I load your ACPI tables into a debugger.

Maybe try poking some brightness values into the driver directly and see if you get any new messages at the bottom of dmesg. To do this, you'll first want to run 'cat /sys/class/backlight/acpi_video0/max_brightness'. This should output something like 101; if you get something much lower than that (like 15) then you still have acpi_osi="!Windows 2012" applied somehow.

Valid brightness values are anything from 0 to the value you get from the cat command. You set a value by running 'echo n > /sys/class/backlight/acpi_video0/brightness' as root, where n is a valid brightness value. Just be careful of going too low, you still want to be able to read the screen!

Seth Forshee (sforshee) on 2013-04-19
description: updated
description: updated
description: updated
summary: - Regression in brightness control on Lenovo Thinkpad X230 and X1 Carbon
+ Regression in brightness control on Lenovo Thinkpad X230 (+tablet) and
+ X1 Carbon
Brad Figg (brad-figg) on 2013-05-08
tags: added: verification-needed-raring
tags: added: verification-done
removed: verification-needed-raring
Changed in linux:
status: Incomplete → In Progress
45 comments hidden view all 125 comments
Benjamin Tegge (livewirebt) wrote :

I just installed the packages on my T530: Backlight control is working and provides a more fine grained control than with the workaround in current kernels. If I ramp the brightness up and go down towards 0% than the last step completely turns off the backlight. But that's nothing that would be bothering me, though.

The kernel 3.10.0-0-generic #2~lp1098216v201306100718 works
great on a Thinkpad X1 Carbon.

Lowest setting turns off the LCD, which is great. Is this going upstream?

Brain (i-gnatenko-brain) wrote :

@Seth Forshee (sforshee), can you provide *all* patches for this bug in 3.10 kernel ?

Marius B. Kotsbak (mariusko) wrote :

Works fine with my X230 tablet too.

Nathaniel Roach (nroach44) wrote :

I'm getting errors attempting to patch 3.9.5:

0001*.patch:
Hunk #5 FAILED at 1097.

0003*.patch:
Hunk #1 FAILED at 1661.

I'll compile it anyway, and try with 3.10-rc4 later tonight.

Nathaniel Roach (nroach44) wrote :

Adding those patches to a clean 3.9.5 folder on an Edge E330 results in default behaviour (as if no patch were applied).

Seth Forshee (sforshee) wrote :

On Tue, Jun 11, 2013 at 12:13:18AM -0000, Anmar Oueja wrote:
> The kernel 3.10.0-0-generic #2~lp1098216v201306100718 works
> great on a Thinkpad X1 Carbon.
>
> Lowest setting turns off the LCD, which is great. Is this going
> upstream?

It's not clear. There seems to be another solution under development as
well (no patches as of yet though), so I guess the maintainers will pick
whichever one they like better.

Seth Forshee (sforshee) wrote :

On Tue, Jun 11, 2013 at 08:54:44AM -0000, Brain wrote:
> @Seth Forshee (sforshee), can you provide *all* patches for this bug in
> 3.10 kernel ?

All the patches used in the build are already posed in the same location
as the debs.

Seth Forshee (sforshee) wrote :

On Tue, Jun 11, 2013 at 09:25:28AM -0000, Nathaniel Roach wrote:
> I'm getting errors attempting to patch 3.9.5:

Yes, the patches require backporting to anything before 3.10.

Seth Forshee (sforshee) wrote :

On Tue, Jun 11, 2013 at 09:48:17AM -0000, Nathaniel Roach wrote:
> Adding those patches to a clean 3.9.5 folder on an Edge E330 results in
> default behaviour (as if no patch were applied).

Can you explain what this means? Are you saying that the patches do
apply cleanly to 3.9.5, but don't work?

Does your machine have discrete graphics or the integrated Intel
graphics? These change are only going to work with Intel graphics, and
additional patches will be required for radeon/nouveau. This fix is also
probably never going to work with binary blob drivers.

Nathaniel Roach (nroach44) wrote :

Seth: They do apply to 3.9.5 but do not do it cleanly (see errors in comment #90).

My Edge E330 has an Intel i5-3210M with (only) Intel HD4000 graphics.

Nathaniel Roach (nroach44) wrote :

Edit: Behaviour is *exactly* the same as when the bug was not fixed - brightness can only be relatively moved slightly, and when it does it flickers. It can be moved specifying a value (not just up/down), but still flickers.

Nathaniel Roach (nroach44) wrote :

Under patched 3.10-rc5: Backlight control is *COMPLETELY* dependent on the shell being able to process the request - Backlight control does not work while booting or while the shell is frozen. Otherwise, I appreciate the finer control.

(Ubuntu-GNOME 13.04)

Seth Forshee (sforshee) wrote :

On Tue, Jun 11, 2013 at 02:49:21PM -0000, Nathaniel Roach wrote:
> Under patched 3.10-rc5: Backlight control is *COMPLETELY* dependent on
> the shell being able to process the request - Backlight control does not
> work while booting or while the shell is frozen. Otherwise, I appreciate
> the finer control.

Yes, this solution essentially disables ACPI backlight support on Win8
systems when i915 registers a backlight interface. Testing seems to
indicate that Win8 isn't using the ACPI backlight interface, and thus
we can't assume that firmware vendors have actually tested this
interface to verify that it actually works (problems with the ACPI
backlight interfaces on Win8 machines haven't been isolated to only
Lenovos).

Nathaniel Roach (nroach44) wrote :

Fair enough, just thought I'd post my findings here,

Brain (i-gnatenko-brain) wrote :

On Tue, 2013-06-11 at 12:45 +0000, Seth Forshee wrote:
> On Tue, Jun 11, 2013 at 08:54:44AM -0000, Brain wrote:
> > @Seth Forshee (sforshee), can you provide *all* patches for this bug in
> > 3.10 kernel ?
>
> All the patches used in the build are already posed in the same location
> as the debs.
>

Yeah. I patched kernel from Fedora rawhide
(3.10.0-0.rc5.git0.1.bko35622.fc20.B.x86_64) and all works !
--
Best Regards,
Igor Gnatenko

Brain (i-gnatenko-brain) wrote :

@Seth Forshee (sforshee), I build a patched kernel from Fedora Rawhide with 3 patches (from you repo) 10 minutes ago and all works! Great!
3.10.0-0.rc5.git0.1.bko35622.fc20.B.x86_64

Charles Profitt (cprofitt) wrote :

With the latest upgrade to 3.8.0-25-generic #37-Ubuntu SMP Thu Jun 6 20:47:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux the problem is not present on my Lenovo T530 anymore.

Oliver Sauder (sao) wrote :

I can still confirm that this issue exists with kernel 3.8.0-25-generic on a Lenovo T430.

Felix (cebor) wrote :

uname -r
3.8.0-25-generic

bug still exists on thinkpad t430

created new bug: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1183856

Changed in linux:
status: In Progress → Incomplete
Clint Byrum (clint-fewbar) wrote :
Download full text (6.1 KiB)

Same issue on HP EliteBook Folio 9470m.

00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
 Subsystem: Hewlett-Packard Company Device 18df
 Flags: bus master, fast devsel, latency 0
 Capabilities: <access denied>

00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])
 Subsystem: Hewlett-Packard Company Device 18df
 Flags: bus master, fast devsel, latency 0, IRQ 48
 Memory at d0000000 (64-bit, non-prefetchable) [size=4M]
 Memory at c0000000 (64-bit, prefetchable) [size=256M]
 I/O ports at 2000 [size=64]
 Expansion ROM at <unassigned> [disabled]
 Capabilities: <access denied>
 Kernel driver in use: i915

00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI])
 Subsystem: Hewlett-Packard Company Device 18df
 Flags: bus master, medium devsel, latency 0, IRQ 45
 Memory at d0720000 (64-bit, non-prefetchable) [size=64K]
 Capabilities: <access denied>
 Kernel driver in use: xhci_hcd

00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
 Subsystem: Hewlett-Packard Company Device 18df
 Flags: bus master, fast devsel, latency 0, IRQ 49
 Memory at d0735000 (64-bit, non-prefetchable) [size=16]
 Capabilities: <access denied>
 Kernel driver in use: mei

00:16.3 Serial controller: Intel Corporation 7 Series/C210 Series Chipset Family KT Controller (rev 04) (prog-if 02 [16550])
 Subsystem: Hewlett-Packard Company Device 18df
 Flags: bus master, 66MHz, fast devsel, latency 0, IRQ 17
 I/O ports at 20b0 [size=8]
 Memory at d073c000 (32-bit, non-prefetchable) [size=4K]
 Capabilities: <access denied>
 Kernel driver in use: serial

00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
 Subsystem: Hewlett-Packard Company Device 18df
 Flags: fast devsel, IRQ 20
 Memory at d0700000 (32-bit, non-prefetchable) [size=128K]
 Memory at d073b000 (32-bit, non-prefetchable) [size=4K]
 I/O ports at 2080 [size=32]
 Capabilities: <access denied>
 Kernel driver in use: e1000e

00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI])
 Subsystem: Hewlett-Packard Company Device 18df
 Flags: bus master, medium devsel, latency 0, IRQ 16
 Memory at d073a000 (32-bit, non-prefetchable) [size=1K]
 Capabilities: <access denied>
 Kernel driver in use: ehci-pci

00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
 Subsystem: Hewlett-Packard Company Device 18df
 Flags: bus master, fast devsel, latency 0, IRQ 51
 Memory at d0730000 (64-bit, non-prefetchable) [size=16K]
 Capabilities: <access denied>
 Kernel driver in use: snd_hda_intel

00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) (prog-if 00 [Normal decode])
 Flags: bus master, fast devsel, latency 0
 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
 Memory behind bridge: d0600000-d06fffff
 Capabilities: <access denied>
 Kernel driver in...

Read more...

Clint Byrum (clint-fewbar) wrote :

Linux clint-HP 3.8.0-23-generic #34-Ubuntu SMP Wed May 29 20:22:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Changed in linux:
status: Incomplete → In Progress

On my Thinkpad X230, the problem was present in May 2013 but now is gone (3.8.0-25-generic). I cannot tell which kernel update brought the fix.

lepri13 (lepri13) wrote :

Can someone test possible workaround, I am on 3.10.7 when I choose in BIOS under keyboard options swap Fn and Ctrl keys brightness and keyboard seems to work without Grub startup arguments.

Nathaniel Roach (nroach44) wrote :
Download full text (3.4 KiB)

Is that with the newest patches?

On Mon, Sep 2, 2013 at 7:34 AM, lepri13 <email address hidden> wrote:

> Can someone test possible workaround, I am on 3.10.7 when I choose in
> BIOS under keyboard options swap Fn and Ctrl keys brightness and
> keyboard seems to work without Grub startup arguments.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1098216
>
> Title:
> Regression in brightness control on Lenovo Thinkpad X230 (+tablet) and
> X1 Carbon
>
> Status in The Linux Kernel:
> In Progress
> Status in “linux” package in Ubuntu:
> Triaged
> Status in “linux” package in Fedora:
> Unknown
>
> Bug description:
> == Raring SRU Justification ==
>
> Impact: A number of ThinkPad models have a workaround in the ACPI
> backlight implementation for Windows 8 that more or less completely
> breaks backlight control.
>
> Fix: Add an OSI quirk to no longer claim to be Windows 8 on these
> machines, causing the firmware to revert to the older, working behavior.
>
> Test Case: Verified on LP #1098216 and bugzill.kernel.org #51231.
>
> ---
>
> Something changed between the 3.5 and the 3.7 kernel, leading to
> broken brightness control on my Thinkpad x230.
>
> Here are some test results:
> == 3.5.0-21-generic ==
> === Post-boot values ===
> /sys/class/backlight:
> - intel-backlight
> + actual_brightness => 4438
> + bl_power => 0
> + brightness => 4438
> + max_brightness => 4438
> - acpi_video0
> + actual_brightness => 15
> + bl_power => 0
> + brightness => 15
> + max_brightness => 15
>
> === Tests ===
> echo 0 > acpi_video0/brightness => works
> echo 0 > intel_backlight/brightness => works
>
> == 3.8.0-0-generic ==
> === Post-boot values ===
> /sys/class/backlight:
> - intel-backlight
> + actual_brightness => 4438
> + bl_power => 0
> + brightness => 4438
> + max_brightness => 4438
> - acpi_video0
> + actual_brightness => 100
> + bl_power => 0
> + brightness => 100
> + max_brightness => 100
>
> === Tests ===
> echo 0 > acpi_video0/brightness => doesn't do anything
> echo 0 > intel_backlight/brightness => works
> ---
> ApportVersion: 2.8-0ubuntu1
> Architecture: amd64
> CheckboxSubmission: 12108b8b8b67d760cdd84f1b9574e7f3
> CheckboxSystem: bb422ca46d02494cdbc459927a98bc2f
> DistroRelease: Ubuntu 13.04
> InstallationDate: Installed on 2012-09-02 (129 days ago)
> InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64
> (20120902)
> MarkForUpload: True
> Package: linux (not installed)
> ProcEnviron:
> LANGUAGE=en_US:en
> TERM=xterm
> PATH=(custom, no user)
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 3.8.0-0.1-generic 3.8.0-rc3
> Tags: raring
> Uname: Linux 3.8.0-0-generic x86_64
> UnreportableReason: The running kernel is not an Ubuntu kernel
> UpgradeStatus: No upgrade log present (probably fresh install)
> UserGroups:
>
> WORKAROUND:
>
> Add to /etc/default/grub
> in the variable "GRUB_CMDLINE_LINUX_DEFAULT":
>
> acpi_osi...

Read more...

lepri13 (lepri13) wrote :

Just updated to 3.10.10 no patches also tested live latest ubuntu seems to work with both.

lepri13 (lepri13) wrote :

All of the Fn key combinations that I tested work well. Brightness seems to have only large stepping 5 steps but I guess its better than nothing.

BTW I use Mint with Cinamon not sure if his makes much of the difference

Benjamin Tegge (livewirebt) wrote :

Yes, this makes a difference, because you are not using an Ubuntu Linux Kernel (Saucy is currently on 3.11). If you use Mint, please file your bugs against https://bugs.launchpad.net/linuxmint not https://bugs.launchpad.net/ubuntu.

Anmar Oueja (anmar) wrote :

I installed Ubuntu 13.10 running 3.11 kernel and I noticed the stepping is still there. The following fixed the stepping:

sudo sh -c 'echo -n 0 > /sys/module/video/parameters/brightness_switch_enabled'

Seems that the driver and the GNOME settings daemon, or some other user space tool, is issueing the same command so it is doubling up. Should I open another bug or continue to use this bug?

Anmar Oueja (anmar) wrote :

I filed a new bug to capture the issue with the screwed up brightness stepping (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1221795)

lepri13 (lepri13) wrote :

Using above fixes stepping in ubuntu. The fix is still working under ubuntu Swapping Ctrl and Fn keys in bios works

CSRedRat (csredrat) wrote :

Fixed? Can i'm buy X1 Carbon? :)

Download full text (3.3 KiB)

I'm using an X1 Carbon with 13.10 and the brightness control works fine.

On Wed, Jan 1, 2014 at 11:29 AM, CSRedRat <email address hidden>wrote:

> Fixed? Can i'm buy X1 Carbon? :)
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1098216
>
> Title:
> Regression in brightness control on Lenovo Thinkpad X230 (+tablet) and
> X1 Carbon
>
> Status in The Linux Kernel:
> In Progress
> Status in “linux” package in Ubuntu:
> Triaged
> Status in “linux” package in Fedora:
> Unknown
>
> Bug description:
> == Raring SRU Justification ==
>
> Impact: A number of ThinkPad models have a workaround in the ACPI
> backlight implementation for Windows 8 that more or less completely
> breaks backlight control.
>
> Fix: Add an OSI quirk to no longer claim to be Windows 8 on these
> machines, causing the firmware to revert to the older, working behavior.
>
> Test Case: Verified on LP #1098216 and bugzill.kernel.org #51231.
>
> ---
>
> Something changed between the 3.5 and the 3.7 kernel, leading to
> broken brightness control on my Thinkpad x230.
>
> Here are some test results:
> == 3.5.0-21-generic ==
> === Post-boot values ===
> /sys/class/backlight:
> - intel-backlight
> + actual_brightness => 4438
> + bl_power => 0
> + brightness => 4438
> + max_brightness => 4438
> - acpi_video0
> + actual_brightness => 15
> + bl_power => 0
> + brightness => 15
> + max_brightness => 15
>
> === Tests ===
> echo 0 > acpi_video0/brightness => works
> echo 0 > intel_backlight/brightness => works
>
> == 3.8.0-0-generic ==
> === Post-boot values ===
> /sys/class/backlight:
> - intel-backlight
> + actual_brightness => 4438
> + bl_power => 0
> + brightness => 4438
> + max_brightness => 4438
> - acpi_video0
> + actual_brightness => 100
> + bl_power => 0
> + brightness => 100
> + max_brightness => 100
>
> === Tests ===
> echo 0 > acpi_video0/brightness => doesn't do anything
> echo 0 > intel_backlight/brightness => works
> ---
> ApportVersion: 2.8-0ubuntu1
> Architecture: amd64
> CheckboxSubmission: 12108b8b8b67d760cdd84f1b9574e7f3
> CheckboxSystem: bb422ca46d02494cdbc459927a98bc2f
> DistroRelease: Ubuntu 13.04
> InstallationDate: Installed on 2012-09-02 (129 days ago)
> InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64
> (20120902)
> MarkForUpload: True
> Package: linux (not installed)
> ProcEnviron:
> LANGUAGE=en_US:en
> TERM=xterm
> PATH=(custom, no user)
> LANG=en_US.UTF-8
> SHELL=/bin/bash
> ProcVersionSignature: Ubuntu 3.8.0-0.1-generic 3.8.0-rc3
> Tags: raring
> Uname: Linux 3.8.0-0-generic x86_64
> UnreportableReason: The running kernel is not an Ubuntu kernel
> UpgradeStatus: No upgrade log present (probably fresh install)
> UserGroups:
>
> WORKAROUND:
>
> Add to /etc/default/grub
> in the variable "GRUB_CMDLINE_LINUX_DEFAULT":
>
> acpi_osi=\"!Windows 2012\"
>
> e.g:
>
> GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_osi=\"!Windows 2012\""
>
> Then run "...

Read more...

Anmar Oueja (anmar) wrote :
Download full text (6.8 KiB)

On 13.10, the brightness works fine but the stepping is screwed up. In
other words, you don't get to access all of the brightness levels the
LCD offers. Instead, you get half the number of steps. It isn't a show
stopper by any stretch so go ahead and get your X1 carbon. It is the
best machine out there ;-)

On 5 January 2014 19:59, Matthew Tucker-Simmons
<email address hidden> wrote:
> I'm using an X1 Carbon with 13.10 and the brightness control works fine.
>
>
> On Wed, Jan 1, 2014 at 11:29 AM, CSRedRat <email address hidden>wrote:
>
>> Fixed? Can i'm buy X1 Carbon? :)
>>
>> --
>> You received this bug notification because you are subscribed to the bug
>> report.
>> https://bugs.launchpad.net/bugs/1098216
>>
>> Title:
>> Regression in brightness control on Lenovo Thinkpad X230 (+tablet) and
>> X1 Carbon
>>
>> Status in The Linux Kernel:
>> In Progress
>> Status in “linux” package in Ubuntu:
>> Triaged
>> Status in “linux” package in Fedora:
>> Unknown
>>
>> Bug description:
>> == Raring SRU Justification ==
>>
>> Impact: A number of ThinkPad models have a workaround in the ACPI
>> backlight implementation for Windows 8 that more or less completely
>> breaks backlight control.
>>
>> Fix: Add an OSI quirk to no longer claim to be Windows 8 on these
>> machines, causing the firmware to revert to the older, working behavior.
>>
>> Test Case: Verified on LP #1098216 and bugzill.kernel.org #51231.
>>
>> ---
>>
>> Something changed between the 3.5 and the 3.7 kernel, leading to
>> broken brightness control on my Thinkpad x230.
>>
>> Here are some test results:
>> == 3.5.0-21-generic ==
>> === Post-boot values ===
>> /sys/class/backlight:
>> - intel-backlight
>> + actual_brightness => 4438
>> + bl_power => 0
>> + brightness => 4438
>> + max_brightness => 4438
>> - acpi_video0
>> + actual_brightness => 15
>> + bl_power => 0
>> + brightness => 15
>> + max_brightness => 15
>>
>> === Tests ===
>> echo 0 > acpi_video0/brightness => works
>> echo 0 > intel_backlight/brightness => works
>>
>> == 3.8.0-0-generic ==
>> === Post-boot values ===
>> /sys/class/backlight:
>> - intel-backlight
>> + actual_brightness => 4438
>> + bl_power => 0
>> + brightness => 4438
>> + max_brightness => 4438
>> - acpi_video0
>> + actual_brightness => 100
>> + bl_power => 0
>> + brightness => 100
>> + max_brightness => 100
>>
>> === Tests ===
>> echo 0 > acpi_video0/brightness => doesn't do anything
>> echo 0 > intel_backlight/brightness => works
>> ---
>> ApportVersion: 2.8-0ubuntu1
>> Architecture: amd64
>> CheckboxSubmission: 12108b8b8b67d760cdd84f1b9574e7f3
>> CheckboxSystem: bb422ca46d02494cdbc459927a98bc2f
>> DistroRelease: Ubuntu 13.04
>> InstallationDate: Installed on 2012-09-02 (129 days ago)
>> InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Alpha amd64
>> (20120902)
>> MarkForUpload: True
>> Package: linux (not installed)
>> ProcEnviron:
>> LANGUAGE=en_US:en
>> TERM=xterm
>> PATH=(custom, no user)
>> LANG=en_US.UTF-8
>> SHELL=/bin/bash
>> ProcVersio...

Read more...

Anthony Wong (anthonywong) wrote :

The "missing brightness level" problem can be worked around by using the kernel parameter video.brightness_switch_enabled=0.

Add the param to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, then run 'sudo update-grub' and reboot.

Tabris (theangeltabris) wrote :

I'm using a E49 and still not working without adding parameters.

On Mon, Jan 6, 2014 at 12:11 PM, Anthony Wong
<email address hidden> wrote:
> The "missing brightness level" problem can be worked around by using the
> kernel parameter video.brightness_switch_enabled=0.
>
> Add the param to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, then
> run 'sudo update-grub' and reboot.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1098216
>
> Title:
> Regression in brightness control on Lenovo Thinkpad X230 (+tablet) and
> X1 Carbon
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/linux/+bug/1098216/+subscriptions

madbiologist (me-again) wrote :

This should be fixed in the upstream 3.14-rc4 kernel by these two commits:

commit bd8ba20597f0cfef3ef65c3fd2aa92ab23d4c8e1 - ACPI / video: Filter the _BCL table for duplicate brightness values
commit 0e9f81d3b7cd0649a3bc437391b6a0650f98f844 - ACPI / video: Add systems that should favour native backlight interface

The first one has been cc'd to the stable kernel series. A PPA of the 3.14-rc4 kernel is available at http://kernel.ubuntu.com/~kernel-ppa/mainline/ and instructions on how to install and uninstall it are available at https://wiki.ubuntu.com/Kernel/MainlineBuilds

madbiologist (me-again) wrote :

The upstream 3.14-rc4 kernel also contains this commit:

author Rafael J. Wysocki
committer Rafael J. Wysocki
commit a6940190ac15c361862a1a8f50a2072db7184749
tree c73be15646c6418f77a94fede3afc7eabd589dd6
parent 0e9f81d3b7cd0649a3bc437391b6a0650f98f844

Revert "ACPI: Blacklist Win8 OSI for some HP laptop 2013 models"

This reverts commit 2d4054d84224 (ACPI: Blacklist Win8 OSI for some HP laptop 2013 models) that is not necessary any more after previous commit 1811fcb029fa (ACPI / video: Add systems that should favour native backlight interface).

Requested-by: Takashi Iwai
Tested-by: Mika Westerberg
Signed-off-by: Rafael J. Wysocki

Francois Thirioux (ft73) wrote :

Same bug (same workarounds) on ThinkPad T440s with current Trusty.

tags: added: trusty
Anmar Oueja (anmar) wrote :
Download full text (4.0 KiB)

I just tested it on my Thinkpad X1 (haswell) and the fix works.
However, there is a side effect. Connecting and Disconnecting the
Power resets the brightness to maximum. Not sure how to go about
working around this.

anmar

On 26 February 2014 23:14, madbiologist <email address hidden> wrote:
> The upstream 3.14-rc4 kernel also contains this commit:
>
> author Rafael J. Wysocki
> committer Rafael J. Wysocki
> commit a6940190ac15c361862a1a8f50a2072db7184749
> tree c73be15646c6418f77a94fede3afc7eabd589dd6
> parent 0e9f81d3b7cd0649a3bc437391b6a0650f98f844
>
> Revert "ACPI: Blacklist Win8 OSI for some HP laptop 2013 models"
>
> This reverts commit 2d4054d84224 (ACPI: Blacklist Win8 OSI for some HP
> laptop 2013 models) that is not necessary any more after previous commit
> 1811fcb029fa (ACPI / video: Add systems that should favour native
> backlight interface).
>
> Requested-by: Takashi Iwai
> Tested-by: Mika Westerberg
> Signed-off-by: Rafael J. Wysocki
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1121951).
> https://bugs.launchpad.net/bugs/1098216
>
> Title:
> Regression in brightness control on Lenovo Thinkpad X230 (+tablet) and
> X1 Carbon
>
> Status in The Linux Kernel:
> In Progress
> Status in “linux” package in Ubuntu:
> Triaged
> Status in “linux” package in Fedora:
> Unknown
>
> Bug description:
> == Raring SRU Justification ==
>
> Impact: A number of ThinkPad models have a workaround in the ACPI
> backlight implementation for Windows 8 that more or less completely
> breaks backlight control.
>
> Fix: Add an OSI quirk to no longer claim to be Windows 8 on these
> machines, causing the firmware to revert to the older, working behavior.
>
> Test Case: Verified on LP #1098216 and bugzill.kernel.org #51231.
>
> ---
>
> Something changed between the 3.5 and the 3.7 kernel, leading to
> broken brightness control on my Thinkpad x230.
>
> Here are some test results:
> == 3.5.0-21-generic ==
> === Post-boot values ===
> /sys/class/backlight:
> - intel-backlight
> + actual_brightness => 4438
> + bl_power => 0
> + brightness => 4438
> + max_brightness => 4438
> - acpi_video0
> + actual_brightness => 15
> + bl_power => 0
> + brightness => 15
> + max_brightness => 15
>
> === Tests ===
> echo 0 > acpi_video0/brightness => works
> echo 0 > intel_backlight/brightness => works
>
> == 3.8.0-0-generic ==
> === Post-boot values ===
> /sys/class/backlight:
> - intel-backlight
> + actual_brightness => 4438
> + bl_power => 0
> + brightness => 4438
> + max_brightness => 4438
> - acpi_video0
> + actual_brightness => 100
> + bl_power => 0
> + brightness => 100
> + max_brightness => 100
>
> === Tests ===
> echo 0 > acpi_video0/brightness => doesn't do anything
> echo 0 > intel_backlight/brightness => works
> ---
> ApportVersion: 2.8-0ubuntu1
> Architecture: amd64
> CheckboxSubmission: 12108b8b8b67d760cdd84f1b9574e7f3
> CheckboxSystem: bb422ca46d02494cdbc459927a98bc2f
> DistroRelease: Ubuntu 13.04
> InstallationDate: Install...

Read more...

Displaying first 40 and last 40 comments. View all 125 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.