I think I alone have filed this bug or similar at least two times. So have others. It's circulating on the internet for more than year. I've been affected by it, though not as severly as others, from the beginning, but at a certain point it got worse: First backlight would turn off on boot and had to be brought up manually, then it couldn't even be brought up by normal means and the lid had to be closed for the light to light (as other have reported before I was hit by that). The symptops changed at some point between 2.6.24 and 2.6.29. For several, irrelevant reasons, it remained rather vague though. The hardware on which this bug typically ocurrs is HP Touchsmart tm-2 Notebooks (with dual graphics). Arrandale i915 Intel Graphics IGD and ATI 5450 (Cedar) DIS. The bug: Startup, switching into KMS with Intel, as it happens on Boot, renders the screen blank, Backlight off. Pressing the BIOS keys which are meant to increase/decrease brightness do change the desired value as it is recorded by the kernel, but do not bring the backlight on. The backlight can be brought on by closing the lid (!) (It also immediately turns off, because the lid is closed but then properly reignites when opening it again). It then goes to the highest possible brightness and from then on can be controlled by the BIOS function keys and writing to the kernel file for brightness. Unless it is brought down to minimal brightness, which means tunred off, that is when it cannot be illuminated again. The whole thing also depends on whether the computer is connected to AC power or not. Surprisingly backlight does ignite from the off-state if you call xrandr in a specific order, rotate from 0° to 90°. Following is a description (more complete) I gave a while back on the list. Once kernel.org is up again, you might consult: https://bugzilla.kernel.org/show_bug.cgi?id=34582 https://bugs.freedesktop.org/show_bug.cgi?id=36823 https://bugzilla.kernel.org/show_bug.cgi?id=37282 The laptop has a convertible capacitive touchscreen which also features a wacom tablet layer. Like most laptops, the FX function keys have alternative functions assigned to them, which can be accessed by holding the Fn-key (or not, so the Fn-key has to be held to access their regular FX-use, if a special BIOS option is set). F2 and F3 have the special meaninf of decreasing and increasing brightness respectively, henceforth called BINC and BDEC. There are two graphic cards, a discrete Radeon HD 5450 [1002:68e0] and an Intel onboard [8086:0046] which runs with i915. The whole system is set up for vgaswitcheroo, the default on boot is the i915 which immediately goes into KMS (has to) Until recently, more specifically: until I had the computer in for repairs to replace the screen for the wacom was faulty - the screen blanked on boot [2]. Though bloody annoying, the cause could at least be somewhat found: ACPI wasn't working properly [3]. Backlight could then be brought back on by pressing BINC - at least when the intel card was switcheroo'ed on. The DIS radeon wouldn't acknowledge backlight at all, once activated. Since the computer got back from repairs and I installed a brand new system with 39.1 stable (gentoo, by the way), things got ugly: The screen blanks upon boot as before. Booting 39.1, the BINC is rendered useless. You can press it, but contrary to before, it will not ignite the backlight. The desired backlight brightness increases, but the screen wont ignite unless closed and re-opened, when it goes to the desired brightness. Now the witchcraft starts: When you boot into 38.8 (mind that before the pc was in for repairs, some 39-next was running) and THEN boot into 39.1 - from a complete power off or just a reboot, it doesn't matter - the BINC works! BUT it works only for the first time to ignite the backlight. BDEC'ing it to be OFF again, and trying to re-ignite it a second time may work or may not. A pure matter of luck. You may be able to BDEC/OFF the backlight a dozen times in a row and suddenly, the next time, it stops working and wont start working unless you boot into 38.8 again (or, under rare circumstances, until you boot again). Not crazy enough? Here comes the burner: As already pointed out in [2], xrandr plays a significant role in this drama: Assuming a situtation in which (39.1) BINC from OFF has ceased to work, there is, besides the method of closing and re-opening the lid, another method which, so far, worked reliably: Rotating the screen by xrandr BY EXACTLY +-90 DEGREES Rotating by anything but 90 degrees will not do, but rotating by exactly 90, from either inverted, left, right, or none to a 90 rotated will work with certainty. If the desired brightness, as indicated through the presses of BINC or BDEC, indicated in /sys/class/backlight/.../brightness device is still 0, the backlight goes to full power when doing so. If the desired brightness is another value, the backlight will go to the desired value.
By today, I've had the LCD replaced three times, the motherboard once, and three BIOS updates ran, because I suspected it to be an inverter/HW issue. Since the issue is still not resolved and there is no indication of it in windows, I must strongly assume it is in the kernel.
Created attachment 51920 [details] [review] obey backlight power sequencing delays Please test this kernel patch and report if anything changes in the backlight behavior. No high hopes that this fixes it, but imo worth a try.
(In reply to comment #2) > Created an attachment (id=51920) [details] > obey backlight power sequencing delays > > Please test this kernel patch and report if anything changes in the backlight > behavior. > > No high hopes that this fixes it, but imo worth a try. No. I noticed a slight difference in the flicker when the backlight initially turns off, but other than that and also in particular regard to bringing the backlight back on, there is no change. Please refer to [1] for additonal information. Though there is nothing significant new, it is worth noting that the kernel succeeds in bringing the backlight up, in the following cases: *Laptop lid is opened after closed for a few seconds (upon closing the lid, the backlight shortly flickers on, to then go off and go on again, if the lid is opened after a few seconds) *Xrandr rotates the screen while X is running with its driver *The unit is on battery power and THERE HAS NO ATTEMPT BEEN MADE to turn the backlight on/increase brightness while the unit is on AC, since the backlight went off the last tiem *The backlight is turned back on due to resuming from turning the screen off in a screensaver-fashion or the system comes back from any sort of power safe, such as suspend
[1] is [1] http://marc.info/?l=linux-acpi&m=131749369005052&w=2
This looks like a duplicate of bug 36823.
(In reply to comment #5) > This looks like a duplicate of bug 36823. No it is not, as explained there. No need to suggest it in both threads redundantly.
I also noticed that it appears not to depend on the manner in which the backlight turned off, but exclusively on the manner in which it is tried to be turned on. If, for example, no attempt to turn the backlight on while on AC after it has gone off on boot has been made, and instead we wait a bit so that the power-save type of blank-screen "would" turn it off, it will successfully ignite after "any key" press, which returns from the power-save type of blank-screen (if no measures have been taken, it will immediately go off again, though, because the "desired brightness" is still 0 at that point, due to the bug on boot.). Any suggestion would be greatly appreciated!
There was one recent patch on LKML related to backlight value saving - http://lkml.org/lkml/2011/10/13/95 - could you please try it?
(In reply to comment #8) > There was one recent patch on LKML related to backlight value saving - > http://lkml.org/lkml/2011/10/13/95 - could you please try it? It does what it say on the box: The backlight doesn't initially go to the brightest state after opening the lid. Other than that, there is no change, esp. with regard to not being able to turn it on in the situations elaborated above. Does anyone know in how far the mechanisms of igniting the backlight differ? Id est: Why does it work in one csae but not in the other. Why not simply use the working mechanism, always!?
Ok, this bug is lacking a bit on information. Please attach dmesg with drm.debug=0xe added to your commandline. I'm working on a few backlight fixes right now, so with the information from dmesg I could (hopefully) attach a few patches for you to try.
I for my part can no longer provide any information for I am no longer in possession of the specific hardware. I can only refer you to https://bugzilla.kernel.org/show_bug.cgi?id=34582 which has received some attention since I filed it. If no one else can reproduce this issue, I have no objections to closing it as whatever you like.
Ok, closing because the hw is gone. Thanks for reporting this anyway.
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.