Since 2.6.39 (I think) a problem with backlight has gone from bad to horrible. Previously, the backlight turned itsself off when booting and had to be brought back up manuallly. Now, the backlight can't be turned on at all. Normally, the backlight can be increased and decreased and even turned on and off when decreasing below the lowest level. Normally, if you increase it again, it turns on and subsequently becomes brighter. In fact, once it turned off, either because that happend on boot or because you manually turned it off, increasing the value again does *not* turn it on. If the value is theoretically so, that it should be on, and the lid of the desktop is closed and opened again, the backlight turns on. HP Touchsmart tm-2 2010eg
I think it's a graphics driver problem. What graphics driver is used on your system?
I don't think so. I think ACPI backlight control is not related to the graphics device. Anyway, the device in use is Intel IGP with the i915 driver. (If it's of any importance, which I do not deem so, the specific laptop has hybrid graphics switcheroo with a Radeon, which, however, is not the default device which is used on boot). Formerly, an error regarding 'no _BCQ' appeared in dmesg regarding the blackout on boot. I've been proposed some ugly workarrounds which included modifying the DSDT but they are really not resolving the issue - not to mention they are not related to this very one. For further details refer to the bug on the intel-gfx bugtracker[1]. However, the fact that even pressing the "lightness up" key is unable to reignite the backlight appears to be a distinct, though similar issue. Thanks for looking into this, it's a really annoying bug. [1] https://bugs.freedesktop.org/show_bug.cgi?id=36823
please attach the output from acpidump also, when you switch virtual consoles using CTRL-ALT-F1, F2 etc does it have any effect? it would be extremely helpful if you could determine if this problem started in 2.6.39, or it if it was present in earlier releases, such as 2.6.38.
Created attachment 61982 [details] acpidump output
After compiling and booting into 38.8 (where it worked) and then going back to 39.1, it works there, too. I had a similarily bizarre issue a few days back, when booting into a brand new system with 39.1 would have the kernel stop doing anything (though still responding to events such as hardware being plugged and sysreqs), shortly after rootfs was mounted r/o. After I changed a few things such as mounting rootfs r/w and then went back to where the kernel originally stopped booting, it suddenly booted although i didnt change anything. So the control keys are now able to change brightness, though the screen still blanks on boot, which is also annoying.
PS: The acpidump is from after it started working.
Also, the backlight/brightness sysfs interface is not working, as before. Please note Bug #34582 . There has been absolutely no interest in that bug so I hope this will make someone look into it. It's impossible to control brightness programatically.
After a reboot from power off the problem has reappeared. I'm not able to use the control keys, as before. the currenct acpidump is attached, again.
Created attachment 62082 [details] acpidump when not working
Looks like there is no difference...
Switching virtual consoles has no effect.
Please accept this bug as verified and comment on it.
It's great that the kernel bugzilla is back. Can you please verify if the problem still exists in the latest upstream kernel?
I take the liberty to close this asINSUFFICENT_DATA because I'm no longer able to provide information (nor test it) and there have not been any other people reporting these problems. Besides #34582 is closely related and might aswell have rectified the particular issue reported here.