Created attachment 127971 [details] acpidump of aspire one d257 Hello all, I hope I am posting this in the right place. I have an Acer Aspire One, model D257 with intel integrated graphics. The backlight control buttons always worked out of the box with no special kernel parameters until 3.13. Upon upgrading to 3.13, specifically 3.13.5-1 on arch x86_64 -brightness went to max -fn brightness keys are non-responsive -# ls /sys/class/backlight/ acpi_video0 intel_backlight Before the patch, acpi_video0 did not exist. I believe it to be the culprit. I added the video.use_native_backlight=1 parameter to my kernel line in grub. Nothing changed. I then added /etc/X11/xorg.conf.d/20-intel.conf Section "Device" Identifier "card0" Driver "intel" Option "Backlight" "intel_backlight" BusID "PCI:0:2:0" EndSection With the xorg pointer and the kernel parameter, my computer now boots at previously set backlight level, but the fn+brightness keys still do not work. Thanks. Here is the discussion thread about my problem:https://bbs.archlinux.org/viewtopic.php?pid=1388092 I'm attempting to attach my acpidump here, it looks like gibberish to me, but I hope it helps. This is my first time posting a bug, so please let me know what other information you would find helpful.
I'll take a look at the acpidump, and if I didn't find anything obvious, you will need to do a git bisect to find the offending commit.
I should have checked earlier, but I now notice that my fn-vol up/down/mute keys don't work like they used to either. Some other fn-keys don't work like the overlay numpad on the keyboard. 1-9 do not work but the operators +-*/ do. Should I move this bug to a more general hardware issue?
Better to find the offending commit first with git bisect than we can decide which component this bug belongs to.
I checked your ACPI table, the firmware doesn't claim support of win8 so video.use_native_backlight=1 is not for you. Did you try to bisect between v3.12(which I assume works) and v3.13(which is broken)?
Sorry, I'll try to bisect this afternoon. I've never done it before, so it might take a while. Thank you for your continued help. I'll report back with bisect as soon as I am able.
Created attachment 129431 [details] git bisect 3.12 good, current bad - 14 steps calling all bad
OK,so a disclaimer. I know very little about what I'm doing, and had to borrow from some internet reading. If I bisected incorrectly, please let me know how to create a better log for troubleshooting. I couldn't figure out if the arch x86_64 linux package was any different from the Linus kernel, so I bisected the torvalds public git. Should I have bisected an arch specific linux release? My process: /$> sudo git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-git /$> cd linux-git /linux-git $> sudo git bisect start /linux-git $> sudo git bisect good v3.12 /linux-git $> sudo git bisect bad then I just kept on telling it bad through all 14 steps, checking the fn-brightness keys each time. I'm not sure how to test each step otherwise, should I have rebooted each step? See attached log, and thank you all again for your patience.
(In reply to Joshua Brown from comment #7) > OK,so a disclaimer. I know very little about what I'm doing, and had to > borrow from some internet reading. If I bisected incorrectly, please let me > know how to create a better log for troubleshooting. I couldn't figure out > if the arch x86_64 linux package was any different from the Linus kernel, so > I bisected the torvalds public git. > Should I have bisected an arch specific linux release? No arch specific tree, just use Linus' tree. > > My process: > /$> sudo git clone No need to use sudo here, the same for the following commands. > git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux-git > /$> cd linux-git > /linux-git $> sudo git bisect start > /linux-git $> sudo git bisect good v3.12 > /linux-git $> sudo git bisect bad I think you can start by: $ git bisect reset v3.13 $ git bisect start $ git bisect bad ;v3.13 is bad $ git bisect good v3.12 ;v3.12 is good ... ... > > then I just kept on telling it bad through all 14 steps, checking the > fn-brightness keys each time. I'm not sure how to test each step otherwise, > should I have rebooted each step? Everytime you need to build the kernel and use that kernel to test if it has the problem and then tell git whether this commit is good or bad. Here is a link for a introduction: http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search Please let me know if you have any questions/problems, thanks.
I wasn't able to bisect, it took hours to compile each step and broke three steps in most times. I gave up. Thankfully, with the latest kernel, my fn backlight keys are working again. So I guess this is solved. Not sure what the problem was, but I suspect it is the native backlight entry discussed here: https://bugzilla.kernel.org/show_bug.cgi?id=35622 Thank you for all the help