Backlight brightness control doesn't work

Bug #1243267 reported by Björn Cassens
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

Hello, during a kernel update from 3.11.0-4 up to 3.11.0-9 i've found out that my brightness controll of my Notebook (Lenovo Thinkpad T430-D17 (nvidia-graphic card, optimus disabled, driver version: 325.15) does not work). Therefore, i have tried several kernel from kernel.org where all Kernel provides the backlight control. To get comparable values, i have tried the kernel version
ubuntu-kernel: Ubuntu 3.12.0-0.2-generic and 3.12.0-rc6
By using the the ubuntu kernel, i wasn't able to control the backlight brightness but by using the kernel profided by kernel.org works. Therefore, i began to search the patch lists of ubuntu and find this patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-trusty.git;a=blobdiff;f=drivers/acpi/blacklist.c;h=f49ffaedaefdaa28d533d339a3f5cda073687ed7;hp=9515f18898b2b578053c58309185daa7934cfdda;hb=02cb06962306d96f59bc97ec8289c14b73bafb4e;hpb=2eb9acd1a1deb3f4d6428d022fc43541c9e70069.
I have reverted this patch and the brightness control of my notebook works fine.

If anybody wants to execute the ubuntu-bug program, you should note, that i'm not using ubuntu, i'm only using the ubuntu kernel and the ubuntu-bug program is not in my repositories. Therefore, i supply the lspci-vnvn report. If any other logs or reports are missing please feel free to ask me.

Revision history for this message
Björn Cassens (bjoern-cassens) wrote :
Revision history for this message
Seth Forshee (sforshee) wrote :

Björn: We also have reports that this patch fixes the backlight on the T430 (bug #1183856). Possibly Lenovo is making machines that look the same to the kernel but behave differently.

Please also provide the following information.

Grab a copy of your acpi tables by running "acpidump > acpi-tables.txt" and attach acpi-tables.txt here.

Also grab a copy of your dmi information by running "dmidecode > dmi.txt" and attach dmi.txt here.

Then, please do the following twice, once with an Ubuntu kernel where your backlight works and once with one where it doesn't.

1. Capture dmesg output and attach it here.

2. Provide the output from "ls /sys/class/backlight".

3. For each of the directories in /sys/class/backlight, run "cat max_brightness" to find the maximum brightness value supported. Then try writing a few values between 1 and max_brightness to the brightness file, e.g. "echo 10 | sudo tee brightness". Working backlights should change brightness each time you write a new value to brightness. Let me know which backlights work and which do not.

Changed in linux (Ubuntu):
importance: Undecided → Medium
tags: added: saucy
Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

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

apport-collect 1243267

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
Revision history for this message
Björn Cassens (bjoern-cassens) wrote :

Hi, here are all files you wanted in a tar.gz file format. Every output is marked, when the files have been generated (backlight_ok or backlight_NOT_ok). One maybe important fact is, that if i write in to /etc/classes/.../brightness nothing happens, the file actual_brightness shows the written value. But if I'm using xcfe4-power-manager and using the Fn keys it seems to be working and the value in the file actual_brightness changes as well. When i reach the highes possible brightness, the file actual_brightness does not show 100 (which is the max brightness when i'm using the kernel, where the brightness control seems to be working) instead of this it shows only the number 6. The same behavior applies to the not working version of the kernel.

Revision history for this message
Björn Cassens (bjoern-cassens) wrote :

I'm sorry i have choosen a wrong file.

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Seth Forshee (sforshee) wrote :

One more thing. Can you supply the output of running "cat /sys/class/backlight/acpi_video0/device/firmware_node/path" for both kernels?

Revision history for this message
Björn Cassens (bjoern-cassens) wrote :

Here you are... but both files are equal
The naming convention is in this tar.gz the same as the provided files before.

Revision history for this message
Seth Forshee (sforshee) wrote :

The firmware has lots of strange complexities, but as far as I can tell the acpi_video0 backlight interface should fundamentally work no better, or possibly worse, when the patch is reverted. It would be instructive if you could verify this by trying to adjust the brightness using some mechanism other than the hotkeys, e.g. a brightness slider in the UI or something like that.

In that case your backlight would probably be getting changed directly by the firmware rather than by the operating system, and it could be that this commit is responsible for the differing behaviors:

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-saucy.git;a=commitdiff;h=efaa14c7e981bdf8d3c8d39d3ed12bdc60faabb8

If reverting this commit fixes your backlight when the other commit is present then we'll know that's what is happening.

What this likely boils down to is that the ACPI backlight is broken in weird ways, and Lenovo and/or their firmware supplier never bothered to test it because they aren't using it in Windows. There's nothing in the DMI data that I see which will allow us to distinguish between the T430's for which the quirk works and those for which it does not. If you were using the nouveau driver for your graphics you might have an alternate backlight interface which worked, but the nvidia driver isn't providing one.

What you can do as a workaround is to modify your setup to pass the option acpi_osi="Windows 2012" to the kernel when booting, which ought to override the quirk. I can't tell you how this would be done for your distribution however.

penalvch (penalvch)
tags: added: needs-kernel-logs needs-upstream-testing regression-potential
removed: acpi backlight lenovo t430 thinkpad
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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