SSL Java viewer work thru proxy. -sslGenCA, etc key/cert management utils for x11vnc. FBPM "support".

1 files changed, 439 insertions, 51 deletions

diff --git a/x11vnc/x11vnc.1 b/x11vnc/x11vnc.1
index a2db39e..fcf2d6b 100644
--- a/x11vnc/x11vnc.1
+++ b/x11vnc/x11vnc.1
@@ -1,8 +1,8 @@
 .\" This file was automatically generated from x11vnc -help output.
-.TH X11VNC "1" "March 2006" "x11vnc " "User Commands"
+.TH X11VNC "1" "April 2006" "x11vnc " "User Commands"
 .SH NAME
 x11vnc - allow VNC connections to real X11 displays
-         version: 0.8.1, lastmod: 2006-03-27
+         version: 0.8.1, lastmod: 2006-04-05
 .SH SYNOPSIS
 .B x11vnc
 [OPTION]...
@@ -638,7 +638,7 @@ use the traditional
 .IR crypt (3)
 method to
 verify passwords instead.  This requires that the
-encrpyted passwords be readable.  Passwords stored
+encrypted passwords be readable.  Passwords stored
 in /etc/shadow will be inaccessible unless x11vnc
 is run as root.
 .IP
@@ -647,7 +647,7 @@ NIS setups the user encrypted passwords are accessible
 (e.g. "ypcat passwd").  NIS is not required for this
 mode to work (only that 
 .IR getpwnam (3)
-return the encrpyted
+return the encrypted
 password is required), but it is unlikely it will work
 for any other modern environment.  All of the \fB-unixpw\fR
 options and contraints apply.
@@ -665,17 +665,19 @@ is prescribed.
 to specify a PEM certificate file to use to identify
 and provide a key for this server.  See 
 .IR openssl (1)
-for what a PEM can be.
+for
+more info about PEMs and the \fB-sslGenCert\fR option below.
 .IP
-Connecting VNC viewer SSL tunnels can optionally
+The connecting VNC viewer SSL tunnel can optionally
 authenticate this server if they have the public
 key part of the certificate (or a common certificate
 authority, CA, is a more sophisicated way to verify
-this server's cert).  This is used to prevent
-man-in-the-middle attacks.  Otherwise, if the VNC
-viewer accepts this server's key without verification,
-at least the traffic is protected from passive sniffing
-on the network (but NOT from man-in-the-middle attacks).
+this server's cert, see \fB-sslGenCA\fR below).  This is
+used to prevent man-in-the-middle attacks.  Otherwise,
+if the VNC viewer accepts this server's key without
+verification, at least the traffic is protected
+from passive sniffing on the network (but NOT from
+man-in-the-middle attacks).
 .IP
 If [pem] is not supplied and the 
 .IR openssl (1)
@@ -693,15 +695,34 @@ to generate a
 temporary certificate, the public part of it will be
 displayed to stderr (e.g. one could copy it to the
 client-side to provide authentication of the server to
-VNC viewers.)
+VNC viewers.)  See following paragraphs for how to save
+keys to reuse when x11vnc is restarted.
 .IP
 Set the env. var. X11VNC_SHOW_TMP_PEM=1 to have x11vnc
 print out the entire certificate, including the PRIVATE
 KEY part, to stderr.  One could reuse this cert if saved
 in a [pem] file.  Similarly, set X11VNC_KEEP_TMP_PEM=1
 to not delete the temporary PEM file: the file name
