Bug 62891 - [hsw] MacBook Air 6,2 (2013) brightness is not well calibrated
Summary: [hsw] MacBook Air 6,2 (2013) brightness is not well calibrated
Status: RESOLVED OBSOLETE
Alias: None
Product: Drivers
Classification: Unclassified
Component: Video(DRI - Intel) (show other bugs)
Hardware: x86-64 Linux
: P3 normal
Assignee: intel-gfx-bugs@lists.freedesktop.org
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-12 10:16 UTC by GiulioDP
Modified: 2015-10-07 09:50 UTC (History)
7 users (show)

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


Attachments
Brightness ticks with acpi_backlight=vendor (100 bytes, text/plain)
2013-10-15 09:48 UTC, GiulioDP
Details
Brightness ticks with NO acpi_backlight=vendor (95 bytes, text/plain)
2013-10-15 09:49 UTC, GiulioDP
Details
dmesg on drm-intel-nightly (3.13-rc3) with drm.debug=0xe (115.98 KB, text/plain)
2013-12-09 19:26 UTC, GiulioDP
Details
i915_opregion (8.00 KB, application/octet-stream)
2014-05-07 13:48 UTC, GiulioDP
Details

Description GiulioDP 2013-10-12 10:16:53 UTC
When turning up (or down) the screen brightness level there's no good calibration of the brightness itself. There are no "standard" steps (such as +/- 5%) instead sometimes the screen gets really bright (with one step-up) and sometimes the change is tiny. This does not happen in OSX.
Comment 1 Aaron Lu 2013-10-14 03:11:37 UTC
Please do:
$ ls /sys/class/backlight
Comment 2 GiulioDP 2013-10-14 11:52:04 UTC
This is the output of ls:

ls /sys/class/backlight
acpi_video0  intel_backlight
Comment 3 Aaron Lu 2013-10-15 03:07:37 UTC
Please try acpi_backlight=vendor in kernel cmdline, also list /sys/class/backlight here when you use the option.
Comment 4 GiulioDP 2013-10-15 09:48:26 UTC
Created attachment 111071 [details]
Brightness ticks with acpi_backlight=vendor
Comment 5 GiulioDP 2013-10-15 09:49:11 UTC
Created attachment 111081 [details]
Brightness ticks with NO acpi_backlight=vendor
Comment 6 GiulioDP 2013-10-15 09:51:01 UTC
With acpi_backlight=vendor there is no acpi_video in /sys/class/backlight.
I did not see much difference between those two modes: I uploaded the "ticks" with both flags (w and w/o acpi_backlight=vendor)
Comment 7 GiulioDP 2013-10-15 09:51:56 UTC
Comment on attachment 111071 [details]
Brightness ticks with acpi_backlight=vendor

This is related to intel_brightness
Comment 8 GiulioDP 2013-10-15 09:52:10 UTC
Comment on attachment 111081 [details]
Brightness ticks with NO acpi_backlight=vendor

This is related to intel_brightness
Comment 9 Aaron Lu 2013-10-16 06:14:54 UTC
The step is decided by GUI, and from the log, there is nothing obviously wrong.
But the one step-up makes LCD very bright sounds like a problem. Do you have this behavior after normal boot or after resume?
Comment 10 GiulioDP 2013-10-16 15:26:04 UTC
I can replicate the bug after a normal boot since after a resume there's this critical bug: https://bugzilla.kernel.org/show_bug.cgi?id=62881
Comment 11 Aaron Lu 2013-10-22 09:00:08 UTC
What would happen if you manually adjust brightness levels through the sysfs interface*? Please test both acpi_video and intel_backlight.

