Created attachment 56732 [details] Dmesg This is a HP Touchsmart tm2 2010eg. The bug splits in multiple parts, all having to do with faulty ACPI and backlight support. Users with KMS enabled/vgaswitcheroo enabled experience all of them. Users without KMS and/or vgaswitcheroo might experience only parts of. --- With KMS on the screen turns blank on boot and backlight has to be brought back on through the laptop-mounted control keys. This happens at about 5 to 7.9 seconds in the attached dmesg, I can't tell exactly where, because it passes by to quickly. --- The brightness interface in /sys/class/backlight/acpi_video*/brightness does not sync with the real brightness, which in turn can only set by the hardware keys. If the brightness is decreased by those keys, the value in ./brightness decreases, too. Same with increasing it. But the value has not the correct absolute value. Values can be written to ./brightness and are accepted, so that the read-out value changes, but the real brightness does not change. --- xrandr rotating the screen to "Normal" rotation resets the backlight to 10. This is about the only "software driven" way that the brightness ever changes.
Update: Since this is Hybrid graphics with VGA Switcheroo, there are actually two cases. The one described above applies to IGD Intel Arrandale i915 running. When running the DIS ATI Cedar Radeon, even the hardware-keys are not changing the brightness, though they change the value in ./brightness.
Update: Surprisingly, rotating the display with xrandr in 90° steps does *not* have the effect of increasing brightness to 100% when rotating to normal rotation! xrandr --rotate inverted xrandr --rotate normal # => Backlight to 100% (though the next press of the function keys brings the backlight to a level as if the value had been retained) as opposed to xrandr --rotate inverted xrandr --rotate left xrandr --rotate normal # 90 deg steps => nothing happens. A bug with further information has been created and confirmed on LP for Ubuntu https://bugs.launchpad.net/ubuntu/+source/linux/+bug/697514
please build in your ACPI_VIDEO driver and boot with kernel parameter "video.use_bios_initial_backlight=0". Does the screen turns blank during boot?
(In reply to comment #3) > please build in your ACPI_VIDEO driver and boot with kernel parameter > "video.use_bios_initial_backlight=0". > Does the screen turns blank during boot? No, with this parameter brightness is at maximum level on boot. (I've got the hardware in my hands and can provide any further testing needed.) Some additional details, in case. OS: Ubuntu Natty, vga_switcheroo at initrd, modeset=1 kernel parameter Special key for changing brightness work, brightness could be changed with them (but not with system brightness setting GUI) at six levels with correctly displayed popup indication and two levels below (with indicator at minimum level), third level below seems to turn backlight off. The only known way to turn it back on - close-open lid, sometimes twice. Brightness level do not persist during OS restart.
I have a HP Touchsmart tm2-2090eo, I have had this problem forever but since for some reason X starting brought back the display so I never bothered to investigate further. When I reinstalled Arch Linux this week Tuesday X no longer brought back the display. That is what prompted me debugging this all week. My findings: -Booting i915 & radeon modules leads to blank screen, if I look closely I can see the high res framebuffer display for a split second before going blank. -I blamed this on the radeon module doing something funny so I tried blacklisting it. The result is exactly the same, thus I decided it had to be the i915 doing it. -Blacklisting i915 and using only radeon gave a different result, the display stayed lit but froze after "loading modules" in vga mode. Machine booted normally and I could SSH in. -With both modules loaded, SSH-ing in and found that echo DDIS > /sys/../vgaswitcheroo/switch killall X echo DIGD > /sys../switch would bring the display back. Today: adding acpi_osi="!Linux" acpi_osi="!Windows 2006" acpi_osi="!Windows 2009" to the kernel params makes the display stay lit, which is a bit unfortunate because it makes me loose the urge to investigate and get it fixed. Other info: My notebook is still running F.23 BIOS when HP has released F.25 in march 2011, some people report this BIOS update resolving issues. I will now proceed to swap to stock hard drive and use Windows to update BIOS and post more info as I learn more.
Created attachment 72910 [details] Dmesg of boot drm.debug=0xe without acpi_osi params
Created attachment 72911 [details] Dmesg of boot drm.debug=0xe without acpi_osi params
Created attachment 72912 [details] Dmesg of boot drm.debug=0xe with acpi_osi params Managed to mess up the earlier one
Some debugging of the problem is done here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/697514 And there is some workaround HowTo based on that debug: https://wiki.ubuntu.com/HP%20TouchSmart%20tm2#Screen_Brightness No more black screens after applying this fix. (Just one minor problem with graphical mode setting in Plymouth - black screen at disk encryption prompt, text mode is OK after Escape press; looks like it's from another bug.) to Robert Ahlskog It looks like F.25 does not change anything with the case. It seems, there is some logic behind that "if" in that _BCL ACPI function, but I couldn't found any mention of it. CORRECTION to my post #4: should read "Ubuntu 11.10 Oneiric" instead of "Ubuntu Natty" (living in yesterday a bit =).
I can confirm that patching the DSDT makes everything work as it should, the acpi_osi parmaters made the display stay black after dpms off, closing-opening the lid made it come back on. However patching the DSDT does not seem like a permanent solution, how do we proceed in bringing this issue to and what we know about it to someone who has the knowhow to make a fix. I do not know how these kind of things are handled, while I could start learning about the process and how to work around ACPI quirks progress would be slow with my unfortunately limited time resources. And with me now having my laptop back in workable condition I have lost an immediate itch to scratch and other priorities take over. I guess a bounty would be in place, 50€ via PayPal(I cover the fees) or Cash/Bank in Vaasa/Finland area claimable once it is in mainline. I will provide what I know and be available for testing to whomever wants to try fixing it.