FS#30577 - [linux] 3.4.x - 3.6.x brightness controls doesn't work on Toshiba NB505

Attached to Project: Arch Linux
Opened by Max Pray (synthead) - Friday, 06 July 2012, 23:35 GMT
Last edited by Tobias Powalowski (tpowa) - Wednesday, 23 January 2013, 14:58 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 8
Private No


The Fn + (F6|F7) keys used to work in earlier versions of the v3 kernel, now they don't respond after the system boots. They function just fine with the laptop's firmware (before the OS boots).

linux 3.4.4-2 (x86_64)

Will provide more information as needed :)
This task depends upon

Closed by  Tobias Powalowski (tpowa)
Wednesday, 23 January 2013, 14:58 GMT
Reason for closing:  Fixed
Additional comments about closing:  3.6.10
Comment by Jeff P (jecxjo) - Monday, 09 July 2012, 00:02 GMT
I've duplicated this issue on my NB505.
Comment by Max Pray (synthead) - Monday, 09 July 2012, 02:30 GMT
"echo n > /sys/devices/pci0000:00/0000:00:02.0/backlight/acpi_video0/brightness" seems to still adjust the brightness (where n is a number from 0 to 7).
Comment by Arch Linux User (archie0) - Wednesday, 11 July 2012, 09:36 GMT
Might be a DE related issue.
Comment by Max Pray (synthead) - Wednesday, 11 July 2012, 23:35 GMT
This is on XFCE4.

libxfce4ui 4.10.0-1
libxfce4util 4.10.0-1
xfce4-session 4.10.0-3
xfce4-settings 4.10.0-2
xfconf 4.10.0-2
xfdesktop 4.10.0-3
xfwm4 4.10.0-1
Comment by Maciej Szlosarczyk (sosek) - Tuesday, 17 July 2012, 16:33 GMT
The same thing happened for me at the HP Compaq 6710s laptop. Before the update everything was working perfectly.
Comment by Tomasz Pałka (majar) - Wednesday, 18 July 2012, 12:41 GMT
Same thing here on Toshiba NB500 without X server.
Comment by Max Pray (synthead) - Saturday, 28 July 2012, 17:30 GMT
lspci output related to this problem: http://pastebin.com/07e50Q6g
Comment by Max Pray (synthead) - Thursday, 23 August 2012, 00:45 GMT
Still occurring on my machine. Is there any information I can provide to help get this solved?
Comment by Kyle Van Berendonck (kvanberendonck) - Friday, 24 August 2012, 16:16 GMT
Could you check if you're using an InsydeH20 BIOS? Could be the issue here:
Comment by Jelle van der Waa (jelly) - Monday, 10 September 2012, 18:38 GMT
any updtae with newer kernel?
Comment by kalio (kalio) - Thursday, 13 September 2012, 10:28 GMT
I have the same exact issue with my Toshiba Satellite A135. I still have this problem while using 3.5.3-1-ARCH.
Comment by Stefan Wilkens (stefanwilkens) - Thursday, 13 September 2012, 22:03 GMT
Are any of you able to register the key-presses at all after the related kernel upgrade? (Xev, showkey and friends)

I've done some serious historical digging, this issue doesn't exist on any 2.6 kernel I had available. I'll see if I can pinpoint the 3.4.x kernel change that breaks this.
Comment by Tomasz Pałka (majar) - Friday, 14 September 2012, 16:49 GMT
showkey works fine but still no brightness change:

$ showkey
kb mode was UNICODE
[ if you are trying this under X, it might not work
since the X server is also reading /dev/console ]

press any key (program terminates 10s after last keypress)...
keycode 28 release
keycode 224 press
keycode 224 release # this is for Fn+F6 (decrease brightness)
keycode 225 press
keycode 225 release # this is for Fn+F7 (increase brightness)

Tested with 3.5.3-1-ARCH and showkey version 1.15.3
Comment by Stefan Wilkens (stefanwilkens) - Saturday, 15 September 2012, 12:23 GMT
Small update: I had to drop down all the way to 3.3.4-1-ARCH to regain brightness control. I'm going to start cutting upgrades after this apart to see if I can find the actual kernel commit that broke this.

I'm unsure if i'm affected by this bug or if https://bugs.archlinux.org/task/31269 is applicable. Still investigating.