*
https://www.kernel.org/doc/Documentation/ABI/stable/sysfs-class-backlight
Comment 12 GiulioDP 2013-10-22 09:09:09 UTC
What should I test? What should I echo to /sys/class/backlight/*/brightness?
Comment 13 Aaron Lu 2013-10-23 05:08:54 UTC
Any value that is less than max_brightness is a valid value to echo. Please note that for intel_backlight interface, if the value echoed is too small, the screen may be very dark, and a 0 would normally turn off the backlight, so avoid those values or you will have to type blindly.
Comment 14 GiulioDP 2013-10-23 10:56:24 UTC
Echoing values change the brightness level but the problem is still the same.
E.g:
The full range is 0-2555 in brightness:
Echoing a number x which is 0 < x < 1000 produces much more brightness than a x >= 1001.
The "first" part is "stronger": the higher the number, the lesser the difference.
Comment 15 Aaron Lu 2013-10-24 07:14:58 UTC
Hi Jani,

Just FYI, this is another problem related to MBA (2013?). See comment #14, for brightness levels < 1000, the change is obvious; for brightness levels > 1000, the change is not obvious. Is this known and expected behavior?

BTW, I've checked the acpidump of MBA provided in #62881, the ACPI control method _BCM makes use of operation region to do backlight setting.
Comment 16 Aaron Lu 2013-10-31 08:54:25 UTC
Hi Jani,

Do you think this is a bug? If so, I suppose I should move it to drivers/DRI-Intel since the ACPI control method just relays the setting to i915 through operation region.
Comment 17 Daniel Vetter 2013-11-25 09:20:42 UTC
Jani's enjoying the carribean for a bit more. Meanwhile please test the latest drm-intel-nightly branch from http://cgit.freedesktop.org/~danvet/drm-intel/

It contains Jani's backlight rework which should fix a bunch of things. If the bug persists please boot with drm.debug=0xe, reproduce the issue (pressing backlight keys should be good enough) and attach the complete dmesg to this bug.
Comment 18 GiulioDP 2013-12-09 10:57:48 UTC
I'm sorry for the newbish question but how can I use the latest drm-intel-nightly? What should I do? Could you please post me a guide? Thanks.
Comment 19 Jani Nikula 2013-12-09 12:44:14 UTC
(In reply to GiulioDP from comment #18)
> I'm sorry for the newbish question but how can I use the latest
> drm-intel-nightly? What should I do? Could you please post me a guide?

If it's not clear, you need to build and install a custom kernel using the sources from the drm-intel-nightly branch of the official drm-intel repository at http://cgit.freedesktop.org/~danvet/drm-intel/

See e.g. http://kernelnewbies.org/KernelBuild or your own distro's pages on how to get started.
Comment 20 GiulioDP 2013-12-09 19:25:31 UTC
The bug is still there. Here is the dmesg with drm.debug=0xe.
Comment 21 GiulioDP 2013-12-09 19:26:46 UTC
Created attachment 117941 [details]
dmesg on drm-intel-nightly (3.13-rc3) with drm.debug=0xe
Comment 22 frank604 2014-01-21 21:41:12 UTC
User experimental fix seems to resolve this issue. https://github.com/patjak/mba6x_bl
Comment 23 Jani Nikula 2014-01-23 08:25:38 UTC
(In reply to frank604 from comment #22)
> User experimental fix seems to resolve this issue.
> https://github.com/patjak/mba6x_bl

Does this work around the issue also for the reporter of this bug?
Comment 24 GiulioDP 2014-01-23 12:35:27 UTC
I've tried the work around which is a module. I built it, loaded it but I don't notice any difference with the brightness behaviour. I followed the installation instructions, obviously. Did someone else try it?
Comment 25 frank604 2014-01-23 17:42:39 UTC
Many of us on the archlinux forums gave it a go and have successful results. https://bbs.archlinux.org/viewtopic.php?id=165899&p=5  Any logs after loading module?
Comment 26 Lionel Landwerlin 2014-01-25 13:36:02 UTC
I'm using Debian with a 3.12.8 kernel on the MacBook Air 6,2 and I can confirm that using the mba6x_bl driver fix my brightness problems after suspend.
Comment 27 GiulioDP 2014-01-25 15:45:04 UTC
This is NOT the 0 or 100% brightness bug! The fix is for that issue... the bug I've reported isn't the one you're referring to.
Comment 28 Patrik Jakobsson 2014-02-08 00:52:35 UTC
I just added a branch called mapping to the mba6x_bl git repo. It tries to map the specified brightness to match the actual brightness a little better. It's not perfect but I think it's an improvement.
Comment 29 Jani Nikula 2014-04-10 14:03:13 UTC
Please attach /sys/kernel/debug/dri/0/i915_opregion.
Comment 30 Jani Nikula 2014-05-07 12:14:54 UTC
(In reply to Jani Nikula from comment #29)
> Please attach /sys/kernel/debug/dri/0/i915_opregion.

GiulioDP, please attach the requested information.
Comment 31 GiulioDP 2014-05-07 13:48:15 UTC
Created attachment 135321 [details]
i915_opregion
Comment 32 GiulioDP 2014-05-07 13:48:41 UTC
I'm very sorry for the delay. Just added the file.
Comment 33 GiulioDP 2014-05-08 10:08:47 UTC
I can say that using the module mba6x_bl the problem seems to be solved. https://github.com/patjak/mba6x_bl
Comment 34 Jani Nikula 2015-10-07 09:50:08 UTC
Long time no updates, closing.

If the problem persists with recent kernel versions, please file a bug at the freedesktop.org bugzilla [1], referencing this bug. Thank you.

[1] https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel

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