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-Video | Assignee: | 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
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. |