Arch Linux

I've duplicated this issue on my NB505.

"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).

Might be a DE related issue.

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

The same thing happened for me at the HP Compaq 6710s laptop. Before the update everything was working perfectly.

Same thing here on Toshiba NB500 without X server.

lspci output related to this problem: http://pastebin.com/07e50Q6g

Still occurring on my machine. Is there any information I can provide to help get this solved?

Could you check if you're using an InsydeH20 BIOS? Could be the issue here:
https://bugs.archlinux.org/task/31269

any updtae with newer kernel?

I have the same exact issue with my Toshiba Satellite A135. I still have this problem while using 3.5.3-1-ARCH.

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.

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

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.

*edit*

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.

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.

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.

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.

Continued here:
https://bugzilla.kernel.org/show_bug.cgi?id=47861

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.

Still not fixed :/

@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:
http://thread.gmane.org/gmane.linux.acpi.devel/56345

Apparently yesterday it made it to linux-next: https://patchwork.kernel.org/patch/1588511/

Let's hope for fast turnover!

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..

If developers need any logs/debug - i will provide any needed info.

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.

Shoud be fixed in 3.7, please confirm.

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.