It's fine up till 3.3.8-1-ARCH, things break on the first 3.4-1-ARCH. This matches the sheer masses of ACPI related backlight / brightness control reports that are already available on the kernel's bugtracker. Next step will be to revert all the ACPI-related commits in the 3.4-rc1 kernel.

Either way, I'm fairly confident this is an upstream regression. Will be compiling vanilla to confirm.
Comment by Kyle Van Berendonck (kvanberendonck) - Monday, 17 September 2012, 10:36 GMT
Latest kernel, still nothing. The scancodes do come through though, but if I map them to the appropriate events (brightness up/down, for example) they don't seem to come up in handler.sh of acpid.
Comment by Stefan Wilkens (stefanwilkens) - Friday, 21 September 2012, 19:40 GMT
Small update again, my kernel bisect indicated that commit ea9f8856bd6d4ed45885b06a338f7362cd6c60e5 is the cause. I've contacted the author of this commit to get the ball rolling.

Given that this is a fairly old commit, I can't simply revert it or create a patch against the current stable... Too much has changed to the affected block of code since that commit and I'm certainly no ACPI wiz. Hopefully more to come.
Comment by Kyle Van Berendonck (kvanberendonck) - Saturday, 22 September 2012, 01:17 GMT
Brightness can be adjusted using the regular acpi (/sys/class/backlight/acpi_video0/brightness) but not the toshiba acpi which seems to steal events from gnome/xfce but not adjust the actual brightness setting. Keys certainly don't work anyhow, tested on mainline.
Comment by Stefan Wilkens (stefanwilkens) - Monday, 24 September 2012, 15:15 GMT
Continued here:

Sadly this issue is very hardware dependent and causes may vary between models, people are generally advised to open their own model specific bug-reports on the kernel's bug-tracker.
Comment by Max Pray (synthead) - Saturday, 13 October 2012, 20:20 GMT
Still not fixed :/
Comment by Stefan Wilkens (stefanwilkens) - Saturday, 13 October 2012, 22:13 GMT
@Max Pray: Can you attach a recent dmesg?

In general: I would suggest you all to do as I did, track down the kernel commit that causes the bug and submit it to the kernel bugtracker + cc-ing the author of the commit. Issues like these are very likely to be caused by upstream development, this is the proper place to report these bugs and get them fixed in stable. I would suggest to report under ACPI Power-Video component.

If anything, finding the commit that causes the issue for you will help you track down the possible cause as searching on the commit hash might provide better results than other arbitrary search terms.

for HP 6720s laptop owners, the fix (workaround) was recently submitted for discussion:
Comment by sledge (sledge) - Wednesday, 24 October 2012, 18:23 GMT
Apparently yesterday it made it to linux-next: https://patchwork.kernel.org/patch/1588511/

Let's hope for fast turnover!
Comment by Dmitry Korzhevin (dkorzhevin) - Thursday, 22 November 2012, 22:29 GMT
Hi! I'm also have brightness problem on HP ProBook 4525s, brightness keys on keyboard stop work after kernel upgrade. KDE brightness controls not works too.

I control brightness in such way:

# echo 13 > /sys/class/backlight/acpi_video0/brightness

This is temporary solution, i hope this will be fixed..
Comment by Dmitry Korzhevin (dkorzhevin) - Thursday, 22 November 2012, 22:30 GMT
If developers need any logs/debug - i will provide any needed info.
Comment by Jelle van der Waa (jelly) - Friday, 23 November 2012, 10:44 GMT
Archlinux developers can't do much with logs/debugs, you should look at stefanwilkens & sledge. You could try building a kernel with the patch attached.
Comment by Tobias Powalowski (tpowa) - Wednesday, 19 December 2012, 10:45 GMT
Shoud be fixed in 3.7, please confirm.
Comment by Stefan Wilkens (stefanwilkens) - Wednesday, 19 December 2012, 11:28 GMT
Was fixed in 3.6.10 for me. I assume the patch made it into the tree before 3.7?

@others with similar issues: You really should post DMESG output or attempt to bisect the kernel yourself, there are piles upon piles of laptop model specific patches in the kernel tree and the kernel devs are now of the opinion that expecting hardware to be perfect is silly.

This means they want you to report these hardware irks.