Configuration: ==============
A mainline kernel of arbitrary version. HP Touchsmart tm-2 2010eg [1] Laptop with dual (a.k.a "hybrid") switchable graphics:
Intel 1915 Arrandale & Radeon HD 5450 CEDAR
DRM_RADEON_KMS [=y] HAS_IOMEM [=y] DRM_RADEON [=y] DRM_I915 [=y] DRM_I915_KMS [=y] DRM [=y] AGP [=y] AGP_INTEL [=y] ACPI [=y] LCD_CLASS_DEVICE [=y] LCD_PLATFORM [=y] BACKLIGHT_CLASS_DEVICE [=y] FIRMWARE_EDID [=y] FB_FOREIGN_ENDIAN [=y] FB_MODE_HELPERS [=y] FB_EFI [=y] VIDEO_OUTPUT_CONTROL [=y] VGA_SWITCHEROO [=y]
plus respective dependencies.
Symptops in default configuration: ==================================
Upon boot the backlight turns off at about the point where KMS would kick in*.
The subsequent behaviour shows a complicated yet distinctive pattern, as follows:
After backlight has gone off, either initially on boot or during uptipe by decreasing the brightness to 0 (either by laptop function keys or kernel /sys brightness interface) it cannot be turned back on, if exactly one more attempts to do so have been made, while the unit was on AC Power.
In that case, there are only two possible hacks to turn the backlight back on, in both of which cases the backlight will instantly turn to the brightest setting, regarldess, although the value in the /sys brightness interface remains unchanged:
a) Close the laptop screen down for a few seconds and open it back up.
b) If X is running, issue an xrandr --rotate such that the screen will rotate by 90 deg in either direction.
In all other cases, the backlight can be controlled normally. That is, if no attempt to increase brightness, id est turn the backlight back on is made while the unit is AC powered.
None of these problems arise if the backlight has been turned off due to idle time (say, in TTY), rather than on boot or manually.
* Supplemental information: The kernel defaults to the i915 IGD o boot. Radeon is not considered here, although it also appears to have problems controlling the backlight.
Symptoms in various other configurations (list): ================================================
Other configurations have been tried. As you will read in the list, you can witness another undesired coupling between switcheroo (the debugfs interface) and KMS. In certain situations, switcheroo is said to be enabled in CONFIG, yet not available in debugfs for other reasons. One of those situations, which is not among the ones listed below, is when the DRM drivers have been compiled as modules rather than compiled in.
In the following "screen blanks" refers to the situation which is described above as the symptoms in default configuration:
ACPI off (=>Switcheroo off): Boots into KMS, everything OK Switcheroo off: Boots into KMS, screen blanks KMS off: Freezes (visually) on boot KMS default off (compiled): Switcheroo disappears, everything OK KNS on (default off): Switcheroo disappears, screen blanks KMS default off, BL off: Switcheroo disappears, everything OK KMS on (default off), BL off: Switcheroo disappears, screen blanks Same 2 with Switcheroo off: Same as the two lines above
(BL off means BACKLIGHT_LCD_SUPPORT off, which results in a warning because DRM & ACPI requires BACKLIGHT_CLASS_SUPPORT, which is a child thereof)
Further information: ====================
This and similar bugs has been repeatedly filed by me and others on serveral bugtrackers, including freedesktop[2] and kernel (which is unreachable atm). DMESG in default configuration is attached. You will find a reference to an ACPI bug which likely to be related to the initial backlight loss on boot [3]. However, it is so far unclear whether it is also related to the problems in bringing the backlight back on.
[1] http://h10025.www1.hp.com/ewfrf/wc/document?docname=c02262928&tmp_task=p... [2] https://bugs.freedesktop.org/show_bug.cgi?id=41306 [3] http://forums.gentoo.org/viewtopic-t-874961-start-0.html