Userland support for suspend
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Copyright (C) 2005 Rafael J. Wysocki <[email protected]>
Copyright (C) 2006 Pavel Machek <[email protected]>

This package contains some userland tools allowing you to suspend a Linux
system either to disk or to RAM.  These tools provide some capabilities
that are not available in the vanilla Linux kernel.

The suspend to disk can be carried out with the help of s2disk and resume
utilities which use the software suspend userland interface available in
the Linux kernel 2.6.17 or above.  Among other things, they provide the
following features:

- suspend image checksumming
- suspend image compression
- suspend image encryption
- (limited) support for splash screens and graphical progress meters

that are not provided by the in-kernel software suspend code (swsusp).
Please refer to the HOWTO document in this package for more information about
these utilities and installation instructions.

The s2ram tool allows you to suspend the system to RAM and restore the state
of the graphics adapter after the resume automatically.  For this purpose it
uses the code out of vbetool and radeontool utilities, needed for handling
quite a lot of graphics cards after the resume from RAM. The s2ram tool uses
three different methods to suspend the machine:

- KMS: s2ram try first suspend the machine using KMS (Kernel Mode Set) if the
  kernel supports it. With this method s2ram don't need extra parameters
  (quirks).
- Whitelist: s2ram has a whitelist of machines that are known to work with it.
  This whitelist includes the quirks to suspend known machines. The whitelist
  was used prior to suspend-utils version 1.0, and now the whitelist is not
  updated. The database is used because has a lot of machines included and
  many users are using it. Please refer to the document README.s2ram-whitelist
  in this package for more information about the s2ram whitelist.
- Configuration file: s2ram can use the configuration file to read the extra
  parameters (quirks). This option is useful if the kernel don't support KMS
  (for example, kernel compiled without support), if the machine is not
  included in the whitelist (for example, new machines) or if the user wants
  to override the quirks of the whitelist file.

The flow of options is:

1. If the kernel supports KMS, then use it. This option can be overriding
   using the argument "-k" in s2ram (s2ram -k).
2. If the kernel don't support KMS, or the user override it, then s2ram
   checks if the configuration file has the parameters. If the parameters
   are included, s2ram use them, else, the whitelist is used.

You need libx86 installed to build s2ram, the HOWTO document explains how to
install it.

The s2both tool combines the functionalities of s2disk and s2ram.  With the
help of it the system may be suspended to RAM after the suspend-to-disk
image has been created instead of being powered off.  Then, if there's enough
battery power, you can resume from RAM and discard the saved image, or you
can resume the system from disk using the resume tool otherwise  However, this
is only possible if your box is present in the s2ram whitelist.

To build the s2ram and s2both tools you will need the pciutils-devel
(pciutils-dev) package and the libx86-dev package (which you can get from 
http://www.codon.org.uk/~mjg59/libx86/downloads/). They are necessary to 
compile the vbetool code (the vbetool code is based on vbetool-1.0 from 
http://www.codon.org.uk/~mjg59/vbetool/). With newer pciutils (2.2.4 and
above) you also have to install the zlib development package (zlib-devel on
SUSE, zlib1g-dev on Debian).

For debugging, see http://suspend.sf.net/s2ram-support.html.

acpi-support package from Ubuntu has *very* long whitelist of machines: 
http://packages.ubuntu.org.cn/dapper/admin/acpi-support that are likely to
work with s2ram.

To compile this beast from CVS, do:

./autogen.sh
./configure
make