Bug 43577 - [SNB] KMS with intel sandy bridge video sets brightness to zero.
[SNB] KMS with intel sandy bridge video sets brightness to zero.
Status: RESOLVED NOTOURBUG
Product: DRI
Classification: Unclassified
Component: DRM/Intel
unspecified
x86-64 (AMD64) Linux (All)
: medium blocker
Assigned To: Jani Nikula
Intel GFX Bugs mailing list
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-07 05:16 UTC by Gustavo Vieira
Modified: 2013-11-15 05:32 UTC (History)
5 users (show)

See Also:
i915 platform:
i915 features:


Attachments
dmesg with debug on (121.24 KB, text/plain)
2011-12-07 05:18 UTC, Gustavo Vieira
no flags Details
dmesg with drm.debug=0xe (111.12 KB, text/plain)
2011-12-07 07:59 UTC, Gustavo Vieira
no flags Details
dmesg with drm.debug=0xe for HP Envy4t w/3rd Gen Core i5 (83.25 KB, text/plain)
2012-09-06 15:48 UTC, Ben
no flags Details
i915_opregion while screen is dark (21.86 KB, text/plain)
2012-09-07 02:13 UTC, Ben
no flags Details
dmesg, after adding dump_stack (134.83 KB, text/plain)
2012-09-11 12:47 UTC, Ben
no flags Details
drm/i915: set the BIOS current backlight level (3.46 KB, patch)
2012-12-10 16:30 UTC, Jani Nikula
no flags Details | Splinter Review
Result of acpidump (333.52 KB, text/plain)
2013-11-15 01:15 UTC, Gustavo Vieira
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gustavo Vieira 2011-12-07 05:16:55 UTC
In early boot, when the kernel sets the mode in a mobile intel sandy bridge video
adapter the brightness is set to zero. The display then becomes unreadable.

If I disable KMS, the problem disappears.

If I boot in text mode (no X involved) the problem persists as long as KMS is
enabled.

If I boot a Live CD that starts a desktop session automaticaly, I can increase the brightness using the brightness controls. The workaround is to put: echo 7 > /sys/class/backlight/acpi_video0/brightness in some initialization script.

I'm using Fedora 16 with 3.1 kernel, but the problem persists with 3.2-rc4.
Comment 1 Gustavo Vieira 2011-12-07 05:18:18 UTC
Created attachment 54180 [details]
dmesg with debug on
Comment 2 Chris Wilson 2011-12-07 05:33:05 UTC
drm.debug=0x4 doesn't include the details about the panel backlight, you need to use drm.debug=0xe. Can you please attach the boot dmesg with the increased verbosity?
Comment 3 Gustavo Vieira 2011-12-07 07:59:47 UTC
Created attachment 54184 [details]
dmesg with drm.debug=0xe

You are right.

In this log it's possible to see at 12.82s the point where my workaround kicks in and the brightness is set to 7. Before that, it's the normal driver operation.
Comment 4 Daniel Vetter 2012-03-31 08:01:22 UTC
Please retest with 3.4-rc1 (or the latest git snapshot if -rc1 isn't out there yet when you try to test). That contains a few backlight fixes which might help in your case here.
Comment 5 Jesse Barnes 2012-04-23 11:04:07 UTC
Ok assuming this one is fixed since the reporter hasn't responded.

Gustavo, please re-open if not.
Comment 6 Gustavo Vieira 2012-06-19 12:06:52 UTC
I've retested with kernel 3.4.2 (as packaged by Fedora: kernel-3.4.2-1.fc16.x86_64) and the problem is still present.
Comment 7 Daniel Vetter 2012-06-19 12:11:30 UTC
Gustavo, can you please test the drm-intel-next-queued git branch from

http://cgit.freedesktop.org/~danvet/drm-intel

That contains patches that are know to fix some backlight issues on snb.
Comment 8 Gustavo Vieira 2012-06-22 06:32:28 UTC
Tested drm-intel-next-queued as of today and the problem is still present.
Comment 9 Daniel Vetter 2012-08-22 11:01:00 UTC
Presumably fixed with

commit 6db65cbb941f9d433659bdad02b307f6d94465df
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jun 21 15:30:41 2012 +0200

    drm/i915: Fix eDP blank screen after S3 resume on HP desktops

Which is merged into 3.5, cc stable kernels.
Comment 10 Gustavo Vieira 2012-08-22 13:25:02 UTC
Tested with 3.4.9 (Fedora 3.4.9-1.fc16.x86_64), that includes this commit and the problem persists.

More information: 1) This bug appears at system boot, not on S3 resume. Suspend and resume work perfectly. 2) This bug shows on a display connected on LVDS.
Comment 11 Ben 2012-08-27 04:24:19 UTC
I have the same problem with an Ivybridge machine (HP Envy 4t Laptop).  Brightness is set to 0 during kms enable upon first boot. (I select the kernel in Grub -> few moments later the screen goes dark.)

