Bug 62881 - MacBook Air 6,2 (2013) brightness is either 100% or 0% after suspend
Summary: MacBook Air 6,2 (2013) brightness is either 100% or 0% after suspend
Status: CLOSED MOVED
Alias: None
Product: ACPI
Classification: Unclassified
Component: Power-Video (show other bugs)
Hardware: x86-64 Linux
: P1 high
Assignee: acpi_power-video
URL:
Keywords:
: 60707 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-10-12 10:13 UTC by GiulioDP
Modified: 2013-11-16 19:23 UTC (History)
8 users (show)

See Also:
Kernel Version: 3.12-rc4
Tree: Mainline
Regression: No


Attachments
test brightness with different values and write values to output file (671 bytes, application/x-shellscript)
2013-10-15 10:15 UTC, Can Kavaklıoğlu
Details
output of brightness_test.sh before pm-suspend command (87 bytes, application/octet-stream)
2013-10-15 10:16 UTC, Can Kavaklıoğlu
Details
output of brightness_test.sh after pm-suspend command (87 bytes, application/octet-stream)
2013-10-15 10:16 UTC, Can Kavaklıoğlu
Details
acpidump_before_pm_suspend from kernel source tree (237.78 KB, text/plain)
2013-10-22 10:45 UTC, Can Kavaklıoğlu
Details
acpidump_after_pm_suspend from kernel source tree (237.78 KB, text/plain)
2013-10-22 10:45 UTC, Can Kavaklıoğlu
Details

Description GiulioDP 2013-10-12 10:13:14 UTC
After closing the lid, the MBA 2013 has either 100% or 0% brightness set up. There are NO possible "middle-choices" such as 50% or 25%. This happens EACH time that the MBA goes to sleep.
Comment 1 Aaron Lu 2013-10-14 03:10:43 UTC
Do you mean when you close the lid, the MBA goes to sleep, but the brightness is at 100%. Is this correct?
Comment 2 Can Kavaklıoğlu 2013-10-14 09:19:09 UTC
AaronLu, no, behavior is really interesting:

- boot computer from cold
- can adjust brightness fine at this point
- suspend to ram
- wake up
- try to adjust brightness, but there are only two brightness levels available: 100% or 0%.

In the problematic case /sys/class/backlight/acpi_video0/brightness reports the correct values as brightness is changed. But backlight either goes zero or full brightness.

This issue is reported in Arch, Ubuntu and Freedesktop:

https://bugs.freedesktop.org/show_bug.cgi?id=67454

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1197482

https://bbs.archlinux.org/viewtopic.php?id=165899&p=1

I am testing on a MacAir 6,2 (2013). Let me know if I can do any testing. I will try with 3.12-rc5 right now and let you know about the results.

Thanks.
Comment 3 Can Kavaklıoğlu 2013-10-14 10:18:22 UTC
Problem persists with 3.12.0-rc5.
Comment 4 GiulioDP 2013-10-14 11:53:11 UTC
Same here with 3.12.0-rc5.
Comment 5 Aaron Lu 2013-10-15 03:09:44 UTC
So this means acpi_video stops working after resume.

Does intel_backlight work before/after resume?
You can test it by echoing some value there, e.g.:
# cd /sys/class/backlight
# cat max_brightness
1024 (an example)
# echo 200 > brightness
see if backlight level changed
# echo 500 > brightness
etc.
Comment 6 GiulioDP 2013-10-15 09:54:07 UTC
No it does not work. If you echo a number other than the one which represents the "max_brightness" the screen goes off.
Comment 7 Can Kavaklıoğlu 2013-10-15 10:15:26 UTC
Created attachment 111091 [details]
test brightness with different values and write values to output file
Comment 8 Can Kavaklıoğlu 2013-10-15 10:16:33 UTC
Created attachment 111101 [details]
output of brightness_test.sh before pm-suspend command
Comment 9 Can Kavaklıoğlu 2013-10-15 10:16:53 UTC
Created attachment 111111 [details]
output of brightness_test.sh after pm-suspend command
Comment 10 Can Kavaklıoğlu 2013-10-15 10:20:11 UTC
I attached the test script I have used to test this problem. As GiulioDP mentions, all is fine before the suspend but problem appears after suspend. More detailed:

- bash brightness_test.sh
- screen goes full brightness, 50% brightness, 25% brightness
- copy log file as test_output_before_resume

- suspend with pm-suspend command
- wait a second, resume by pressing a key

- bash brigthness_test.sh
- screen goes full brightness, 0% brightness
- manually increase brightness to full brightness
- copy log file as test_output_after_resume

Thanks.
Comment 11 Aaron Lu 2013-10-16 06:08:54 UTC
Please attach acpidump:
# acpidump > acpidump.txt

