An update to the more-or-less ongoing saga of the “black screen” at boot when running Intel Graphics
(Some material herein may rightfully belong in another forum: mea culpa)
There have been many threads and many more posts regarding install, boot or power-management problems when using Intel Graphics. In particular, I have posted regarding the Intel GMA HD, although the Intel GMA 3000 and others have manifested the problem of a “black screen” either during install, or following selection from GRUB. This “black screen” also appears in certain power-management scenarios.
The problem(s) have manifested in many distros: openSUSE, Ubuntu, Fedora and more. Further, the problems seem to have appeared in kernels after 2.6.32. A brief glimmer of progress was noted at kernel 2.6.38-rc1 and moreso at 2.6.38-rc2. Subsequent kernels (up to, and including kernel 3.1.rc9-7.2 manifest the problem, a regression noted in bug 699678 (see below). Related problems were reported against X, specifically, the Intel video drivers. However, the base source of the problem is in the kernel, specifically kernel initialization and KMS.
Several “bugs” have been created or updated on this problem, most notably:
bug 29278 - https://bugs.freedesktop.org/show_bug.cgi?id=29278
bug 669798 - https://bugzilla.novell.com/show_bug.cgi?id=669798
and more than a few others.
Circumventions and work-arounds have included the lid closure/re-opening (at boot), and workspace-switching (following power-deomanagement actions). While these offer some solutions to laptop users, there appears to be no alternatives to desktop or all-in-one PC’s experiencing this problem.
Following a long chain of links, starting with “acpi” and “backlight” leading to “acpi_video0”, two kernel options offered some opportunity: acpi_osi and acpi_backlight. Specifically, using the following kernel options:
acpi_osi=Linux
acpi_backlight=vendor
have reported some success in Ubuntu installations, as well as Fedora 14 and 15. It should be noted that the original source of the lid-closure/re-open circumvention was from the Fedora forums.
After testing each of the above options, on openSUSE 11.4 and 12.1MS5++ (actually 12.1 Factory now), the option acpi_osi appeared to have no observable effect. However, setting acpi_backlight=vendor on the kernel options resulted in no “black screen” at boot, nor at power-management suspend/hibernation recovery. Further, this option yielded a bonus: display brightness control (via fn+arrow keys or whatever key combination is specific to hardware) functions correctly.
This finding has been tested by me on the following hardware: Intel i5-430M, with Intel GMA HD graphics. The option was tested on openSUSE 11.4 against the following kernels: 2.6.37.6-0.7 and 3.1.0-rc9-7, kernel type -desktop. Further, this option was tested against openSUSE 12.1MS5++, with kernels 3.0.0-4 and 3.1.0-rc9-7, kernel type -desktop.
Suspend/hibernation was successfully tested on each of the above combinations, both under Gnome 2.32 (11.4) and Gnome 3 (12.1), and KDE 4.7.2 on each openSUSE release, and previous brightness levels were correctly reinstated.
(FWIW: the acpi_backlight option was also successfully tested on Fedora 15, kernel 2.6.40-6. Initial tests on [Fedora] kernel 2.6.38-26 gave mixed results)
Brightness control via keyboard (acpi-controlled) functioned correctly under each of the above combinations, with a couple of minor glitches under Gnome3 (in resumption from suspend). (NOTE: my Gnome3 has no option for hibernation, and is being researched separately).
I have tested this option (acpi_backlight=vendor) from the GRUB command line and by updating entries in /boot/grub/menu.lst. Next test is to update the saved bootloader configuration for subsequent kernel updates.
One area NOT covered by this solution involves the DE (gdm or kdm) “Login” screen. I have never been able to suppress the power-management options for a display sitting on the “Login” screen. Once power-management blanks the screen, only the workspace switch workaround can recover.
I would be eager to hear any experiences with other Intel GMA’s, as well as any switchable-graphics platforms and non-laptop users. I will be updating bug 699678 soon, however, I apparently do not (as yet) have authority to update freedesktop.org bugs.