Workaround is to hit Fn-F3 to brighten the display.  The display appears to be working, just that brightness is 0.

If there was a workaround to script brightening the display in userland, that would be acceptable as a fix for me (but this should be a kernel issue?)...
Comment 12 Ben 2012-08-27 04:33:34 UTC
Ok I also wanted to mention that this was observed in 3.4.9-Gentoo. I'm not sure what happened to that statement when I did the initial post.  The backlight turns off before init gets called.

I just verified that setting a new value into /sys/class/backlight/acpi_video0/brightness works, and this is enough of a workaround for me for now (but it does get somewhat annoying when looking at the boot log trying to debug other startup issues, it's a fresh install.)
Comment 13 Ben 2012-09-03 19:21:01 UTC
Tried Linux kernel general release 3.5.2 - problem still exists.

I wish this laptop had a serial port so that I could slow the boot sequence down to see exactly when the screen goes dark, but it happens within the first 3 seconds of boot, I'm lucking if I can catch init.

In my dmesg (similar to Gustavo's except the times are different) I see PWM set to 0 at 0.9s, then back to max at 1.6s, then set to 0 at 1.7s.  Best I can do is assume when the PWM is set it's exactly when the event happens.
Comment 14 Daniel Vetter 2012-09-04 07:55:50 UTC
From your description it sounds more like something from userspace sets the brightness to 0 at boot, since brightness controls seem to work as advertised.

Also, the intel_backlight is only a fallback in case your firmware doesn't expose anything else, userspace /should/ prefer the acpi backlight controller (or any other more specific backlight exposed by the firmware).

No much idea what's going on here unfortunately ...
Comment 15 Ben 2012-09-05 07:16:03 UTC
I tried booting without my initramfs, setting init=/bin/bash and root=/dev/sda3 (my hard drive so it can find bash).  The screen still goes dark and stays dark until I fn-F3 to brighten it.  This should show that it's the kernel darkening the display before init runs (unless bash does something weird...)

I see both /sys/class/backlight/acpi_video0/brightness and /sys/class/backlight/intel_backlight/brightness but dmesg all reports intel_backlight. Not sure why the kernel itself is not using ACPI?  Not sure how this should work...
Comment 16 Jani Nikula 2012-09-06 09:25:39 UTC
(In reply to comment #15)
> I tried booting without my initramfs, setting init=/bin/bash and root=/dev/sda3
> (my hard drive so it can find bash).  The screen still goes dark and stays dark
> until I fn-F3 to brighten it.  This should show that it's the kernel darkening
> the display before init runs (unless bash does something weird...)
> 
> I see both /sys/class/backlight/acpi_video0/brightness and
> /sys/class/backlight/intel_backlight/brightness but dmesg all reports
> intel_backlight. Not sure why the kernel itself is not using ACPI?  Not sure
> how this should work...

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 keys.
Comment 17 Jani Nikula 2012-09-06 11:57:15 UTC
(In reply to comment #11)
> I have the same problem with an Ivybridge machine (HP Envy 4t Laptop). 
> Brightness is set to 0 during kms enable upon first boot. (I select the kernel
> in Grub -> few moments later the screen goes dark.)
> 
> Workaround is to hit Fn-F3 to brighten the display.  The display appears to be
> working, just that brightness is 0.

Please also attach your dmesg with drm.debug=0xe, from boot until and including you using Fn-F3 to brighten the display. Thanks.
Comment 18 Ben 2012-09-06 15:48:27 UTC
Created attachment 66737 [details]
dmesg with drm.debug=0xe for HP Envy4t w/3rd Gen Core i5

Getting the dumps have been trickier than I thought (specifically the opregion), will try to revert back to default Gentoo setup as it sets up all directories automatically (and more importantly loads all modules...)

I'd say the critical moment is why the kernel is setting PWM = 0 at around time = 1.108192.  At 1.449732 it again sets it to 0, but 300ms later at 1.756318 it turns it on full blast.  50 milliseconds later, at 1.807509 it shuts it off once more.  (I do not see the blinking so I don't know if this really is happening, then again a 50 ms blink with possible low pass filtering in the backlight circuitry, not sure if I can see it.)  Around the time 16, that's when I had my startup script write a new value into brightness, making the screen visible again.  My guess is around time 7.706841 is when my initramfs starts, there are tell tale signs after this point.

Again, the order of events seems very similar to Gustavo's log.
Comment 19 Ben 2012-09-07 02:13:19 UTC
Created attachment 66755 [details]
i915_opregion while screen is dark

Same machine but with kernel 3.4.9-gentoo

After screen is brightened, this is the diff between the two.

19c19
< 00000310  00 00 00 80 06 00 00 80  00 00 00 80 11 80 16 8a  |................|
---
> 00000310  19 00 00 80 06 00 00 80  09 00 00 80 11 80 16 8a  |................|
Comment 20 Jani Nikula 2012-09-07 06:53:21 UTC
(In reply to comment #19)
> Created attachment 66755 [details]
> i915_opregion while screen is dark
> 
> Same machine but with kernel 3.4.9-gentoo
> 
> After screen is brightened, this is the diff between the two.
> 
> 19c19
> < 00000310  00 00 00 80 06 00 00 80  00 00 00 80 11 80 16 8a 
> |................|
> ---
> > 00000310  19 00 00 80 06 00 00 80  09 00 00 80 11 80 16 8a  |................|

The difference is in the opregion requested backlight brightness, 0x00 vs. 0x19 out of maximum 0xff. The 0x80 at offset 0x313 indicates the value is valid. The request comes through ACPI, and kernel sets what ACPI asks. (Perhaps this also answers your question about ACPI in comment #15.)

Indeed, AFAICT the below intel_panel_get_max_backlight(), intel_panel_actually_set_backlight() sequence is only possible on ACPI requests, but since we don't have debugs there, I can't be 100% sure.

[    1.807427] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882
[    1.807430] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4882
[    1.807507] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882
[    1.807509] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0

Why the ACPI would change its mind about the brightness it wants in less than a 1 ms, I have no idea.
Comment 21 Ben 2012-09-11 06:22:26 UTC
New data:

I think I have found something interesting:

The bug is some sort of race condition.  Not knowing about how to debug this I tried to make it dump the stack when setting the PWM in gpu/drm/i915/intel_panel.c

With this instrumentation the backlight will turn off during initialization (seems that the code will shut off all panels) but will turn the panel backlight back on within a second, enough to start dumping the rest of the boot sequence to the display.)

Unfortunately since this seems to be a race condition of sorts, the stack dumps probably isn't very useful...

Hmm... still seeing if I can collect additional data as to why it's setting it back to 0.
Comment 22 Jani Nikula 2012-09-11 07:36:44 UTC
(In reply to comment #21)
> With this instrumentation the backlight will turn off during initialization
> (seems that the code will shut off all panels) but will turn the panel
> backlight back on within a second, enough to start dumping the rest of the boot
> sequence to the display.)

I'd be interested in a dmesg with drm.debug=0xe on a boot where this happens.
Comment 23 Ben 2012-09-11 12:47:41 UTC
Created attachment 66969 [details]
dmesg, after adding dump_stack

based on the call traces,

1.046240 backlight off (init, lvds disable)
1.376800 backlight off (this call I don't understand)
1.711346 backlight full blast (lvds enable)
1.802276 backlight full blast (appears to be user mode setting as witnessed by the call stack which matches future calls?)
11.028084 backlight on at level 2, this I'm pretty sure is the user mode setting of the backlight in by boot scripts.
Subsequent calls I think is Gnome/X11 slowly brightening the display during boot.

I could understand why during init, to shut everything down once and re-enable once, the second calls to each I don't...

Comparing back to the original dmesg, the 1.807509 setting should not have happened.  However the instrumentation caused the code to behave different which is weird.
Comment 24 Ben 2012-09-11 13:57:39 UTC
Again some kernel hacking newbieness here, I don't know what functions are reentrant or legal so I'm sure I'll get strange results, all part of learning...

I tried adding a msleep() into intel_panel_actually_set_backlight instead of causing dumps.   msleep(20) didn't appear to do anything (behavior same as before) but larger values caused bad things to happen - but msleep() of 50, 100, and 200 cause the kernel to endless loop freeze (seems msleep()ing there for a while is bad for whatever reason.)

BUT...

The display is ON without Fn-F3'ing and I could see the endless loop crash happening!
Comment 25 John C 2012-09-28 03:59:21 UTC
I have an HP Envy 3040nr and my screen backlight is set to zero upon boot. I have to set the brightness up everytime. This is present on Arch Linux (my main distribution), Ubuntu, Mint, Fedora, and Suse.
I have the latest kernel 3.5.4
Here are my laptop specs:
http://www.newegg.com/Product/Product.aspx?Item=N82E16834158219
Comment 26 Jani Nikula 2012-09-28 07:29:20 UTC
(In reply to comment #25)
> I have an HP Envy 3040nr and my screen backlight is set to zero upon boot. I
> have to set the brightness up everytime. This is present on Arch Linux (my
> main distribution), Ubuntu, Mint, Fedora, and Suse.
> I have the latest kernel 3.5.4
> Here are my laptop specs:
> http://www.newegg.com/Product/Product.aspx?Item=N82E16834158219

We would prefer separate bug reports unless you have the insight to be quite sure this is the same bug as reported here. It's easy to resolve extra bugs as duplicates, but it can get fairly confusing if data for two distinct bugs start to accumulate on one bug.

On the new bug report, please attach dmesg with drm.debug=0xe. The newegg link says the machine has Radeon graphics - do you have that disabled? This bug is about Intel graphics. What does "upon boot" mean? Is the backlight off when you turn on the machine, or does the backlight switch off during KMS?
Comment 27 Ben 2012-10-17 02:43:32 UTC
On my airplane flight I decided to mess with this a bit.  I think msleep() is illegal this routine so I ditched this route.  For kicks I tried putting in a spinloop (which is bad, as it's CPU speed dependent).

When I did this:


static void intel_panel_actually_set_backlight(struct drm_device *dev, u32 level)
{
        volatile int foo;
        struct drm_i915_private *dev_priv = dev->dev_private;
        u32 tmp;

        DRM_DEBUG_DRIVER("set backlight PWM = %d\n", level);
/*
 * need a 1ms or so delay.  Cannot schedule a msleep here, and no usleep?
 */
        for(foo=0;foo<555555;foo++);
        level = intel_panel_compute_brightness(dev, level);

        if (HAS_PCH_SPLIT(dev))
                return intel_pch_panel_set_backlight(dev, level);


the display now turns on again after being shut off during initialization.  If anyone else with this issue would like to try this patch, it's definitely not clean but at least it seems to help the issue...  I used the 555555 as it seems to work on my i5-3317u without killing boot times too much, may need to tweak for other CPUs, or find a cleaner solution.
Comment 28 Chris Wilson 2012-10-17 08:00:15 UTC
A more important question is what is the delay required after? A delay here kind of suggests that your firmware is broken.
Comment 29 Daniel Vetter 2012-10-17 08:17:32 UTC
Shot in the dark: Can you please try with latest drm-intel-fixes (or upstream 3.7-rc1), specifically the following commit?commit d627b62ff8d4d36761adbcd90ff143d79c94ab22                                                                                      
Author: Lekensteyn <lekensteyn@gmail.com>                                                                                            
Date:   Tue Jun 26 00:36:24 2012 +0200                                                                                               
                                                                                                                                     
    i915: initialize CADL in opregion
Comment 30 Ben 2012-10-18 12:10:06 UTC
I just tried 

Linux mikuru 3.7.0-rc1 #1 SMP Wed Oct 17 21:49:25 MDT 2012 x86_64 Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz GenuineIntel GNU/Linux

The kernel still does not turn the backlight back on and thus dark until usermode does so.
Comment 31 Gustavo Vieira 2012-10-18 15:10:55 UTC
Bug still present with latest drm-intel-fixes.

Based on my experience with HP laptops, I would bet on a firmware bug that needs to be worked around. When this machine boots Win7, it turns off the display briefly before de mouse cursor appears.
Comment 32 Ben 2012-10-19 05:12:48 UTC
If this really is some firmware bug then who's the contact to HP to fix this?
Apparently there are at least two, maybe three HP machines that have this
issue and no other manufacturers?  Or will a workaround need to be used?

I accidently found a position where a delay seemed to help, so I don't know
why it works... It was dumb luck that it seemed to be some sort of race
condition trying to figure out how/why it ran each set_brightness and I'm sure
there are other places where the delay could work...

If anyone is interested in my hacky workaround patch to verify if our machines are all having the same problem, this is against 3.7-rc1 but I didn't actually test it against that, this was tested against 3.4.9 and 3.5.2 (with fuzz), however (or just manually edit the file ala above comment.)  I believe the randomly selected constant 555555 will work for any Core CPU except maybe an overclocked machine (rough guess at how many loop iterations plus fuzz to get 1ms), but don't be tweaking this number just to see if it works...  Assume it fails (unless you really want to play with it :)

diff -ru linux-3.7-rc1-orig/drivers/gpu/drm/i915/intel_panel.c linux-3.7-rc1/drivers/gpu/drm/i915/intel_panel.c
--- linux-3.7-rc1-orig/drivers/gpu/drm/i915/intel_panel.c       2012-10-14 15:41:04.000000000 -0600
+++ linux-3.7-rc1/drivers/gpu/drm/i915/intel_panel.c    2012-10-18 22:42:23.869985519 -0600
@@ -258,6 +258,8 @@
 {
        struct drm_i915_private *dev_priv = dev->dev_private;
        u32 tmp;
+       volatile loopfoo;
+       for(loopfoo=0;loopfoo<555555;loopfoo++);

        DRM_DEBUG_DRIVER("set backlight PWM = %d\n", level);
        level = intel_panel_compute_brightness(dev, level);
Comment 33 Gustavo Vieira 2012-10-26 13:44:19 UTC
I
Comment 34 Gustavo Vieira 2012-10-26 14:01:34 UTC
I've tested with the delay of comment 32 and the display isn't dark anymore. However, strangely, when the login screen appears it sets the brightness to zero again. This time it is surely a userspace thing, but the brightness controls are a bit weird, with only 5 steps instead of 10. Might be unrelated though, because I patched drm-intel-fixes instead of 3.6.

Anyway, even though random delays don't appear to the a reasonable workaround, I suppose we have found a way to identify the problem. My machine, a HP dm4-2035br, and the HP Envy 4t probably share the same problem. I know another owner of a dm4 (different model) with the same problem. Yes, it's an HP thing...
Comment 35 Ben 2012-10-27 02:31:03 UTC
I just tested the patch against 3.7-rc1 proper and it also now exhibits the expected behavior.

That is weird that the user space issue is also plaguing the machine.  I suppose Gnome is saving some state that is kept in user preferences, I wonder if it will also poll the current state or use the same "brightness" setting available in the kernel regardless if it's via intel direct or ACPI if they use different values to mean the same brightness level... Hmm.  (Looks like GNOME for me also has 6 levels, with level 1 being backlight off.)

I suppose until we get a real patch (and it's probably HP that needs to do it?) I will have to hack my kernels with the delay so I can see bootup status (and my penguins:)) without having to turn on brightness...

How *does* the firmware get used in the brightness interface anyway? ACPI DSDT firmware or something to that extent?
Comment 36 Daniel Vetter 2012-10-27 10:53:36 UTC
On Sat, Oct 27, 2012 at 4:31 AM,  <bugzilla-daemon@freedesktop.org> wrote:
> How *does* the firmware get used in the brightness interface anyway? ACPI
> DSDT firmware or something to that extent?

This is unfortunately a question that can't be answered by mere
mortals. Our best guess for now is:
- with some magic platform specific thing (think all the
vendor/platform specific acpi modules in the kernel)
- with the normal acpi backlight (maybe, if that doesn't disable it)
- with the native backlight controller in the hw (but some vendoers
that use this manage to wire it up the wrong way to the pwm, so we
need to invert the values)
- through the opregion interface (where the driver gets sent change
requests, which it can deny or accept)
- through SMM and special firmware-only interrupts generate when
writing specific registers

Plus any funny interractions of the above: E.g. write the backlight
value to the native backlight controller, which generates a special
SMM interrupt to the firmware, which the generates the opregion
request, which the driver feeds back to the firmware, which then
adjusts the backlight. Or so goes the story, but only if all the
things in between work out correctly. We know that random vendor
firmware checks random (acpi) tables for random things, so we try to
fake them as well as possible ...
Comment 37 Ben 2012-10-30 00:01:51 UTC
If HP does not do anything, how can we close this bug?  I don't think we can "assign" this to HP here?

Though I can "fix" this myself for my own kernel builds, I suspect there are many people completely baffled by this behavior in different distributions.  One notable example is the GNU Parted bootable CD, which incidently is x86 and not x86_64.  A Windows user tries to run it and the screen goes dark...

Perhaps we can live with a delay.  How would one be accepted into the kernel?  What would be needed if HP does not pony up the info needed?  Spinloops like what I have are surely no-go but maybe something similar somewhere would be acceptable?
Comment 38 Daniel Vetter 2012-10-30 08:02:49 UTC
Sleeps are a no-go since our boot time already takes too long - we're trying hard to shave off delays ...
Comment 39 Ben 2012-10-31 16:18:47 UTC
Next thing I'd try is to add another call to brighten the display as a workaround, where would be an appropriate call near the end of the initialization routines to call brightness one last time before handoff to the rest of the kernel boot?
Comment 40 Jesse Barnes 2012-11-14 17:04:29 UTC
(In reply to comment #23)
> Created attachment 66969 [details]
> dmesg, after adding dump_stack
> 
> based on the call traces,
> 
> 1.046240 backlight off (init, lvds disable)
> 1.376800 backlight off (this call I don't understand)
> 1.711346 backlight full blast (lvds enable)
> 1.802276 backlight full blast (appears to be user mode setting as witnessed
> by the call stack which matches future calls?)
> 11.028084 backlight on at level 2, this I'm pretty sure is the user mode
> setting of the backlight in by boot scripts.
> Subsequent calls I think is Gnome/X11 slowly brightening the display during
> boot.
> 
> I could understand why during init, to shut everything down once and
> re-enable once, the second calls to each I don't...
> 
> Comparing back to the original dmesg, the 1.807509 setting should not have
> happened.  However the instrumentation caused the code to behave different
> which is weird.

That second call is from the fbdev initial configuration code.  It first tries to disable everything, then build a config based on what outputs have been detected.

The last one at 1.802 is ACPI requesting a change through a interrupt, which could be due to userspace asking for a change through the ACPI backlight interface, or could be spontaneous.  Since it happens right at the end of driver init when we init the ACPI video interface, it could be part of the firmware's ACPI video init, and not from userspace.

But according to that log, the backlight PWM value should be nonzero after the driver loads... but you saw a blank screen?

As for adding a "set to max brightness" at the end somewhere, we'd probably want to do it around the time we set up the fbcon for the device.  Ideally right when we set the mode for fbcon, so we don't get a dim fbcon that then goes to full brightness slightly after.
Comment 41 Gustavo Vieira 2012-11-14 17:22:29 UTC
(In reply to comment #40)
> 
> But according to that log, the backlight PWM value should be nonzero after
> the driver loads... but you saw a blank screen?

This specific log is about a situation where a dump stack makes the problem vanish. So, yes, in this case the screen is not blank. You might be interested in the traces of comment #3 and comment #18.
Comment 42 Ben 2012-11-14 20:46:32 UTC
Correct, in the dmesg with the traces we cannot use for debugging this issue because the back light is turned on properly with the instrumentation, which implies we are likely dealing with a race condition with unknown contestants. Likely the firmware triggering an interrupt unexpectedly after the kernel does something.  However it helped me understand what the correct sequence of events.

The key is how we can figure out why this is occurring in the trace in comment #3:
[    3.038356] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882
[    3.038370] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4882
[    3.038570] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882
[    3.038579] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0

which is the same odd behavior as this trace in comment #18
[    1.807427] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882
[    1.807430] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4882
[    1.807507] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882
[    1.807509] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0

For some reason, around 170-200 microseconds after it sets the final backlight, a spurious call is made and sets the backlight to 0.

I just looked at freedesktop bug #40692 trace supplied which also has this telltale signature:
[    4.397699] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882
[    4.397705] [drm:intel_panel_actually_set_backlight], set backlight PWM = 4882
[    4.397783] [drm:intel_panel_get_max_backlight], max backlight PWM = 4882
[    4.397785] [drm:intel_panel_actually_set_backlight], set backlight PWM = 0

(just wanted to cross link these two bugs as they smell very similar, but Dan's right, we can't dupe these together just yet.)
Comment 43 Jani Nikula 2012-12-10 16:30:35 UTC
Created attachment 71276 [details] [review]
drm/i915: set the BIOS current backlight level

It's a long shot, but could you try the attached patch? It's on top of drm-intel-next-queued, but might apply on Linus' master too. It just might help with the BIOS <-> driver co-operation here.
Comment 44 Daniel Vetter 2012-12-11 09:47:16 UTC
Maybe-related: https://bugzilla.kernel.org/show_bug.cgi?id=47941
Comment 45 Jesse Barnes 2012-12-11 18:28:22 UTC
poke.  Any chance to test Gustavo?
Comment 46 Ben 2012-12-11 21:42:26 UTC
The kernel.org bug appears to be on a Dell, and he mentions that his brighten/darken ACPI keys do not work so it may not be the same problem... it would be interesting if this problem also afflicted machines that weren't HPs...
Comment 47 Jani Nikula 2012-12-12 07:57:09 UTC
(In reply to comment #46)
> The kernel.org bug appears to be on a Dell, and he mentions that his
> brighten/darken ACPI keys do not work so it may not be the same problem...
> it would be interesting if this problem also afflicted machines that weren't
> HPs...

Well, the patches did not help the problem there, maybe try them for your issue?
Comment 48 Ben 2012-12-12 08:52:11 UTC
I just tried attachment 71276 [details] [review] patch against 3.7-release and the display still goes dark upon KMS init and remains dark until brightened by Fn-F3.
Comment 49 Ben 2012-12-13 09:06:31 UTC
I also tried that kernel.org attach-patch 88981 coupled with the patch described in the previous comment on the same 3.7 kernel, and still greeted with darkness...
Comment 50 Gustavo Vieira 2012-12-13 12:53:37 UTC
Same here, the proposed patch, tested with drm-intel-next-queued does not solves the problem.
Comment 51 Gustavo Vieira 2013-03-07 02:12:35 UTC
Found the problem and a solution. Apparently it is a BIOS bug where it is claimed the display uses minimum backlight at boot. 

More info: https://bugzilla.kernel.org/show_bug.cgi?id=21212 and https://bugzilla.kernel.org/show_bug.cgi?id=51141

The solution is to put video.use_bios_initial_backlight=0 in the kernel command line. A more definitive fix is to add this laptop to a white list of machines needing this parameter. I've made a patch to fix it and have sent it to the ACPI list: http://www.spinics.net/lists/linux-acpi/msg42467.html
Comment 52 Daniel Vetter 2013-03-07 09:05:19 UTC
Awesome. Since it's an acpi bug and not something wrong with drm/i915 I'll close this report now.
Comment 53 Gustavo Vieira 2013-11-15 01:15:17 UTC
Created attachment 89242 [details]
Result of acpidump

Attaching acpidump as requested in linux-acpi@vger.kernel.org. Hope you don't mind. :)
Comment 54 Jani Nikula 2013-11-15 05:32:00 UTC
Gustavo, please try linux-next branch of [1]. There are fixes for initial backlight issues, headed for 3.13.

[1] http://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git