Created attachment 95952 [details] dmesg of broken kernel with drm.debug=0xe On a Dell XPS13 (IVB version), backlight control is broken with v3.14-rc7, it was previously working with v3.13. Reverting patch bc0bb9fd1c78 ("drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE") gets things working again.
Created attachment 95953 [details] Output of intel_reg_dumper with vanilla v3.14-rc7 (not working)
Created attachment 95954 [details] Output of intel_reg_dumper with revert (working)
Created attachment 96374 [details] [review] drm/i915/dp: reorder backlight pwm enable/disable wrt panel sequencing Please try the attached patch.
Thanks for the patch, but it doesn't apply on top of v3.14-rc8. I'm guessing this is on top of drm-intel-next? Looks like the changes could apply to ironlake_edp_backlight_{on,off} but there are some other changes in there so please confirm.
(In reply to comment #4) > Thanks for the patch, but it doesn't apply on top of v3.14-rc8. I'm guessing > this is on top of drm-intel-next? Looks like the changes could apply to > ironlake_edp_backlight_{on,off} but there are some other changes in there so > please confirm. On top of drm-intel-nightly, yes.
If this is going to be submitted for v3.14-final or have a -stable tag I'd rather test a standalone patch on top of v3.14-rc8 than build a kernel from drm-intel-nightly. Thanks.
Created attachment 96375 [details] [review] drm/i915/dp: reorder backlight pwm enable/disable wrt panel sequencing (for v3.14-rc8) The same for v3.14-rc8. Please test.
Ok, sorry but this one on top of v3.14-rc8 doesn't work either.
I'm joining the conversation, broken backlight on XPS13 w/ kernel 3.14 (as released yesterday). Would be happy to test patch againt mainline 3.14.
Update: echo 0 > /sys/class/backlight/intel_backlight is a valid work-around, for me.
(In reply to comment #10) > Update: echo 0 > /sys/class/backlight/intel_backlight is a valid > work-around, for me. Does acpi_backlight work after that?
Please attach /sys/kernel/debug/dri/0/i915_opregion
Also please provide a reg dump *before* i915 gets loaded. Does acpi_backlight work before i915 is loaded?
Also, is there a difference between EFI vs. legacy boot?
Please do all of the above, and additionally try this hack: diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index cb058408c70e..a07c8fa7aed0 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -1065,6 +1065,8 @@ int intel_panel_setup_backlight(struct drm_connector *connector) unsigned long flags; int ret; + return 0; + /* set level and max in panel struct */ spin_lock_irqsave(&dev_priv->backlight_lock, flags); ret = dev_priv->display.setup_backlight(intel_connector);
Ping, please provide the requested information to move forward with this.
I'm sorry. I never got a mail about the additional comments. I just accidentally checked back and saw your updates. I will get back to this as soon as possible and supply the info where possible.
Created attachment 97111 [details] As requested Some answers and output: Let me start by saying that the backlight is ON, so I can work. The only thing that stopped working is backlight control in KDE powercontrol interface. 1. Does acpi_backlight work after that? The KDE powercontrol interface works again after that (my main concern). Echo'ing values between 0 and 100 in /sys/class/backlight/acpi_video0/brightness correctly sets the brightness. Echoing values between 0 and /sys/class/backlight/intel_backlight/max_brightness to /sys/class/backlight/intel_backlight/brightness makes the backlight pulsate (slowly) except for max_brightness which makes the backlight max without pulse. acpi_video0 doesn't work then. 2. Please attach /sys/kernel/debug/dri/0/i915_opregion See attached file. 3. Also please provide a reg dump *before* i915 gets loaded. Does acpi_backlight work before i915 is loaded? I think this is one of the things I can't easily help you with, i915 is compiled into my kernel since it makes no sense booting without (to me). 4. Also, is there a difference between EFI vs. legacy boot? I boot legacy and have no EFI partition. I don't want to risk reformatting my drive, since this is my daily workhorse. 5. Please do all of the above, and additionally try this hack Done. This fixes my problem.
Created attachment 97119 [details] [review] 1/2 drm/i915: check VBT for supported backlight type
Created attachment 97120 [details] [review] 2/2 drm/i915: do not setup backlight if not available according to VBT Please test with these two patches applied.
Both patches apply with some offsets, the resulting kernel works like a charm! Thx!
(In reply to comment #20) > Created attachment 97120 [details] [review] [review] > 2/2 drm/i915: do not setup backlight if not available according to VBT > > Please test with these two patches applied. Works great! These patches do indeed re-fix backlight control in v3.14, on both the two XPS13 models that had needed the NO_PCH_PWM_ENABLE quirk. Tested-by: Kamal Mostafa <kamal@canonical.com> Thanks Jani!
Fix pushed as commit 1901dd794a87911d82edab57dc6f87c7fe9c9bfc Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Apr 9 11:31:37 2014 +0300 drm/i915: do not setup backlight if not available according to VBT and commit d76fedf1980022912508e742660cebdc27c7a010 Author: Jani Nikula <jani.nikula@intel.com> Date: Wed Apr 9 11:22:06 2014 +0300 drm/i915: check VBT for supported backlight type These will fix the issue for 3.15 and beyond, but Daniel feels it's too risky to backport these to 3.14. I'll leave the bug open until we've figured out what to do with that. Possibly the safest approach would be to revert commit bc0bb9fd1c7810407ab810d204bbaecb255fddde Author: Jani Nikula <jani.nikula@intel.com> Date: Thu Nov 14 12:14:29 2013 +0200 drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE in 3.14 stable.
(In reply to comment #23) > Fix pushed as Pushed to drm-intel-fixes, that is.
*** Bug 77266 has been marked as a duplicate of this bug. ***
@Jani: sorry for creating a duplicate. So if my understanding is correct, I shall wait kernel 3.14.1 to be released, right? Will 3.14.1 require any special boot parameter to include the fix (currently I only have "quiet")?
@Jani: sorry again, I've read more carefully your comments and saw that will most likely flow into 3.15. For now I've created a custom systemd service as workaround on Arch Linux: ******* /etc/systemd/system/brightness-fix.service : [Unit] Description=Fixes intel backlight control with Kernel 3.14 [Service] Type=forking ExecStart=/usr/bin/brightness-fix TimeoutSec=0 StandardOutput=syslog #RemainAfterExit=yes #SysVStartPriority=99 [Install] WantedBy=multi-user.target ******* /usr/bin/brightness-fix : #!/bin/bash echo 0 > /sys/class/backlight/intel_backlight/brightnes
(In reply to comment #26) > @Jani: sorry for creating a duplicate. So if my understanding is correct, I > shall wait kernel 3.14.1 to be released, right? > Will 3.14.1 require any special boot parameter to include the fix (currently > I only have "quiet")? (In reply to comment #27) > @Jani: sorry again, I've read more carefully your comments and saw that will > most likely flow into 3.15. Don't worry about the dupe; it's *way* more confusing when info is added to an existing bug when the issues turn out to *not* be the same bug! Some 3.15 release candidate will get the fix first, but we'll fix this for 3.14 stable releases as well - which 3.14.point release it will be is out of our control.
@Jani: Sorry for bothering you again but I need help with the workaround described at comment #27. That script is correctly executed at boot and fixes the backlit control. However the problem persist when wakin up from sleep. So I changed my service config file like this: [Install] WantedBy=multi-user.target sleep.target the script is actually executed while resuming from sleep but has no effect at all. I tried loging some values to check that the script is actually executed and see some environment variables and I discovered that both $DISPLAY and $USER are empty at resume time (they are correct at boot time). I understand that this is a little out of scope for a bug trace hystory but it might help other to correctly set up a workaround until the bug fix is released. Thanks.
(In reply to comment #29) > @Jani: Sorry for bothering you again but I need help with the workaround > described at comment #27. Sorry I don't think I'll be able to help much here. You've got a typo (missing s in brightness) in what you've pasted here but I bet you have that right in the script. Maybe try re-setting the brightness in acpi backlight afterwards?
I seem to have a corresponding issue with a Samsung Q35 laptop running arch linux. The screen brightness was not a problem until I updated recently to kernel 3.14.1-1-ARCH. The graphics hardware is 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) With the the 3.14 kernel the screen shows normal brightness during POST, and for the initial stages of the boot. But the screen dims to an unusable level when X starts so that the KDM login greeter screen is so dim it would be unusable. At this stage I can use the Fn+up arrow key once and the screen goes to full brightness. If I then login, then the screen dims again after a short time so that the logged in user again has a screen that is too dim to be usable. Again pressing Fn+ up arrow restores full brightness. There is nothing indicating a problem in the systemd journal log. There is nothing that seems to indicate a problem in /var/log/Xorg.0.log either. Trying to boot with acpi_video=vendor does not help. Adding in a file as per: cat /etc/X11/xorg.conf.d/10-intel.conf Section "Device" Option "Backlight" "intel_backlight" Identifier "Card0" Driver "intel" BusID "PCI:0:2:0" also made no difference. Attempting to use xbacklight -dec 10 after the backlight was set using the key combination specified above then dimmed the screen to be unusable and I could not then recover using Fn+up arrow and had to reboot. I guess restarting X may have worked also. I also tried echo 0 > /sys/class/backlight/intel_backlight/brightness but that also dimmed the screen to be unusable and I could not then recover the brightness. The only directory in the /sys/class/backlight is: intel_backlight I don't know if this problem has a potential fix coming in kernel 3.15 or whether this is an xorg problem?
An additional symptom that I have is that after setting the brightness to max using Fn+up arrow after logging in, if I go to the KDE settings then under Power Management, and move the brightness slider a small amount from full to a little less than full brightness and then click "Apply" the screen dims to an unusable level immediately. I can recover to full brightness again by click Fn+up arrow once and the screen is back to full brightness.
Downgrading the kernel back to 3.13.7 gives a system where the reported problems are not present. This confirms that the issue in the previous two comments must be one or more patches in the kernel 3.14.1-1 : [2014-04-21 16:56] [PACMAN] downgraded linux (3.14.1-1 -> 3.13.7-1) [2014-04-21 16:57] [PACMAN] downgraded linux-headers (3.14.1-1 -> 3.13.7-1)
I have a second laptop (Samsung NC10) which displays the same symptoms as the Samsung Q35. The NC10 has graphics: 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GSE Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03)
Mike, please try kernel v3.15-rc2 and report back. If that fixes stuff for you, great. If it doesn't, it's another bug -> file a new bug.
I found time to build kernel v3.15-rc2 today (it's a 3 hour build!), but unfortunately this kernel does not fix the dim backlight issue for me and the symptoms are the same as with kernel 3.14. So I guess mine is a different bug.
(In reply to comment #36) > I found time to build kernel v3.15-rc2 today (it's a 3 hour build!), but > unfortunately this kernel does not fix the dim backlight issue for me and > the symptoms are the same as with kernel 3.14. So I guess mine is a > different bug. Mike, you have a different bug. Please first see if [1] sounds right, and try the relevant patch [2]. If that doesn't fix the issue, please file a new bug. Thanks. [1] https://bugzilla.kernel.org/show_bug.cgi?id=72491 [2] http://mid.gmane.org/535DC8C1.5090407@intel.com
(In reply to comment #23) > Fix pushed as > > commit 1901dd794a87911d82edab57dc6f87c7fe9c9bfc > Author: Jani Nikula <jani.nikula@intel.com> > Date: Wed Apr 9 11:31:37 2014 +0300 > > drm/i915: do not setup backlight if not available according to VBT > > and > > commit d76fedf1980022912508e742660cebdc27c7a010 > Author: Jani Nikula <jani.nikula@intel.com> > Date: Wed Apr 9 11:22:06 2014 +0300 > > drm/i915: check VBT for supported backlight type > > These will fix the issue for 3.15 and beyond, but Daniel feels it's too > risky to backport these to 3.14. I'll leave the bug open until we've figured > out what to do with that. Possibly the safest approach would be to revert > > commit bc0bb9fd1c7810407ab810d204bbaecb255fddde > Author: Jani Nikula <jani.nikula@intel.com> > Date: Thu Nov 14 12:14:29 2013 +0200 > > drm/i915: remove QUIRK_NO_PCH_PWM_ENABLE > > in 3.14 stable. While we have this covered now in upstream, I've submitted the revert to 3.14 stable [1]. Let's see what the stable team says. [1] http://mid.gmane.org/b6e9694e03367a3133511f7093c917b4982f1266.1398678778.git.jani.nikula@intel.com
(In reply to comment #37) > (In reply to comment #36) > > I found time to build kernel v3.15-rc2 today (it's a 3 hour build!), but > > unfortunately this kernel does not fix the dim backlight issue for me and > > the symptoms are the same as with kernel 3.14. So I guess mine is a > > different bug. > > Mike, you have a different bug. Please first see if [1] sounds right, and > try the relevant patch [2]. If that doesn't fix the issue, please file a new > bug. Thanks. > > [1] https://bugzilla.kernel.org/show_bug.cgi?id=72491 > [2] http://mid.gmane.org/535DC8C1.5090407@intel.com Jan, thank you. I have filed a report at https://bugs.freedesktop.org/show_bug.cgi?id=78200 but added a comment to your bug referenced at [1].
I experience a similar issue as this on a DELL XPS M1330 (Arch linux). I have tried 3.15-rc5 but that doesn't fix it. Reverting back to 3.13.8 does. # echo 255000 > /sys/class/backlight/intel_backlight Will temporarily fix it on kernels >= 3.14.1. I don't know if it's exactly the same bug since it isn't fixed in 3.15-rc5 for me. Should I file a new bug?
(In reply to comment #40) > I experience a similar issue as this on a DELL XPS M1330 (Arch linux). > > I have tried 3.15-rc5 but that doesn't fix it. Reverting back to 3.13.8 does. > > # echo 255000 > /sys/class/backlight/intel_backlight > > Will temporarily fix it on kernels >= 3.14.1. > > I don't know if it's exactly the same bug since it isn't fixed in 3.15-rc5 > for me. Should I file a new bug? Please do, it's a different bug. In that new bug, please attach dmesg from early boot to the problem, with drm.debug=0xe module parameter set, and also attach /sys/kernel/debug/dri/0/i915_opregion. This bug remains open solely for following through with the stable backport mentioned in comment #38.
(In reply to comment #41) > This bug remains open solely for following through with the stable backport > mentioned in comment #38. The backport is now queued to 3.14 stable per http://lkml.kernel.org/r/14000979302980@kroah.com Everyone, thanks for the report and testing, please file new bugs for new issues! ;)
I've just checked and kernels not using the mentioned quirk work like a charm with "Legacy Boot Rom" disabled in BIOS. (XPS13 IVY). This quirk (QUIRK_NO_PCH_PWM_ENABLE) causes backlight to turn completely off after kernel start on legacy-feee machines. Do we really have to reapply it in 3.14? Isn't disabling this option (which is a good thing performance-wise) engouth?
(In reply to comment #43) > I've just checked and kernels not using the mentioned quirk work like a > charm with "Legacy Boot Rom" disabled in BIOS. (XPS13 IVY). This quirk > (QUIRK_NO_PCH_PWM_ENABLE) causes backlight to turn completely off after > kernel start on legacy-feee machines. Do we really have to reapply it in > 3.14? Isn't disabling this option (which is a good thing performance-wise) > engouth? The rule is fixing the earlier regression wins. Please make sure v3.15-rc5 works for you, and file a bug if it doesn't.
I just got the update to kernel 3.14.5 on ArchLinux and I can confirm that this fixes the issue for me. Thanks!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.