File: README

package info (click to toggle)
uswsusp 1.0+20120915-6.2
  • links: PTS, VCS
  • area: main
  • in suites: bullseye, buster, sid
  • size: 1,572 kB
  • sloc: ansic: 7,164; sh: 566; makefile: 223; perl: 65
file content (119 lines) | stat: -rw-r--r-- 6,301 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
Userland support for suspend
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Copyright (C) 2005 Rafael J. Wysocki <rjw@sisk.pl>
Copyright (C) 2006 Pavel Machek <pavel@suse.cz>

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). Is possible test if the
   kernel supports KMS using the argument "-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. Is possible
   test if the machine is in the whitelist using the argument "-n".

The full table of options is:

User want    = What the user needs for their machine (KMS, Whitelist or their
               own specific quirks).
KMS support? = If the kernel has KMS support enabled.
In WL?       = If the machine is included in the whitelist.
Command Line = What should do the user in the command line (s2ram options).
Config File  = What should include the user in the configuration file.
N/A          = Yes and No, for both cases.
Not possible = This option cannot be used!.
Nothing      = The user must not include s2ram_force, s2ram_quirks and
               s2ram_quirks lines in the configuration file.
"<quirks>"   = Quirks options to be used. In command line these options are
               --vbe_save, --vbe_post,... and in the config file are
               vbe_save, vb_post (same options, without the "--").

User want | KMS support? | In WL? | Command Line   | Config File
==========+==============+========+================+========================
          | No           | N/A    | Not possible   | Not possible
KMS (-K)  +--------------+--------+----------------+------------------------
          | Yes          | N/A    | No arguments   | Nothing
==========+==============+========+================+========================
          | N/A          | No     | Not possible   | Not possible
          +--------------+--------+----------------+------------------------
WL  (-n)  | No           | Yes    | No arguments   | Nothing
          +--------------+--------+----------------+------------------------
          | Yes          | Yes    | -k             | s2ram_disable_kms = y
==========+==============+========+================+========================
          | No           | N/A    | -f <quirks>    | s2ram_force = y
          |              |        |                | s2ram_quirks = <quirks>
User      +--------------+--------+----------------+------------------------
Quirks    | Yes          | N/A    | -k -f <quirks> | s2ram_disable_kms = y
          |              |        |                | s2ram_force = y
          |              |        |                | s2ram_quirks = <quirks>
----------+--------------+--------+----------------+------------------------

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