-will be printed to stderr (so one could move it to a
-safe place for reuse).
+will be printed to stderr (so one could move it to
+a safe place for reuse).  You will be prompted for a
+passphrase for the private key.
+.IP
+If [pem] is "SAVE" then the certificate will be saved
+to the file ~/.vnc/certs/server.pem, or if that file
+exists it will be used directly.  Similarly, if [pem]
+is "SAVE_PROMPT" the server.pem certificate will be
+made based on your answers to its prompts for info such
+as OrganizationalName, CommonName, etc.
+.IP
+Use "SAVE-<string>" and "SAVE_PROMPT-<string>"
+to refer to the file ~/.vnc/certs/server-<string>.pem
+instead.  E.g. "SAVE-charlie" will store to the file
+~/.vnc/certs/server-charlie.pem
+.IP
+See \fB-ssldir\fR below to use a directory besides the
+default ~/.vnc/certs
+.IP
+Example: x11vnc \fB-ssl\fR SAVE \fB-display\fR :0 ...
 .IP
 Reverse connections are disabled in \fB-ssl\fR mode because
 there is no way to ensure that data channel will
@@ -709,43 +730,392 @@ be encrypted.  Set X11VNC_SSL_ALLOW_REVERSE=1 to
 override this.
 .IP
 Your VNC viewer will also need to be able to connect
-via SSL.  See the discussion below under \fB-stunnel\fR
-and the FAQ for how this might be achieved.  E.g. on
-Unix it is easy to write a shell script that starts up
-stunnel and then vncviewer.  Also in the x11vnc source
-a SSL enabled Java VNC Viewer applet is provided in
-the classes/ssl directory.
+via SSL.  See the discussion below under \fB-stunnel\fR and
+the FAQ (ssl_vncviewer script) for how this might be
+achieved.  E.g. on Unix it is easy to write a shell
+script that starts up stunnel and then vncviewer.
+Also in the x11vnc source a SSL enabled Java VNC Viewer
+applet is provided in the classes/ssl directory.
+.PP
+\fB-ssldir\fR \fI[dir]\fR
+.IP
+Use [dir] as an alternate ssl certificate and key
+management toplevel directory.  The default is
+~/.vnc/certs
+.IP
+This directory is used to store server and other
+certificates and keys and also other materials.  E.g. in
+the simplest case, "\fB-ssl\fR \fISAVE\fR" will store the x11vnc
+server cert in [dir]/server.pem
+.IP
+Use of alternate directories via \fB-ssldir\fR allows you to
+manage multiple VNC Certificate Authority (CA) keys.
+Another use is if ~/.vnc/cert is on an NFS share you
+might want your certificates and keys to be on a local
+filesystem to prevent network snooping (for example
+\fB-ssldir\fR /var/lib/x11vnc-certs).
+.IP
+\fB-ssldir\fR effects the other \fB-ssl*\fR options.  In the case
+of maintenance commands where the VNC server is not run
+(e.g. \fB-sslGenCA),\fR the \fB-ssldir\fR option must precede the
+command. E.g. x11vnc \fB-ssldir\fR ~/mydir \fB-sslCertInfo\fR LIST
 .PP
 \fB-sslverify\fR \fI[path]\fR
 .IP
 For either of the \fB-ssl\fR or \fB-stunnel\fR modes, use [path]
 to provide certificates to authenticate incoming VNC
-client connections.  This can be used as a method to
-replace standard password authentication of clients.
+*Client* connections (normally only the server is
+authenticated in SSL.)  This can be used as a method
+to replace standard password authentication of clients.
 .IP
 If [path] is a directory it contains the client (or CA)
-certificates in separate files.  If [path] is a file, it
-contains multiple certificates.  These correspond to the
-"CApath = dir" and "CAfile = file" stunnel options.
-See the 
+certificates in separate files.  If [path] is a file,
+it contains multiple certificates.  See special tokens
+below.  These correspond to the "CApath = dir" and
+"CAfile = file" stunnel options.  See the 
 .IR stunnel (8)
 manpage for details.
 .IP
