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!
Created attachment 779933 [details] lspci verbose output
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.
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.
still happening with Fedora 20.
I just put Fedora 19 on a new MacBookAir6,2 and I can confirm this issue is happening for me too.
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
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 :(
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
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.
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
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, (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
(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
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
(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
(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
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
(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.
(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
(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.
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.
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.