Bug 71491

Summary:	Acer Aspire One D257, kernel 3.13 broke brightness control, fn brightness keys no longer respond.
Product:	ACPI	Reporter:	Joshua Brown (jhbrown9)
Component:	Power-Video	Assignee:	Aaron Lu (aaron.lu)
Status:	CLOSED PATCH_ALREADY_AVAILABLE
Severity:	normal	CC:	aaron.lu, jlee
Priority:	P1
Hardware:	x86-64
OS:	Linux
Kernel Version:	3.13.5-1-ARCH	Subsystem:
Regression:	No	Bisected commit-id:
Attachments:	acpidump of aspire one d257 git bisect 3.12 good, current bad - 14 steps calling all bad

Description Joshua Brown 2014-03-04 05:03:41 UTC

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.

Comment 1 Aaron Lu 2014-03-04 05:09:19 UTC

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.

Comment 2 Joshua Brown 2014-03-10 04:29:40 UTC

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?

Comment 3 Aaron Lu 2014-03-12 06:30:05 UTC

Better to find the offending commit first with git bisect than we can decide which component this bug belongs to.

Comment 4 Aaron Lu 2014-03-14 07:04:04 UTC

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)?

Comment 5 Joshua Brown 2014-03-14 18:22:12 UTC

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.

Comment 6 Joshua Brown 2014-03-15 05:23:27 UTC

Created attachment 129431 [details]
git bisect 3.12 good, current bad - 14 steps calling all bad

Comment 7 Joshua Brown 2014-03-15 05:24:23 UTC

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.

Comment 8 Aaron Lu 2014-03-17 01:18:42 UTC

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

Comment 9 Joshua Brown 2014-04-22 19:56:45 UTC

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