Bug 40692 - [SNB] fails to enable backlight
[SNB] fails to enable backlight
Product: DRI
Classification: Unclassified
Component: DRM/Intel
Other Linux (All)
: medium normal
Assigned To: Daniel Vetter
Intel GFX Bugs mailing list
Depends on:
  Show dependency treegraph
Reported: 2011-09-07 11:42 UTC by Samuel Sieb
Modified: 2013-11-18 20:37 UTC (History)
4 users (show)

See Also:

dmesg (48.58 KB, text/plain)
2011-09-21 14:37 UTC, Samuel Sieb
no flags Details
dmesg log with drm.debug=0xe (140.06 KB, text/plain)
2012-09-01 05:05 UTC, Samuel Sieb
no flags Details
opregion before (14.46 KB, text/plain)
2012-09-07 20:03 UTC, Samuel Sieb
no flags Details
opregion after using backlight keys to set full brightness (14.46 KB, text/plain)
2012-09-07 20:09 UTC, Samuel Sieb
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Samuel Sieb 2011-09-07 11:42:06 UTC
I have a laptop with a Sandybridge Mobile chipset.  As soon as KMS activates, the screen goes black.  As soon as X starts, it comes back on and works fine from there.  Also after X has started, the consoles work as well and I can see the shutdown screen.

Kernel version, also happened with 3.1.

The laptop is an HP Pavilion DM4-2055CA.  It has hybrid graphics, but that doesn't seem relevant as it still happens with the radeon driver disabled.

Further testing shows that I can turn the backlight right off using the backlight control keys, so I wonder if the issue is just that the backlight is somehow set to off when initializing.
Comment 1 Chris Wilson 2011-09-07 14:05:16 UTC
Just recently I've been reminded that the absence of the fbcon module loading leads to exactly this scenario. Can you please attach your dmesg from boot.
Comment 2 Samuel Sieb 2011-09-21 14:36:26 UTC
I didn't have access to the laptops for a while.  I have now discovered that it is just the backlight not getting turned on.  I added a line to change the backlight setting to max in the boot sequence and now it works.  So for some reason the KMS driver is either not setting it or is setting it to 0.

I will add the dmesg as well.
Comment 3 Samuel Sieb 2011-09-21 14:37:05 UTC
Created attachment 51471 [details]
Comment 4 Samuel Sieb 2012-04-17 20:30:03 UTC
I just upgraded one of the laptops to Fedora 16 and now it's worse.  I added the line to set the backlight brightness in the boot sequence again, but as soon as X starts, the backlight goes off again.  I can login remotely and turn it back on.

I found something very odd though when looking in /sys/class/backlight/intel_backlight.  "brightness" contains the same value as "max_brightness", but "actual_brightness" is 0.  If I write a value into "brightness", even if it's the same as the current value, the backlight comes on (as long as it isn't 0 of course).  I checked after X started and "brightness" contains the value that I set there during boot, but "actual_brightness" is back to 0 again.

Now I need to find some way to turn the backlight back on after X starts or these laptops will be useless...
Comment 5 Samuel Sieb 2012-04-17 20:33:19 UTC
When resuming, the backlight is on until X re-initializes.
Comment 6 Samuel Sieb 2012-04-17 21:10:52 UTC
I accidentally discovered that if I use the brightness function keys to change the brightness there is no longer any issue. Even after logging out or suspend and resume, the backlight is still on.  But when I used the brightness keys, it seemed to believe that the current value was 0.  And the value of "brightness" is not affected by the brightness keys, only the "actual_brightness" value.  So there is a disconnect somewhere.

I just found something more.  In /sys/class/backlight, there are actually three directories: acpi_video0, acpi_video1, and intel_backlight.  The first two are identical and their values track each other with a different scale than the intel one.  The acpi ones go to 10, the intel one goes to 4882.  If I set "brightness" in one of the acpi ones during boot, it sticks and I don't have any further issues, just as if I used the brightness keys.

So, my immediate concern is relieved, but it would be nice to have this working properly.
Comment 7 Chris Wilson 2012-05-11 07:17:49 UTC
Daniel is working on some patches to fix the backlight controller and is looking for victims^Wtesters.
Comment 8 Daniel Vetter 2012-05-11 07:19:52 UTC
Please add drm.debug=0xe to your kernel cmdline and attach the entire dmesg output.
Comment 9 Daniel Vetter 2012-06-05 07:10:03 UTC
Ok, I've created these patches, available at http://cgit.freedesktop.org/~danvet/drm/log/?h=backlight-confusion

Git link is git://people.freedesktop.org/~danvet/drm backlight-confusion

Please test them, thanks.
Comment 10 Daniel Vetter 2012-08-22 14:16:54 UTC
Reporter is awol, but presumably fixed with the recent pile of backlight fixes. Please reopen if this is still an issue on 3.5, thanks.
Comment 11 Samuel Sieb 2012-09-01 04:49:09 UTC
I only have occasional access to the affected laptops.  I currently have one and just tested it.  Using 3.5.2, it still has the same problem.  I will get that drm debug log for you.
Comment 12 Samuel Sieb 2012-09-01 05:05:58 UTC
Created attachment 66430 [details]
dmesg log with drm.debug=0xe

