~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2003-2006, Pavel Machek
During S3 resume, hardware needs to be reinitialized. For most devices, this is easy, and kernel driver knows how to do it. Unfortunately there's one exception: video card. Those are usually initialized by BIOS, and kernel does not have enough information to boot video card. (Kernel usually does not even contain video card driver -- vesafb and vgacon are widely used).
This is not problem for swsusp, because during swsusp resume, BIOS is run normally so video card is normally initialized. It should not be problem for S1 standby, because hardware should retain its state over that. We either have to run video BIOS during early resume, or interpret it using vbetool later, or maybe nothing is necessary on particular system because video state is preserved. Unfortunately different methods work on different systems, and no known method suits all of them.
Userland application called s2ram has been developed; it contains long whitelist of systems, and automatically selects working method for a given system. It can be downloaded from CVS at . If you get a system that is not in the whitelist, please try to find a working solution, and submit whitelist entry so that work does not need to be repeated.
Currently, VBE_SAVE method (6 below) works on most systems. Unfortunately, vbetool only runs after userland is resumed, so it makes debugging of early resume problems hard/impossible. Methods that do not rely on userland are preferable.
Details ~~~~~~~ There are a few types of systems where video works after S3 resume:
(1) systems where video state is preserved over S3.
(2) systems where it is possible to call the video BIOS during S3 resume. Unfortunately, it is not correct to call the video BIOS at that point, but it happens to work on some machines. Use acpi_sleep=s3_bios.
(3) systems that initialize video card into vga text mode and where the BIOS works well enough to be able to set video mode. Use acpi_sleep=s3_mode on these.
(4) on some systems s3_bios kicks video into text mode, and acpi_sleep=s3_bios,s3_mode is needed.
(5) radeon systems, where X can soft-boot your video card. You'll need a new enough X, and a plain text console (no vesafb or radeonfb). See for more information. Alternatively, you should use vbetool (6) instead.
(6) other radeon systems, where vbetool is enough to bring system back to life. It needs text console to be working. Do vbetool vbestate save > /tmp/delme; echo 3 > /proc/acpi/sleep; vbetool post; vbetool vbestate restore < /tmp/delme; setfont , and your video should work.
(7) on some systems, it is possible to boot most of kernel, and then POSTing bios works. Ole Rohne has patch to do just that at http://dev.gentoo.org/~marineam/patch-radeonfb-2.6.11-rc2-mm2.
(8) on some systems, you can use the video_post utility mentioned here: Do echo 3 > /sys/power/state && /usr/sbin/video_post - which will initialize the display in console mode. If you are in X, you can switch to a virtual terminal and back to X using CTRL+ALT+F1 - CTRL+ALT+F7 to get the display working in graphical mode again.
Now, if you pass acpi_sleep=something, and it does not work with your bios, you'll get a hard crash during resume. Be careful. Also it is safest to do your experiments with plain old VGA console. The vesafb and radeonfb (etc) drivers have a tendency to crash the machine during resume.
You may have a system where none of above works. At that point you either invent another ugly hack that works, or write proper driver for your video card (good luck getting docs :-(). Maybe suspending from X (proper X, knowing your hardware, not XF68_FBcon) might have better chance of working.
