Documentation/power/video.rst

Source file repositories/reference/linux-study-clean/Documentation/power/video.rst

File Facts

System
Linux kernel
Corpus path
Documentation/power/video.rst
Extension
.rst
Size
9006 bytes
Lines
214
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

===========================
Video issues with S3 resume
===========================

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
www.sf.net/projects/suspend . 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
    http://www.doesi.gmxhome.de/linux/tm800s3/s3.html 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 <whatever>, 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.

Annotation

Implementation Notes