Bug 989555 - Macbook Air intel_backlight brightness range after suspend / resume not working
Macbook Air intel_backlight brightness range after suspend / resume not working
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-intel (Show other bugs)
19
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Adam Jackson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-29 10:17 EDT by Matt Hicks
Modified: 2015-02-17 11:24 EST (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-17 11:24:54 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lsmod output (3.50 KB, text/plain)
2013-07-29 10:17 EDT, Matt Hicks
no flags Details
lspci verbose output (5.15 KB, text/plain)
2013-07-29 10:25 EDT, Matt Hicks
no flags Details

  None (edit)
Description Matt Hicks 2013-07-29 10:17:04 EDT
Created attachment 779921 [details]
lsmod output

Description of problem:

Desktop:
  GNOME 3

Hardware (lspci attached):

  Macbook Air 2013 Model
  - Intel Haswell-ULT Graphics Controller - rev 09

Kernel (lsmod attached):

  mhicks@localhost ~$ uname -a
    Linux localhost.localdomain 3.10.3-300.fc19.x86_64 #1 SMP Fri Jul 26 00:00:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux


After a suspend / resume, the brightness control no longer is able to adjust from dark to light.  Essentially, above 2278-2280, the display is at about 95% brightness and below that level, it is about at 5% brightness.  Nothing in between. This is consistent whether using the hotkeys or directly modifying /sys/class/backlight/intel_backlight/brightness.  After a clean reboot, the brightness controls and adjustments work fine.

After some experimentation, here is what I was able to determine about the values that cutover from light to dark.

Procedure - values were set using the /sys/class structure.  For example:
echo "2277" | sudo tee /sys/class/backlight/intel_backlight/brightness

Values after suspend resume:
0-2277: Dark display (probably 5% brightness)

2278-2281: Pulsing display from dark to light.  Usually the pulsing occurs on two numbers but it can vary slightly in my testing.  Most often is occurred on 
2278 (significant pulsing from probably 20% brightness to 95% brightness) and 2279 (slight pulsing from probably 50% brightness to 95% brightness).  However, lately it's been occurring on 2280 and 2281.

2282-2777 (max): Bright display (probably 95% brightness)

I have tried scripts to force the setting on suspend / resume in the following locals with no positive results.  They all set the brightness to the desired value, but it doesn't affect the extreme dark / light range.  Script locations:

/etc/rc.d/rc.local
/etc/pm/sleep.d
/lib/systemd/system-sleep/

Also, no log messages occur in journalctl, or the Xorg.0.log files (or any others I found) that have any related output on suspend or when the display is cycling at the pulsing ranges provided above.

Version-Release number of selected component (if applicable):

Fully updated F19 release as of 7/29/2013.

  gnome-shell-3.8.3-3.fc19.x86_64
  kernel-3.10.3-300.fc19.x86_64
  xorg-x11-drv-intel-2.21.12-1.fc19.x86_64

How reproducible:
  100%

Steps to Reproduce:
1. Boot.  Verify brightness controls work.
2. Suspend / Resume
3. Adjust brightness

Actual results:
  Brightness adjustment has no effect until you hit the transition point.  Then screen will go from very light to very dark or vice versa.

Expected results:
  Brightness adjusts smoothly as it does after a clean reboot.

Additional info:
  Keep up the great work.  Very excited this is running so smoothly on a Macbook Air!
Comment 1 Matt Hicks 2013-07-29 10:25:08 EDT
Created attachment 779933 [details]
lspci verbose output
Comment 2 Matt Hicks 2013-07-29 10:35:30 EDT
I just tested this on KDE (kde-workspace-4.10.5-3.fc19.x86_64) as well to make sure it wasn't a GNOME 3 specific issue.  The results on KDE were exactly the same as with GNOME.
Comment 3 Hugo Osvaldo Barrera 2013-09-18 19:15:46 EDT
The issue is also reproducible on ArchLinux, with compiz as a standalone WM, you can therefore remove any fedora-specific configuration, and any component shared between kde and gnome.
Comment 4 Emmanuele Bassi 2013-10-13 05:47:52 EDT
still happening with Fedora 20.
Comment 5 Alex Markley 2013-10-30 11:36:12 EDT
I just put Fedora 19 on a new MacBookAir6,2 and I can confirm this issue is happening for me too.
Comment 6 michael.mcconachie 2013-11-10 13:39:42 EST
I can confirm as of today the same issues whether I run KDE, or Gnome on an iMac 24-inch, Early 2008.  

-- Processor  2.8 GHz Intel Core 2 Duo
-- Memory  4 GB 800 MHz DDR2 SDRAM
-- Graphics  ATI Radeon HD 2600 Pro 256 MB
Comment 7 John Haiducek 2014-02-02 10:04:30 EST
Same here, same hardware with Fedora 20. This has been reported on freedesktop.org (Bug 67454) and kernel.org (Bug 62881). 

I have been working in MacOS on this machine rather than Linux because of this bug :(
Comment 8 Sean V Kelley 2014-02-02 12:49:23 EST
This issue is resolved for me through a work-around kernel module for mba backlight control.  I use archlinux on MacBookAir 6,2 2013 btw.

https://github.com/patjak/mba6x_bl
Comment 9 Alex Markley 2014-02-04 12:17:13 EST
I've tested this kernel module (mba6x_bl) on Fedora 20 and it does work on this hardware.

Is there any way to implement the fix from mba6x_bl directly in the kernel? This workaround is hardly an option for a new Fedora user on this hardware.
Comment 10 Hans de Goede 2014-04-30 05:59:04 EDT
Hi All,

I've contacted the author of the mba6x_bl module to get the driver added to the upstream kernel, we're currently working on it. Once it has been accepted upstream it should find its way in Fedora pretty quickly.

Regards,

Hans
Comment 11 John Haiducek 2014-04-30 22:23:58 EDT
I still have this problem, even with the mba6x_bl module loaded. Loading the mba6x_bl module initially causes the display brightness buttons to be unresponsive. After suspend and resume the brightness buttons again work, but the old behavior of only allowing 0% or 100% brightness is again present.
Comment 12 Hans de Goede 2014-05-01 04:28:28 EDT
Hi John,

(In reply to John Haiducek from comment #11)
> I still have this problem, even with the mba6x_bl module loaded. Loading the
> mba6x_bl module initially causes the display brightness buttons to be
> unresponsive. After suspend and resume the brightness buttons again work,
> but the old behavior of only allowing 0% or 100% brightness is again present.

I think that the problem may be that you still also have the acpi_video0 backlight control and that X is trying to use that. There has been an update to the mba6x_bl module 2 days ago which makes it unregister the acpi_video backlight control. Can you try getting and building the absolut latest version from: https://github.com/patjak/mba6x_bl

And see if that helps ?

Regards,

Hans
Comment 13 Patrik Jakobsson 2014-05-01 08:39:05 EDT
(In reply to John Haiducek from comment #11)
> I still have this problem, even with the mba6x_bl module loaded. Loading the
> mba6x_bl module initially causes the display brightness buttons to be
> unresponsive. After suspend and resume the brightness buttons again work,
> but the old behavior of only allowing 0% or 100% brightness is again present.

Hi John, I'm the author of the mba6x_bl driver.

When mba6x_bl is loaded you cannot control the brightness by any other backlight device. So Hans is right in that X is using ACPI or Intel backlight instead of mba6x_bl. The latest code will fix this. If you run an older version of the driver you must also specify which backlight device to use in your xorg.conf

Section "Device"
        Identifier      "Intel Graphics"
        Driver          "intel"
        Option          "Backlight"     "mba6x_backlight"
EndSection

I hope that solves your problem.

Thanks
Patrik
Comment 14 John Haiducek 2014-05-01 08:59:12 EDT
Patrik,

Thank you for your help (and for writing the module in the first place!) 

Adding those lines to Xorg.conf fixed the problem for me, but...I'm already using the latest mba6x_bl code from the git repository, so the edits to the Xorg config shouldn't have been necessary according to what you said. Are there any log file(s) or other information I can send to figure out why X isn't using mba6x_bl by default in my case?

John
Comment 15 Patrik Jakobsson 2014-05-01 10:20:23 EDT
(In reply to John Haiducek from comment #14)
> Patrik,
> 
> Thank you for your help (and for writing the module in the first place!) 
> 
> Adding those lines to Xorg.conf fixed the problem for me, but...I'm already
> using the latest mba6x_bl code from the git repository, so the edits to the
> Xorg config shouldn't have been necessary according to what you said. Are
> there any log file(s) or other information I can send to figure out why X
> isn't using mba6x_bl by default in my case?
> 
> John

You're welcome

So you still need the xorg.conf modifications? Make sure that the module you're loading is the same as what you've compiled. Check /sys/class/backlight if acpi_video0 is still there. If so, you have the wrong version of the mba6x_bl module loaded.

The X Intel driver picks firmware backlight drivers first. Both mba6x_bl and the ACPI driver are of the firmware type so it just happened that ACPI took precedence. The correct way of solving this was (as Hans pointed out to me) to tell ACPI backlight that it's no longer needed. That leaves mba6x_bl as the only firmware driver and should automatically get picked by X.

Cheers
Patrik
Comment 16 John Haiducek 2014-05-01 10:32:08 EDT
(In reply to Patrik Jakobsson from comment #15)
> 
> So you still need the xorg.conf modifications? Make sure that the module
> you're loading is the same as what you've compiled. Check
> /sys/class/backlight if acpi_video0 is still there. If so, you have the
> wrong version of the mba6x_bl module loaded.
> 
> The X Intel driver picks firmware backlight drivers first. Both mba6x_bl and
> the ACPI driver are of the firmware type so it just happened that ACPI took
> precedence. The correct way of solving this was (as Hans pointed out to me)
> to tell ACPI backlight that it's no longer needed. That leaves mba6x_bl as
> the only firmware driver and should automatically get picked by X.

In /sys/class/backlight I have intel_backlight and mba6x_backlight (no acpi_video0). I suppose this means that intel_backlight is taking precedence over mba6x_backlight.

John
Comment 17 Hugo Osvaldo Barrera 2014-05-01 10:33:44 EDT
You don't actually need an xorg.conf, just having the following file should do:

$ cat /etc/X11/xorg.conf.d/98-mba6bl.conf
Section "Device"
    Identifier      "Intel Graphics"
    Driver          "intel"
    Option          "Backlight"     "mba6x_backlight"
EndSection
Comment 18 Hans de Goede 2014-05-01 10:40:40 EDT
(In reply to John Haiducek from comment #16)
> In /sys/class/backlight I have intel_backlight and mba6x_backlight (no
> acpi_video0). I suppose this means that intel_backlight is taking precedence
> over mba6x_backlight.

Hmm, did you restart X after updating / insmod-ing the mba6x_backlight driver? X only enumerates the backlight devices when it is first started, so if you change the kernel modules you also need to restart the X server.

I just checked the intel driver sources, and at least the current version should prefer mba6x_backlight over intel_backlight automatically.
Comment 19 John Haiducek 2014-05-01 10:43:39 EDT
(In reply to Hans de Goede from comment #18)
> (In reply to John Haiducek from comment #16)
> > In /sys/class/backlight I have intel_backlight and mba6x_backlight (no
> > acpi_video0). I suppose this means that intel_backlight is taking precedence
> > over mba6x_backlight.
> 
> Hmm, did you restart X after updating / insmod-ing the mba6x_backlight
> driver? X only enumerates the backlight devices when it is first started, so
> if you change the kernel modules you also need to restart the X server.
> 
> I just checked the intel driver sources, and at least the current version
> should prefer mba6x_backlight over intel_backlight automatically.

Yes, I restarted X and the behavior persists after a reboot also.

I have the latests mba6x_backlight but the intel_backlight module was installed months ago, it might be out of date.

John
Comment 20 Hans de Goede 2014-05-01 10:52:16 EDT
(In reply to John Haiducek from comment #19)
> I have the latests mba6x_backlight but the intel_backlight module was
> installed months ago, it might be out of date.

Ok, then this is likely just the somewhat older intel driver in Fedora doing the wrong thing, just stick with the xorg.conf snippet for now then.
Comment 21 Fedora End Of Life 2015-01-09 14:08:50 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 22 Fedora End Of Life 2015-02-17 11:24:54 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

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