Bug 62891

Please do:
$ ls /sys/class/backlight

This is the output of ls:

ls /sys/class/backlight
acpi_video0  intel_backlight

Please try acpi_backlight=vendor in kernel cmdline, also list /sys/class/backlight here when you use the option.

Created attachment 111071 [details]
Brightness ticks with acpi_backlight=vendor

Created attachment 111081 [details]
Brightness ticks with NO acpi_backlight=vendor

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 on attachment 111071 [details]
Brightness ticks with acpi_backlight=vendor

This is related to intel_brightness

Comment on attachment 111081 [details]
Brightness ticks with NO acpi_backlight=vendor

This is related to intel_brightness

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?

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

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

What should I test? What should I echo to /sys/class/backlight/*/brightness?

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.

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.

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.

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.

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.

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.

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

The bug is still there. Here is the dmesg with drm.debug=0xe.

Created attachment 117941 [details]
dmesg on drm-intel-nightly (3.13-rc3) with drm.debug=0xe

User experimental fix seems to resolve this issue. https://github.com/patjak/mba6x_bl

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

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?

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?

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.

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.

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.

Please attach /sys/kernel/debug/dri/0/i915_opregion.

(In reply to Jani Nikula from comment #29)
> Please attach /sys/kernel/debug/dri/0/i915_opregion.

GiulioDP, please attach the requested information.

Created attachment 135321 [details]
i915_opregion

I'm very sorry for the delay. Just added the file.

I can say that using the module mba6x_bl the problem seems to be solved. https://github.com/patjak/mba6x_bl

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