Bug 76276 - Backlight control broken on Dell XPS13 w/ kernel 3.14-rc7
Summary: Backlight control broken on Dell XPS13 w/ kernel 3.14-rc7
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Jani Nikula
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
: 77266 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-03-17 16:31 UTC by Romain Francoise
Modified: 2017-07-24 22:55 UTC (History)
6 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg of broken kernel with drm.debug=0xe (78.66 KB, text/plain)
2014-03-17 16:31 UTC, Romain Francoise
no flags Details
Output of intel_reg_dumper with vanilla v3.14-rc7 (not working) (17.47 KB, text/plain)
2014-03-17 16:32 UTC, Romain Francoise
no flags Details
Output of intel_reg_dumper with revert (working) (17.47 KB, text/plain)
2014-03-17 16:32 UTC, Romain Francoise
no flags Details
drm/i915/dp: reorder backlight pwm enable/disable wrt panel sequencing (1.75 KB, patch)
2014-03-25 16:32 UTC, Jani Nikula
no flags Details | Splinter Review
drm/i915/dp: reorder backlight pwm enable/disable wrt panel sequencing (for v3.14-rc8) (1.77 KB, patch)
2014-03-25 18:11 UTC, Jani Nikula
no flags Details | Splinter Review
As requested (8.00 KB, application/octet-stream)
2014-04-09 07:29 UTC, Martin
no flags Details
1/2 drm/i915: check VBT for supported backlight type (2.60 KB, patch)
2014-04-09 08:44 UTC, Jani Nikula
no flags Details | Splinter Review
2/2 drm/i915: do not setup backlight if not available according to VBT (1.79 KB, patch)
2014-04-09 08:45 UTC, Jani Nikula
no flags Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Romain Francoise 2014-03-17 16:31:21 UTC
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.
Comment 1 Romain Francoise 2014-03-17 16:32:26 UTC
Created attachment 95953 [details]
Output of intel_reg_dumper with vanilla v3.14-rc7 (not working)
Comment 2 Romain Francoise 2014-03-17 16:32:56 UTC
Created attachment 95954 [details]
Output of intel_reg_dumper with revert (working)
Comment 3 Jani Nikula 2014-03-25 16:32:53 UTC
Created attachment 96374 [details] [review]
drm/i915/dp: reorder backlight pwm enable/disable wrt panel sequencing

Please try the attached patch.
Comment 4 Romain Francoise 2014-03-25 17:11:38 UTC
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.
Comment 5 Jani Nikula 2014-03-25 17:18:02 UTC
(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.
Comment 6 Romain Francoise 2014-03-25 17:30:13 UTC
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.
Comment 7 Jani Nikula 2014-03-25 18:11:51 UTC
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.
Comment 8 Romain Francoise 2014-03-25 18:38:36 UTC
Ok, sorry but this one on top of v3.14-rc8 doesn't work either.
Comment 9 Martin 2014-03-31 17:44:33 UTC
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.
Comment 10 Martin 2014-03-31 18:14:05 UTC
Update: echo 0 > /sys/class/backlight/intel_backlight is a valid work-around, for me.
Comment 11 Jani Nikula 2014-04-01 06:25:20 UTC
(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?
Comment 12 Jani Nikula 2014-04-01 06:29:26 UTC
Please attach /sys/kernel/debug/dri/0/i915_opregion
Comment 13 Jani Nikula 2014-04-03 06:59:48 UTC
Also please provide a reg dump *before* i915 gets loaded. Does acpi_backlight work before i915 is loaded?
Comment 14 Jani Nikula 2014-04-03 07:02:33 UTC
Also, is there a difference between EFI vs. legacy boot?
Comment 15 Jani Nikula 2014-04-03 17:42:56 UTC
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);
Comment 16 Jani Nikula 2014-04-08 12:18:57 UTC
Ping, please provide the requested information to move forward with this.
Comment 17 Martin 2014-04-08 20:53:52 UTC
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.
Comment 18 Martin 2014-04-09 07:29:59 UTC
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.
Comment 19 Jani Nikula 2014-04-09 08:44:44 UTC
Created attachment 97119 [details] [review]
1/2 drm/i915: check VBT for supported backlight type
Comment 20 Jani Nikula 2014-04-09 08:45:43 UTC
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.
Comment 21 Martin 2014-04-09 15:57:25 UTC
Both patches apply with some offsets, the resulting kernel works like a charm! Thx!
Comment 22 Kamal Mostafa 2014-04-09 16:59:59 UTC
(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!
Comment 23 Jani Nikula 2014-04-10 08:15:09 UTC
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.
Comment 24 Jani Nikula 2014-04-10 08:15:53 UTC
(In reply to comment #23)
> Fix pushed as

Pushed to drm-intel-fixes, that is.
Comment 25 Jani Nikula 2014-04-10 12:15:44 UTC
*** Bug 77266 has been marked as a duplicate of this bug. ***
Comment 26 Luca Viggiani 2014-04-10 12:23:42 UTC
@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")?
Comment 27 Luca Viggiani 2014-04-10 12:48:37 UTC
@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
Comment 28 Jani Nikula 2014-04-10 13:37:00 UTC
(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.
Comment 29 Luca Viggiani 2014-04-13 17:18:04 UTC
@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.
Comment 30 Jani Nikula 2014-04-16 21:03:13 UTC
(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?
Comment 31 Mike C 2014-04-20 20:40:31 UTC
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?
Comment 32 Mike C 2014-04-20 20:55:49 UTC
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.
Comment 33 Mike C 2014-04-21 16:03:24 UTC
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)
Comment 34 Mike C 2014-04-21 17:14:16 UTC
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)
Comment 35 Jani Nikula 2014-04-22 11:47:03 UTC
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.
Comment 36 Mike C 2014-04-26 18:38:44 UTC
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.
Comment 37 Jani Nikula 2014-04-28 10:13:39 UTC
(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
Comment 38 Jani Nikula 2014-04-28 10:21:04 UTC
(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
Comment 39 Mike C 2014-05-05 20:36:59 UTC
(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].
Comment 40 Mikkel Oscar Lyderik 2014-05-12 23:49:57 UTC
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?
Comment 41 Jani Nikula 2014-05-13 06:44:14 UTC
(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.
Comment 42 Jani Nikula 2014-05-15 04:55:38 UTC
(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! ;)
Comment 43 Adam Kolakowski 2014-05-15 07:27:36 UTC
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?
Comment 44 Jani Nikula 2014-05-15 07:56:54 UTC
(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.
Comment 45 Luca Viggiani 2014-06-03 11:08:16 UTC
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.