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 2.6.40.3-0.fc15.i686.PAE, 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.
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.
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.
Created attachment 51471 [details] dmesg
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...
When resuming, the backlight is on until X re-initializes.
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.
Daniel is working on some patches to fix the backlight controller and is looking for victims^Wtesters.
Please add drm.debug=0xe to your kernel cmdline and attach the entire dmesg output.
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.
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.
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.
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.
Just to check: You have to hit the backlight keys to light up the screen, simply starting X doesn't magically light it up?
That is correct. The backlight level is at 0 when X starts, so using the backlight keys brings it up.
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.
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.
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.
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.
Created attachment 66811 [details] opregion before
Created attachment 66812 [details] opregion after using backlight keys to set full brightness
It was actually /sys/kernel/debug/dri/1/i915_opregion, the radeon card is 0.
$ 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.
Is this the same as bug 43577? https://bugs.freedesktop.org/show_bug.cgi?id=43577
(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 :(
Is this still a problem with the a 3.8+ kernel?
Can you please test whether disabling the ACPI backlight ala https://patchwork.kernel.org/patch/2697681/ fixes the issue?
I wasn't able to test that patch, but the kernel command line parameter from Bug 43577 solves the issue. video.use_bios_initial_backlight=0
Presumably fixed with latest drm-intel-nightly from http://cgit.freedesktop.org/~danvet/drm-intel/ specifically Jani's backlight rework.
Which kernel will those changes get into?
3.14, so testing the mentioned branch is atm the only way.
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.