From the log:
[    4.399161] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882
[    4.399165] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4882
[    4.399229] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882
[    4.399231] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0

Every time it does something with the backlight, it sets it to 0.  At 35 seconds, you can see where the live image has booted and I start hitting the backlight keys.
Comment 13 Daniel Vetter 2012-09-01 09:33:29 UTC
Just to check: You have to hit the backlight keys to light up the screen, simply starting X doesn't magically light it up?
Comment 14 Samuel Sieb 2012-09-01 17:01:27 UTC
That is correct. The backlight level is at 0 when X starts, so using the backlight keys brings it up.
Comment 15 Samuel Sieb 2012-09-03 21:27:14 UTC
Further interesting data.  Right after booting (backlight still off), I looked in /sys/class/backlight/intel_backlight.  Here are the values:

actual_brightness: 0
brightness: 4882
max_brightness: 4882

If I do "echo 4882 > brightness", then actual_brightness becomes 4882.  So, for some reason, there is an initial disagreement between what the kernel thinks is set and what it actually is.
Comment 16 Samuel Sieb 2012-09-03 21:35:33 UTC
I just realized that I mentioned all that in a previous comment.  One thing that may not be clear from comment #6 is that if I set the value using the intel directory, the value does not stick and does not change the value in the acpi directory.  For example if I start X, the backlight goes back to the value set in the acpi directory.  However, if set it in the acpi directory, it sticks and the value in the intel directory is changed as well.
Comment 17 Jani Nikula 2012-09-04 11:10:07 UTC
The interfaces in /sys/class/backlight don't necessarily play too well together. Your userspace should prefer the firmware interfaces over raw interface ('cat type' in each backlight sysfs directory). IIUC the discrepancy you see between the acpi and intel backlight is caused by the intel backlight not informing the BIOS about the change in the reference brightness value. When acpi changes the brightness, it does not look at the actual brightness, but the previous *acpi* reference brightness when choosing the new brightness. I'm afraid this only explains one of the symptoms you describe, and I can't think of a way it could cause the original real problem here. I'll keep looking.
Comment 18 Jani Nikula 2012-09-06 11:34:52 UTC
Please attach the output of

  $ cat /sys/kernel/debug/dri/0/i915_opregion | od -t x1

when the display is dark, and after you've increased the brightness using the
Comment 19 Samuel Sieb 2012-09-07 20:03:20 UTC
Created attachment 66811 [details]
opregion before
Comment 20 Samuel Sieb 2012-09-07 20:09:21 UTC
Created attachment 66812 [details]
opregion after using backlight keys to set full brightness
Comment 21 Samuel Sieb 2012-09-07 20:11:47 UTC
It was actually /sys/kernel/debug/dri/1/i915_opregion, the radeon card is 0.
Comment 22 Jani Nikula 2012-09-10 06:31:41 UTC
$ diff opregion.dark opregion.light 
--- opregion.dark	2012-09-10 09:23:51.017883318 +0300
+++ opregion.light	2012-09-10 09:23:59.169883180 +0300
@@ -16,7 +16,7 @@
 0000660 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0001400 01 00 00 00 00 00 00 00 0f 00 00 00 00 00 00 00
-0001420 00 00 00 80 06 00 00 80 00 00 00 80 10 80 15 8a
+0001420 ff 00 00 80 06 00 00 80 64 00 00 80 10 80 15 8a
 0001440 1d 94 23 9e 2e a8 3e b2 52 bc 6d c6 8f d0 b9 da
 0001460 ff e4 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 0001500 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

The diff is that BIOS has changed its requested backlight brightness from zero to max, and consequently the driver has changed the reference current brightness level from zero to max.

It seems that either the BIOS wants the backlight off, or there's some bad interaction between the BIOS and the driver.
Comment 23 Ben 2012-10-31 16:17:37 UTC
Is this the same as bug 43577?

Comment 24 Daniel Vetter 2012-10-31 16:34:41 UTC
(In reply to comment #23)
> Is this the same as bug 43577?
> https://bugs.freedesktop.org/show_bug.cgi?id=43577

Could be, but please don't mark anything as duplicate until we have the bugfix to prove that both bugs are indeed fixed by the same patch. gfx bugs are hell to triage :(
Comment 25 Ben Widawsky 2013-04-18 22:57:33 UTC
Is this still a problem with the a 3.8+ kernel?
Comment 26 Chris Wilson 2013-06-12 12:32:56 UTC
Can you please test whether disabling the ACPI backlight ala https://patchwork.kernel.org/patch/2697681/ fixes the issue?
Comment 27 Samuel Sieb 2013-06-15 18:23:04 UTC
I wasn't able to test that patch, but the kernel command line parameter from Bug 43577 solves the issue.

Comment 28 Daniel Vetter 2013-11-18 17:50:50 UTC
Presumably fixed with latest drm-intel-nightly from


specifically Jani's backlight rework.
Comment 29 Samuel Sieb 2013-11-18 20:10:44 UTC
Which kernel will those changes get into?
Comment 30 Daniel Vetter 2013-11-18 20:37:20 UTC
3.14, so testing the mentioned branch is atm the only way.