Hi Jani,
Do you happen to know this problem? Both acpi_video and intel_backlight's interfaces stop working after resume on Macbook Air 2013.
Comment 12 Can Kavaklıoğlu 2013-10-16 06:55:29 UTC
On 3.12.0-rc5 same both before and after resume:

# acpidump
Table length (0x00000024) is invalid
Could not get ACPI tables, AE_BAD_HEADER
Comment 13 Jani Nikula 2013-10-16 07:03:53 UTC
(In reply to Aaron Lu from comment #11)
> Please attach acpidump:
> # acpidump > acpidump.txt
> 
> Hi Jani,
> Do you happen to know this problem? Both acpi_video and intel_backlight's
> interfaces stop working after resume on Macbook Air 2013.

We know the problem, but not the solution I'm afraid: https://bugs.freedesktop.org/show_bug.cgi?id=67454
Comment 14 Can Kavaklıoğlu 2013-10-20 11:35:23 UTC
No luck with 3.12.0-rc6 : (

Two other points hoping they might ring some bells:

Interesting brightness behavior (appears to be the same before/after suspend):
- reduce brightness to zero
- increase brightness by 10% -> OK
- increase brightness by 10% -> brightness increases some, pauses a moment and then increases some more.

VLC video corruption:
- While playing video with VLC player video freezes partially or fully.
- Changing window with alt-tab refreshes the picture.
- Sound plays fine (VLC thinks all is good?)
- Disable "Accelerated video output (overlay)" from settings
- Video plays fine.

I can conduct any other test you need.
Comment 15 Aaron Lu 2013-10-22 09:01:58 UTC
What about the acpidump version that is in kernel tree?
$ ls kernel_src_tree/tools/power/acpi
acpidump.8  acpidump.c  Makefile
$ make
Comment 16 Can Kavaklıoğlu 2013-10-22 10:44:24 UTC
That works, I have attached the files.
Comment 17 Can Kavaklıoğlu 2013-10-22 10:45:06 UTC
Created attachment 111931 [details]
acpidump_before_pm_suspend from kernel source tree
Comment 18 Can Kavaklıoğlu 2013-10-22 10:45:27 UTC
Created attachment 111941 [details]
acpidump_after_pm_suspend from kernel source tree
Comment 19 Can Kavaklıoğlu 2013-10-22 10:46:56 UTC
(In reply to Can Kavaklıoğlu from comment #16)
> That works, I have attached the files.

Please note that I attached results of two separate runs of the acpidump. Both runs produced the same result.
Comment 20 Can Kavaklıoğlu 2013-10-27 15:07:54 UTC
I tried hibernation instead of suspend to ram using pm-hibernate command. Brightness problem does not occur in this case.

Thanks to the fast SSD drive it may (almost) be a replacement for suspending to ram.
Comment 21 Can Kavaklıoğlu 2013-11-01 07:46:08 UTC
No luck with 3.12.0-rc7 : (
Comment 22 Alex Markley 2013-11-01 13:46:43 UTC
All,

I can confirm I am experiencing the same issue on a MacBookAir6,2 running 3.11.6-200.fc19.x86_64.

Also it looks like this is a duplicate: https://bugzilla.kernel.org/show_bug.cgi?id=60707

Thanks,
Comment 23 Alex Markley 2013-11-01 14:47:38 UTC
I also just tested on kernel-3.12.0-0.rc7.git2.1.fc21.x86_64 and I am still experiencing the same issue.
Comment 24 Can Kavaklıoğlu 2013-11-05 14:12:53 UTC
No luck with 3.12.0 : (
Comment 25 Christoph 2013-11-05 15:14:03 UTC
I got the same problem on a Macbook Air 6,2 (i5-4250U CPU @ 1.30GHz) with kernel 3.12.0. 

Sorry, I am quite new to this kernel bugzilla handling, so please excuse my clumsy question: Why is the status of this bug 'NEEDINFO' for two weeks now? Is  Can Kavaklıoğlu's acpidump not sufficient?
Comment 26 Alex Markley 2013-11-05 15:30:22 UTC
I concur. Please advise on debugging/troubleshooting steps. Those of us who have this hardware would like to help test.
Comment 27 Aaron Lu 2013-11-06 00:29:50 UTC
No more info is needed and no work can be done in ACPI to solve this, please follow the bug here:
https://bugs.freedesktop.org/show_bug.cgi?id=67454
Comment 28 Alan 2013-11-13 16:20:53 UTC
*** Bug 60707 has been marked as a duplicate of this bug. ***
Comment 29 Alan 2013-11-16 19:23:04 UTC
*** Bug 60707 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.