-To create certificates for all sorts of authentications
-(clients, servers, via CA, etc) see the 
+Examples:
+x11vnc \fB-ssl\fR \fB-sslverify\fR ~/my.pem
+x11vnc \fB-ssl\fR \fB-sslverify\fR ~/my_pem_dir/
+.IP
+Note that if [path] is a directory, it must contain
+the certs in separate files named like <HASH>.0, where
+the value of <HASH> is found by running the command
+"openssl x509 \fB-hash\fR \fB-noout\fR \fB-in\fR file.crt". Evidently
+one uses <HASH>.1 if there is a collision...
+.IP
+The the key-management utility "\fB-sslCertInfo\fR \fIHASHON\fR"
+and "\fB-sslCertInfo\fR \fIHASHOFF\fR" will create/delete these
+hashes for you automatically (via symlink) in the HASH
+subdirs it manages.  Then you can point \fB-sslverify\fR to
+the HASH subdir.
+.IP
+Special tokens: in \fB-ssl\fR mode, if [path] is not a file or
+a directory, it is taken as a comma separated list of
+tokens that are interpreted as follows:
+.IP
+If a token is "CA" that means load the CA/cacert.pem
+file from the ssl directory.  If a token is "clients"
+then all the files clients/*.crt in the ssl directory
+are loaded.  Otherwise the file clients/token.crt
+is attempted to be loaded.  As a kludge, use a token
+like ../server-foo to load a server cert if you find
+that necessary.
+.IP
+Use \fB-ssldir\fR to use a directory different from the
+~/.vnc/certs default.
+.IP
+Note that if the "CA" cert is loaded you do not need
+to load any of the certs that have been signed by it.
+You will need to load any additional self-signed certs
+however.
+.IP
+Examples:
+x11vnc \fB-ssl\fR \fB-sslverify\fR CA
+x11vnc \fB-ssl\fR \fB-sslverify\fR self:fred,self:jim
+x11vnc \fB-ssl\fR \fB-sslverify\fR CA,clients
+.IP
+Usually "\fB-sslverify\fR \fICA\fR" is the most effective.
+See the \fB-sslGenCA\fR and \fB-sslGenCert\fR options below for
+how to set up and manage the CA framework.
+.IP
+NOTE: the following utilities, \fB-sslGenCA,\fR \fB-sslGenCert,\fR
+\fB-sslEncKey,\fR and \fB-sslCertInfo\fR are provided for
+completeness, but for casual usage they are overkill.
+.IP
+They provide VNC Certificate Authority (CA) key creation
+and server / client key generation and signing.  So they
+provide a basic Public Key management framework for
+VNC-ing with x11vnc. (note that they require 
 .IR openssl (1)
-command.  Of particular usefulness is the "x509"
-subcommand of 
-.IR openssl (1).
+be installed on the system)
+.IP
+However, the simplest usage mode (where x11vnc
+automatically generates its own, self-signed, temporary
+key and the VNC viewers always accept it, e.g. accepting
+via a dialog box) is probably safe enough for most
+scenarios.  CA management is not needed.
+.IP
+To protect against Man-In-The-Middle attacks the
+simplest mode can be improved by using "\fB-ssl\fR \fISAVE\fR"
+to have x11vnc create a longer term self-signed
+certificate, and then (safely) copy the corresponding
+public key cert to the desired client machines (care
+must be taken the private key part is not stolen;
+you will be prompted for a passphrase).
+.IP
+So keep in mind no CA key creation or management
+(-sslGenCA and \fB-sslGenCert)\fR is needed for either of
+the above two common usage modes.
+.IP
+One might want to use \fB-sslGenCA\fR and \fB-sslGenCert\fR
+if you had a large number of VNC client and server
+workstations.  That way the administrator could generate
+a single CA key with \fB-sslGenCA\fR and distribute its
+certificate part to all of the workstations.
+.IP
+Next, he could create signed VNC server keys
+(-sslGenCert server ...) for each workstation or user
+that then x11vnc would use to authenticate itself to
+any VNC client that has the CA cert.
+.IP
+Optionally, the admin could also make it so the
+VNC clients themselves are authenticated to x11vnc
+(-sslGenCert client ...)  For this \fB-sslverify\fR would be
+pointed to the CA cert (and/or self-signed certs).
+.IP
+x11vnc will be able to use all of these cert and
+key files.  On the VNC client side, they will need to
+be "imported" somehow.  Web browsers have "Manage
+Certificates" actions as does the Java applet plugin
+Control Panel.  stunnel can also use these files (see
+the ssl_vncviewer example script in the FAQ.)
+.PP
+\fB-sslGenCA\fR \fI[dir]\fR
+.IP
+Generate your own Certificate Authority private key,
+certificate, and other files in directory [dir].
+.IP
+If [dir] is not supplied, a \fB-ssldir\fR setting is used,
+or otherwise ~/.vnc/certs is used.
+.IP
+This command also creates directories where server and
+client certs and keys will be stored.  The 
+.IR openssl (1)
+program must be installed on the system and available
+in PATH.
+.IP
+After the CA files and directories are created the
+command exits; the VNC server is not run.
+.IP
+You will be prompted for information to put into the CA
+certificate.  The info does not have to be accurate just
+as long as clients accept the cert for VNC connections.
+You will also need to supply a passphrase of at least
+4 characters for the CA private key.
+.IP
+Once you have generated the CA you can distribute
+its certificate part, [dir]/CA/cacert.pem, to other
+workstations where VNC viewers will be run.  One will
+need to "import" this certicate in the applications,
+e.g. Web browser, Java applet plugin, stunnel, etc.
+Next, you can create and sign keys using the CA with
+the \fB-sslGenCert\fR option below.
+.IP
+Examples:
+x11vnc \fB-sslGenCA\fR
+x11vnc \fB-sslGenCA\fR  ~/myCAdir
+x11vnc \fB-ssldir\fR ~/myCAdir \fB-sslGenCA\fR
+.IP
+(the last two lines are equivalent)
+.PP
+\fB-sslGenCert\fR \fItype\fR \fIname\fR
+.IP
+Generate a VNC server or client certificate and private
+key pair signed by the CA created previously with
+\fB-sslGenCA.\fR  The 
+.IR openssl (1)
+program must be installed
+on the system and available in PATH.
+.IP
+After the Certificate is generated the command exits;
+the VNC server is not run.
+.IP
+The type of key to be generated is the string \fItype\fR.
+It is either "server" (i.e. for use by x11vnc) or
+"client" (for a VNC viewer).  Note that typically
+only "server" is used: the VNC clients authenticate
+themselves by a non-public-key method (e.g. VNC or
+unix password).  \fItype\fR is required.
+.IP
+An arbitrary default name you want to associate with
+the key is supplied by the \fIname\fR string.  You can
+change it at the various prompts when creating the key.
+\fIname\fR is optional.
+.IP
+If name is left blank for clients keys then "nobody"
+is used.  If left blank for server keys, then the
+primary server key: "server.pem" is created (this
+is the saved one referenced by "\fB-ssl\fR \fISAVE\fR" when the
+server is started)
+.IP
+If \fIname\fR begins with the string "self:" then
+a self-signed certificate is created instead of one
+signed by your CA key.
+.IP
+If \fIname\fR begins with the string "req:" then only a
+key (.key) and a certificate signing *request* (.req)
+are generated.  You can then send the .req file to
+an external CA (even a professional one, e.g. Thawte)
+and then combine the .key and the received cert into
+the .pem file with the same basename.
+.IP
+The distinction between "server" and "client" is
+simply the choice of output filenames and sub-directory.
+This makes it so the \fB-ssl\fR SAVE-name option can easily
+pick up the x11vnc PEM file this option generates.
+And similarly makes it easy for the \fB-sslverify\fR option
+to pick up your client certs.
+.IP
+There is nothing special about the filename or directory
+location of either the "server" and "client" certs.
+You can rename the files or move them to wherever
+you like.
+.IP
+Precede this option with \fB-ssldir\fR [dir] to use a
+directory other than the default ~/.vnc/certs You will
+need to run \fB-sslGenCA\fR on that directory first before
+doing any \fB-sslGenCert\fR key creation.
+.IP
+Note you cannot recreate a cert with exactly the same
+distiguished name (DN) as an existing one.  To do so,
+you will need to edit the [dir]/CA/index.txt file to
+delete the line.
+.IP
+Similar to \fB-sslGenCA,\fR you will be prompted to fill
+in some information that will be recorded in the
+certificate when it is created.  Tip: if you know
+the fully-quailified hostname other people will be
+connecting to you can use that as the CommonName "CN"
+to avoid some applications (e.g. web browsers and java
+plugin) complaining it does not match the hostname.
+.IP
+You will also need to supply the CA private key
+passphrase to unlock the private key created from
+\fB-sslGenCA.\fR  This private key is used to sign the server
+or client certicate.
+.IP
+The "server" certs can be used by x11vnc directly by
+pointing to them via the \fB-ssl\fR [pem] option.  The default
+file will be ~/.vnc/certs/server.pem.  This one would
+be used by simply typing \fB-ssl\fR SAVE.  The pem file
+contains both the certificate and the private key.
+server.crt file contains the cert only.
+.IP
+The "client" cert + private key file will need
+to be copied and imported into the VNC viewer
+side applications (Web browser, Java plugin,
+stunnel, etc.)  Once that is done you can delete the
+"client" private key file on this machine since
+it is only needed on the VNC viewer side.  The,
+e.g. ~/.vnc/certs/clients/<name>.pem contains both
+the cert and private key.  The <name>.crt contains the
+certificate only.
+.IP
+NOTE: It is very important to know one should always
+generate new keys with a passphrase.  Otherwise if an
+untrusted user steals the key file he could use it to
+masquerade as the x11vnc server (or VNC viewer client).
+You will be prompted whether to encrypt the key with
+a passphrase or not.  It is recommended that you do.
+One inconvenience to a passphrase is that it must
+be suppled every time x11vnc or the client app is
+started up.
+.IP
+Examples:
+.IP
+x11vnc \fB-sslGenCert\fR server
+x11vnc \fB-ssl\fR SAVE \fB-display\fR :0 ...
+.IP
+and then on viewer using ssl_vncviewer stunnel wrapper
+(see the FAQ):
+ssl_vncviewer \fB-verify\fR ./cacert.crt hostname:0
+.IP
+(this assumes the cacert.crt cert from \fB-sslGenCA\fR
+was safely copied to the VNC viewer machine where
+ssl_vncviewer is run)
+.IP
+Example using a name:
+.IP
+x11vnc \fB-sslGenCert\fR server charlie
+x11vnc \fB-ssl\fR SAVE-charlie \fB-display\fR :0 ...
+.IP
+Example for a client certificate (rarely used):
+.IP
+x11vnc \fB-sslGenCert\fR client roger
+scp ~/.vnc/certs/clients/roger.pem somehost:.
+rm  ~/.vnc/certs/clients/roger.pem
+.IP
+x11vnc is then started with the the option \fB-sslverify\fR
+~/.vnc/certs/clients/roger.crt (or simply \fB-sslverify\fR
+roger), and on the viewer user on somehost could do
+for example:
+.IP
+ssl_vncviewer \fB-mycert\fR ./roger.pem hostname:0
+.PP
+\fB-sslEncKey\fR \fI[pem]\fR
+.IP
+Utility to encrypt an existing PEM file with a
+passphrase you supply when prompted.  For that key to be
+used (e.g. by x11vnc) the passphrase must be supplied
+each time.
+.IP
+The "SAVE" notation described under \fB-ssl\fR applies as
+well. (precede this option with \fB-ssldir\fR [dir] to refer
+a directory besides the default ~/.vnc/certs)
+.IP
+The 
+.IR openssl (1)
+program must be installed on the system
+and available in PATH.  After the Key file is encrypted
+the command exits; the VNC server is not run.
+.IP
+Examples:
+x11vnc \fB-sslEncKey\fR /path/to/foo.pem
+x11vnc \fB-sslEncKey\fR SAVE
+x11vnc \fB-sslEncKey\fR SAVE-charlie
+.PP
+\fB-sslCertInfo\fR \fI[pem]\fR
+.IP
+Prints out information about an existing PEM file.
+In addition the public certificate is also printed.
+The 
+.IR openssl (1)
+program must be in PATH. Basically the
+command "openssl x509 \fB-text"\fR is run on the pem.
+.IP
+The "SAVE" notation described under \fB-ssl\fR applies
+as well.
+.IP
+Using  "LIST" will give a list of all certs being
+managed (in the ~/.vnc/certs dir, use \fB-ssldir\fR to refer
+to another dir).  "ALL" will print out the info for
+every managed key (this can be very long).  Giving a
+client or server cert shortname will also try a lookup
+(e.g. \fB-sslCertInfo\fR charlie).  Use "LISTL" or "LL"
+for a long (ls \fB-l\fR style) listing.
+.IP
+Using "HASHON" will create subdirs [dir]/HASH and
+[dir]/HASH with OpenSSL hash filenames (e.g. 0d5fbbf1.0)
+symlinks pointing up to the corresponding *.crt file.
+([dir] is ~/.vnc/certs or one given by \fB-ssldir.)\fR
+This is a useful way for other OpenSSL applications
+(e.g. stunnel) to access all of the certs without
+having to concatenate them.  x11vnc will not use them
+unless you specifically reference them.  "HASHOFF"
+removes these HASH subdirs.
+.IP
+The LIST, LISTL, LL, ALL, HASHON, HASHOFF words can
+also be lowercase, e.g. "list".
+.PP
+\fB-sslDelCert\fR \fI[pem]\fR
+.IP
+Prompts you to delete all .crt .pem .key .req files
+associated with [pem].  "SAVE" and lookups as in
+\fB-sslCertInfo\fR apply as well.
 .PP
 \fB-stunnel\fR \fI[pem]\fR
 .IP
 Use the 
 .IR stunnel (8)
 (www.stunnel.org) to provide an
-encrypted SSL tunnel between viewers and x11vnc.  This
-was implemented prior to the integrated \fB-ssl\fR encrpytion.
-It works well.  This requires stunnel to be installed
+encrypted SSL tunnel between viewers and x11vnc.
+.IP
+This external tunnel method was implemented prior to the
+integrated \fB-ssl\fR encryption described above.  It still
+works well.  This requires stunnel to be installed
 on the system and available via PATH (n.b. stunnel is
 often installed in sbin directories).  Version 4.x of
 stunnel is assumed (but see \fB-stunnel3\fR below.)
@@ -771,14 +1141,13 @@ Your VNC viewer will also need to be able to connect via
 SSL.  Unfortunately not too many do this.  UltraVNC has
 an encryption plugin but it does not seem to be SSL.
 .IP
-In the x11vnc distribution, a patched TightVNC Java
-applet is provided in classes/ssl that does SSL
+Also, in the x11vnc distribution, a patched TightVNC
+Java applet is provided in classes/ssl that does SSL
 connections (only).
 .IP
 It is also not too difficult to set up an stunnel or
-other SSL tunnel on the viewer side.
-.IP
-A simple example on Unix using stunnel 3.x is:
+other SSL tunnel on the viewer side.  A simple example
+on Unix using stunnel 3.x is:
 .IP
 % stunnel \fB-c\fR \fB-d\fR localhost:5901 \fB-r\fR remotehost:5900
 % vncviewer localhost:1
@@ -842,9 +1211,10 @@ Store password \fIpass\fR as the VNC password in the
 file \fIfile\fR.  Once the password is stored the
 program exits.  Use the password via "\fB-rfbauth\fR \fIfile\fR"
 .IP
-If called with no arguments, i.e., "\fB-storepasswd\fR",
+If called with no arguments, "x11vnc \fB-storepasswd",\fR
 the user is prompted for a password and it is stored
-in the file ~/.vnc/passwd
+in the file ~/.vnc/passwd.  Called with one argument,
+that will be the file to store the prompted password in.
 .PP
 \fB-nopw\fR
 .IP
@@ -1078,12 +1448,9 @@ each rectangle.  If one of the items on the list is the
 string "noptr" the mouse pointer will not be allowed
 to go into a blacked out region.
 .PP
-\fB-xinerama\fR
+\fB-xinerama,\fR \fB-noxinerama\fR
 .IP
 If your screen is composed of multiple monitors
-.PP
-\fB-noxinerama\fR
-.IP
 glued together via XINERAMA, and that screen is
 not a rectangle this option will try to guess the
 areas to black out (if your system has libXinerama).
@@ -2086,12 +2453,9 @@ slow links that take a long time to paint the first
 screen libvncserver may hit the timeout and drop the
 connection.  Default: 20 seconds.
 .PP
-\fB-nap\fR
+\fB-nap,\fR \fB-nonap\fR
 .IP
 Monitor activity and if it is low take longer naps
-.PP
-\fB-nonap\fR
-.IP
 between screen polls to really cut down load when idle.
 Default: take naps
 .PP
@@ -2101,6 +2465,26 @@ Time in seconds after NO activity (e.g. screen blank)
 to really throttle down the screen polls (i.e. sleep
 for about 1.5 secs). Use 0 to disable.  Default: 60
 .PP
+\fB-nofbpm,\fR \fB-fbpm\fR
+.IP
+If the system supports the FBPM (Frame Buffer Power
+Management) extension (i.e. some Sun systems), then
+prevent the video h/w from going into a reduced power
+state when VNC clients are connected.
+.IP
+FBPM capable video h/w save energy when the workstation
+is idle by going into low power states (similar to DPMS
+for monitors).  This interferes with x11vnc's polling
+of the framebuffer data.
+.IP
+"\fB-nofbpm\fR" means prevent FBPM low power states whenever
+VNC clients are connected, while "\fB-fbpm\fR" means to not
+monitor the FBPM state at all.  See the 
+.IR xset (1)
+manpage
+for details.  \fB-nofbpm\fR is basically the same as running
+"xset fbpm force on" periodically.  Default: \fB-fbpm\fR
+.PP
 \fB-noxdamage\fR
 .IP
 Do not use the X DAMAGE extension to detect framebuffer
@@ -2760,6 +3144,10 @@ nonap           disable \fB-nap\fR mode.
 .IP
 sb:n            set \fB-sb\fR to n s, same as screen_blank:n
 .IP
+fbpm            disable \fB-nofbpm\fR mode.
+.IP
+nofbpm          enable  \fB-nofbpm\fR mode.
+.IP
 xdamage         enable  xdamage polling hints.
 .IP
 noxdamage       disable xdamage polling hints.
@@ -2937,8 +3325,8 @@ pm input_skip input client_input speeds wmdt
 debug_pointer dp nodebug_pointer nodp debug_keyboard
 dk nodebug_keyboard nodk deferupdate defer wait_ui
 wait_bog nowait_bog slow_fb wait readtimeout nap nonap
-sb screen_blank fs gaps grow fuzz snapfb nosnapfb
-rawfb progressive rfbport http nohttp httpport
+sb screen_blank fbpm nofbpm fs gaps grow fuzz snapfb
+nosnapfb rawfb progressive rfbport http nohttp httpport
 httpdir enablehttpproxy noenablehttpproxy alwaysshared
 noalwaysshared nevershared noalwaysshared dontdisconnect
 nodontdisconnect desktop debug_xevents nodebug_xevents