Bug 37282

Summary: Backlight can NOT be turned on by kernel, only off! - HP Touchsmart tm-2 2010eg
Product: ACPI Reporter: Cedric Sodhi (manday)
Component: Power-VideoAssignee: acpi_power-video
Status: CLOSED INSUFFICIENT_DATA    
Severity: normal CC: lenb, rjw, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.39 Subsystem:
Regression: No Bisected commit-id:
Attachments: acpidump output
acpidump when not working

Description Cedric Sodhi 2011-06-12 07:32:48 UTC
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
Comment 1 Rafael J. Wysocki 2011-06-12 10:11:46 UTC
I think it's a graphics driver problem.

What graphics driver is used on your system?
Comment 2 Cedric Sodhi 2011-06-12 14:42:23 UTC
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
Comment 3 Len Brown 2011-06-14 01:36:43 UTC
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.
Comment 4 Cedric Sodhi 2011-06-14 09:09:00 UTC
Created attachment 61982 [details]
acpidump output
Comment 5 Cedric Sodhi 2011-06-14 09:12:38 UTC
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.
Comment 6 Cedric Sodhi 2011-06-14 09:15:57 UTC
PS: The acpidump is from after it started working.
Comment 7 Cedric Sodhi 2011-06-14 09:47:47 UTC
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.
Comment 8 Cedric Sodhi 2011-06-15 06:56:56 UTC
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.
Comment 9 Cedric Sodhi 2011-06-15 06:57:58 UTC
Created attachment 62082 [details]
acpidump when not working
Comment 10 Cedric Sodhi 2011-06-15 06:59:39 UTC
Looks like there is no difference...
Comment 11 Cedric Sodhi 2011-06-15 10:04:40 UTC
Switching virtual consoles has no effect.
Comment 12 Cedric Sodhi 2011-06-16 19:56:27 UTC
Please accept this bug as verified and comment on it.
Comment 13 Zhang Rui 2012-01-18 05:20:28 UTC
It's great that the kernel bugzilla is back.

Can you please verify if the problem still exists in the latest upstream
kernel?
Comment 14 Cedric Sodhi 2012-05-11 13:29:32 UTC
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.