neulab/tldr huggingface dataset:
Set -env STUNNEL_LISTEN=xxx to the address of the network interface to listen on (the default is to listen on all interfaces), e.g. STUNNEL_LISTEN=192.168.1.100.
A simple way to add IPv6 support is STUNNEL_LISTEN=::
Your VNC viewer will also need to be able to connect via SSL. Unfortunately not too many do this.  See the information about SSL viewers under the -ssl option.  The x11vnc project's SSVNC is an option.
Also, in the x11vnc distribution, patched TightVNC and UltraVNC Java applet jar files are provided in the classes/ssl directory that do SSL connections.  Enable serving them with the -http, -http_ssl, or -httpdir (see the option descriptions for more info.)
Note that for the Java viewer applet usage the "?PORT=xxxx" in the various URLs printed at startup will need to be supplied to the web browser to connect properly.
Currently the automatic "single port" HTTPS mode of -ssl is not fully supported in -stunnel mode.  However, it can be emulated via:
% x11vnc -stunnel -http_ssl -http_oneport ...
In general, it is also not too difficult to set up an stunnel or other SSL tunnel on the viewer side.  A simple example on Unix using stunnel 3.x is:
% stunnel -c -d localhost:5901 -r remotehost:5900 % vncviewer localhost:1
For Windows, stunnel has been ported to it and there are probably other such tools available.  See the FAQ and SSVNC for more examples.
-stunnel3 [pem]
Use version 3.x stunnel command line syntax instead of version 4.x.  The -http/-httpdir Java applet serving is currently not available in this mode.
-enc cipher:keyfile
Use symmetric encryption with cipher "cipher" and secret key data in "keyfile".  If keyfile is pw=<string> then "string" is used as the key data.
NOTE: It is recommended that you use SSL via the -ssl option instead of this option because SSL is well understood and takes great care to establish unique session keys and is more compatible with other software.  Use this option if you do not want to deal with SSL certificates for authentication and do not want to use SSH but want some encryption for your VNC session.  Or if you must interface with a symmetric key tunnel that you do not have control over.
Note that this mode will NOT work with the UltraVNC DSM plugins because they alter the RFB protocol in addition to tunnelling with the symmetric cipher (an unfortunate choice of implementation...)
cipher can be one of:  arc4, aesv2, aes-cfb, blowfish, aes256, or 3des.  See the OpenSSL documentation for more info.  The keysize is 128 bits (except for aes256).  Here is one way to make a keyfile with that many bits:
dd if=/dev/random of=./my.key bs=16 count=1
you will need to securely share this key with the other side of the VNC connection (See SSVNC for examples).
Example:  -enc blowfish:./my.key Example:  -enc blowfish:pw=swordfish
By default 16 bytes of random salt followed by 16 bytes of random initialization vector are sent at the very beginning of the stream.  The other side must read these and initialize their cipher with them.  These values make the session key unique (without them the security is minimal).  Similarly, the other side must send us its random salt and IV with those same lengths.
The salt and key data are combined to create a session key using an md5 hash as described in EVP_BytesToKey(3).
The exact call is: EVP_BytesToKey(Cipher, EVP_md5(), salt, keydata, len, 1, keystr, NULL);  where salt is the random data as described above, and keydata is the shared secret key data. keystr is the resulting session key.  The cipher is then seeded with keystr and uses the random initialization vector as its first block.
To modify the amount of random salt and initialization vector use cipher@n,m where n is the salt length and m the initialization vector length.  E.g.
-enc aes-cfb@8,16:./my.key
It is not a good idea to set either one to zero, although you may be forced to if the other side of the tunnel is not under your control.
To skip the salt and EVP_BytesToKey MD5 entirely (no hashing is done: the keydata is directly inserted into the cipher) specify "-1" for the salt, e.g.
-enc blowfish@-1,16:./my.key
The message digest can also be changed to something besides the default MD5.  Use cipher@md+n,m where "md" can be one of sha, sha1, md5, or ripe.  For example:
-enc arc4@sha+8,16:./my.key
The SSVNC vnc viewer project supplies a symmetric encryption tool named "ultravnc_dsm_helper" that can be used on the viewer side. For example:
ssvncviewer exec='ultravnc_dsm_helper arc4 my.key 0 h:p'
where h:p is the hostname and port of the x11vnc server. ultravnc_dsm_helper may also be used standalone to provide a symmetric encryption tunnel for any viewer or server (VNC or otherwise.) The cipher (1st arg) is basically the same syntax as we use above.
Also see the 'Non-Ultra DSM' SSVNC option for the ´UltraVNC DSM Encryption Plugin' advanced option.
For both ways of using the viewer, you can specify the salt,ivec sizes (in GUI or, e.g. arc4@8,16).
-https [port]
Use a special, separate HTTPS port (-ssl and -stunnel modes only) for HTTPS Java viewer applet downloading. I.e. not 5900 and not 5800 (the defaults.)
BACKGROUND: In -ssl mode, it turns out you can use the single VNC port (e.g. 5900) for both VNC and HTTPS connections. (HTTPS is used to retrieve a SSL-aware VncViewer.jar applet that is provided with x11vnc).  Since both use SSL the implementation was extended to detect if HTTP traffic (i.e. GET) is taking place and handle it accordingly.  The URL would be, e.g.:
https://mymachine.org:5900/
This is convenient for firewalls, etc, because only one port needs to be allowed in.  However, this heuristic adds a few seconds delay to each connection and can be unreliable (especially if the user takes much time to ponder the Certificate dialogs in his browser, Java VM, or VNC Viewer applet.  That's right 3 separate "Are you sure you want to connect?" dialogs!)
END OF BACKGROUND.
USAGE: So use the -https option to provide a separate, more reliable HTTPS port that x11vnc will listen on.  If [port] is not provided (or is 0), one is autoselected.  The URL to use is printed out at startup.
The SSL Java applet directory is specified via the -httpdir option.  If not supplied, -https will try to guess the directory as though the -http option was supplied.
-httpsredir [port]
In -ssl mode with the Java applet retrieved via HTTPS, when the HTML file containing applet parameters ('index.vnc' or 'proxy.vnc') is sent do NOT set the applet PORT parameter to the actual VNC port but set it to "port" instead.  If "port" is not supplied, then the port number is guessed from the Host: HTTP header.
This is useful when an incoming TCP connection redirection is performed by a router/gateway/firewall from one port to an internal machine where x11vnc is listening on a different port. The Java applet needs to connect to the firewall/router port, not the VNC port on the internal workstation. For example, one could redir from mygateway.com:443 to workstation:5900.
This spares the user from having to type in https://mygateway.com/?PORT=443 into their web browser. Note that port 443 is the default https port; other ports must be explicitly indicated, for example: https://mygateway.com:8000/?PORT=8000.  To avoid having to include the PORT= in the browser URL, simply supply "-httpsredir" to x11vnc.
This option does not work in -stunnel mode.
More tricks: set the env var X11VNC_EXTRA_HTTPS_PARAMS to be extra URL parameters to use.  This way you do not need to specify extra PARAMS in the index.vnc file.  E.g. x11vnc -env X11VNC_EXTRA_HTTPS_PARAMS='?GET=1' ...
If you do not want to expose the non-SSL HTTP port to the network (i.e. you just want the single VNC/HTTPS port, e.g. 5900, open for connections) then specify the option -env X11VNC_HTTP_LISTEN_LOCALHOST=1  This way the connection to the LibVNCServer httpd server will only be available on localhost (note that in -ssl mode, HTTPS requests are redirected from SSL to the non-SSL LibVNCServer HTTP server.)
-http_oneport
For UN-encrypted connections mode (i.e. no -ssl, -stunnel, or -enc options), allow the Java VNC Viewer applet to be downloaded thru the VNC port via HTTP.
That is to say, you can use a single port for Java applet viewer connections by using a URL in your web browser like this, for example:
http://hostname:5900
The regular, two-port mode, URL http://hostname:5800 will continue to work as well.
As mentioned above, this mode will NOT work with the -ssl, -stunnel, or -enc encryption options.  Note that is it equivalent to '-enc none' (i.e. it uses the same detection mechanism as for HTTPS, but with no encryption.)
HTTPS single-port is on by default in -ssl encrypted mode (and -enc too), so you only need -http_oneport when doing non-SSL encrypted connections.
This mode could also be useful for SSH tunnels since it means only one port needs to be redirected.
The -httpsredir option may also be useful for this mode when using an SSH tunnel as well as for router port redirections.
Note that the -env X11VNC_HTTP_LISTEN_LOCALHOST=1 option described above under -httpsredir applies for the LibVNCServer httpd server in all cases (ssl or not.)
-ssh user@host:disp
Create a remote listening port on machine "host" via a SSH tunnel using the -R rport:localhost:lport method. lport will be the local x11vnc listening port, so a connection to rport (5900+disp) on "host" will reach x11vnc.  E.g. fred@snoopy.com:0
This could be useful if a firewall/router prevents incoming connections to the x11vnc machine, but the ssh machine "host" can be reached by the VNC viewer. "user@" is not needed unless the remote unix username differs from the current one.
By default the remote sshd is usually configured to listen only on localhost for rport, so the viewer may need to ssh -L redir to "host" as well (See SSVNC to automate this).  The sshd setting GatewayPorts enables listening on all interfaces for rport; viewers can reach it more easily.
"disp" is the VNC display for the remote SSH side, e.g. 0 corresponds to port 5900, etc.  If disp is greater than 200 the value is used as the port.  Use a negative value to force a low port, e.g. host:-80 will use port 80.
If ssh-agent is not active, then the ssh password needs to be entered in the terminal where x11vnc is running.
By default the remote ssh will issue a 'sleep 300' to wait for the incoming connection for 5 mins.  To modify this use user@host:disp+secs.
If the remote SSH server is on a non-standard port (i.e. not 22) use user@host:port:disp+secs.
Note that the ssh process MAY NOT be killed when x11vnc exits.  It tries by looking at ps(1) output.
-usepw
If no other password method was supplied on the command line, first look for ~/.vnc/passwd and if found use it with -rfbauth; next, look for ~/.vnc/passwdfile and use it with -passwdfile; otherwise, prompt the user for a password to create ~/.vnc/passwd and use it with the -rfbauth option.  If none of these succeed x11vnc exits immediately.
-storepasswd pass file
Store password pass as the VNC password in the file file.  Once the password is stored the program exits.  Use the password via "-rfbauth file"
If called with no arguments, "x11vnc -storepasswd", the user is prompted for a password and it is stored in the file ~/.vnc/passwd.  Called with one argument, that will be the file to store the prompted password in.
-nopw
Disable the big warning message when you use x11vnc without some sort of password.
-accept string
Run a command (possibly to prompt the user at the X11 display) to decide whether an incoming client should be allowed to connect or not.  string is an external command run via system(3) or some special cases described below.  Be sure to quote string if it contains spaces, shell characters, etc.  If the external command returns 0 the client is accepted, otherwise the client is rejected.  See below for an extension to accept a client view- only.
If x11vnc is running as root (say from inetd(8) or from display managers xdm(1) , gdm(1) , etc), think about the security implications carefully before supplying this option (likewise for the -gone option).
Environment: The RFB_CLIENT_IP environment variable will be set to the incoming client IP number and the port in RFB_CLIENT_PORT (or -1 if unavailable).  Similarly, RFB_SERVER_IP and RFB_SERVER_PORT (the x11vnc side of the connection), are set to allow identification of the tcp virtual circuit.  The x11vnc process id will be in RFB_X11VNC_PID, a client id number in RFB_CLIENT_ID, and the number of other connected clients in RFB_CLIENT_COUNT. RFB_MODE will be "accept".  RFB_STATE will be PROTOCOL_VERSION, SECURITY_TYPE, AUTHENTICATION, INITIALISATION, NORMAL, or UNKNOWN indicating up to which state the client has achieved. RFB_LOGIN_VIEWONLY will be 0, 1, or -1 (unknown).  RFB_USERNAME, RFB_LOGIN_TIME, and RFB_CURRENT_TIME may also be set.
If string is "popup" then a builtin popup window is used.  The popup will time out after 120 seconds, use "popup:N" to modify the timeout to N seconds (use 0 for no timeout).
In the case of "popup" and when the -unixpw option is specified, then a *second* window will be popped up after the user successfully logs in via his UNIX password.  This time the user will be identified as UNIX:username@hostname, the "UNIX:" prefix indicates which user the viewer logged as via -unixpw.  The first popup is only for whether to allow him to even *try* to login via unix password.
If string is "xmessage" then an xmessage(1) invocation is used for the command.  xmessage must be installed on the machine for this to work.
Both "popup" and "xmessage" will present an option for accepting the client "View-Only" (the client can only watch).  This option will not be presented if -viewonly has been specified, in which case the entire display is view only.
If the user supplied command is prefixed with something like "yes:0,no:*,view:3 mycommand ..." then this associates the numerical command return code with the actions: accept, reject, and accept-view-only, respectively.  Use "*" instead of a number to indicate the default action (in case the command returns an unexpected value).  E.g. "no:*" is a good choice.
Note that x11vnc blocks while the external command or popup is running (other clients may see no updates during this period).  So a person sitting a the physical display is needed to respond to an popup prompt. (use a 2nd x11vnc if you lock yourself out).
More -accept tricks: use "popupmouse" to only allow mouse clicks in the builtin popup to be recognized.  Similarly use "popupkey" to only recognize keystroke responses.  These are to help avoid the user accidentally accepting a client by typing or clicking. All 3 of the popup keywords can be followed by +N+M to supply a position for the popup window.  The default is to center the popup window.
-afteraccept string
As -accept, except to run a user supplied command after a client has been accepted and authenticated. RFB_MODE will be set to "afteraccept" and the other RFB_* variables are as in -accept. Unlike -accept, the command return code is not interpreted by x11vnc.  Example: -afteraccept 'killall xlock &'
-gone string
As -accept, except to run a user supplied command when a client goes away (disconnects).  RFB_MODE will be set to "gone" and the other RFB_* variables are as in -accept.  The "popup" actions apply as well.  Unlike -accept, the command return code is not interpreted by x11vnc.  Example: -gone 'xlock &'
-users list
If x11vnc is started as root (say from inetd(8) or from display managers xdm(1) , gdm(1) , etc), then as soon as possible after connections to the X display are established try to switch to one of the users in the comma separated list.  If x11vnc is not running as root this option is ignored.
Why use this option?  In general it is not needed since x11vnc is already connected to the X display and can perform its primary functions.  The option was added to make some of the *external* utility commands x11vnc occasionally runs work properly.  In particular under GNOME and KDE to implement the "-solid color" feature external commands (gconftool-2 and dcop) unfortunately must be run as the user owning the desktop session.  Since this option switches userid it also affects the userid used to run the processes for the -accept and -gone options.  It also affects the ability to read files for options such as -connect, -allow, and -remap and also the ultra and tight filetransfer feature if enabled.  Note that the -connect file is also sometimes written to.
So be careful with this option since in some situations its use can decrease security.
In general the switch to a user will only take place if the display can still be successfully opened as that user (this is primarily to try to guess the actual owner of the session). Example: "-users fred,wilma,betty".  Note that a malicious local user "barney" by quickly using "xhost +" when logging in may possibly get the x11vnc process to switch to user "fred".  What happens next?
Under display managers it may be a long time before the switch succeeds (i.e. a user logs in).  To instead make it switch immediately regardless if the display can be reopened prefix the username with the "+" character. E.g. "-users +bob" or "-users +nobody".
The latter (i.e. switching immediately to user "nobody") is the only obvious use of the -users option that increases security.
Use the following notation to associate a group with a user: user1.group1,user2.group2,...  Note that initgroups(2) will still be called first to try to switch to ALL of a user's groups (primary and additional groups).  Only if that fails or it is not available then the single group specified as above (or the user's primary group if not specified) is switched to with setgid(2). Use -env X11VNC_SINGLE_GROUP=1 to prevent trying initgroups(2) and only switch to the single group.  This sort of setting is only really needed to make the ultra or tight filetransfer permissions work properly. This format applies to any comma separated list of users, even the special "=" modes described below.
In -unixpw mode, if "-users unixpw=" is supplied then after a user authenticates himself via the -unixpw mechanism, x11vnc will try to switch to that user as though "-users +username" had been supplied.  If you want to limit which users this will be done for, provide them as a comma separated list after "unixpw=" Groups can also be specified as described above.
Similarly, in -ssl mode, if "-users sslpeer=" is supplied then after an SSL client authenticates with his cert (the -sslverify option is required for this) x11vnc will extract a UNIX username from the "emailAddress" field (username@hostname.com) of the "Subject" of the x509 SSL cert and then try to switch to that user as though "-users +username" had been supplied.  If you want to limit which users this will be done for, provide them as a comma separated list after "sslpeer=".  Set the env. var X11VNC_SSLPEER_CN to use the Common Name (normally a hostname) instead of the Email field.
NOTE: for sslpeer= mode the x11vnc administrator must take care that any client certs he adds to -sslverify have the intended UNIX username in the "emailAddress" field of the cert.  Otherwise a user may be able to log in as another.  This command can be of use in checking: "openssl x509 -text -in file.crt", see the "Subject:" line.  Also, along with the normal RFB_* env. vars. (see -accept) passed to external cmd= commands, RFB_SSL_CLIENT_CERT will be set to the client's x509 certificate string.
The sslpeer= mode can aid finding X sessions via the FINDDISPLAY and FINDCREATEDISPLAY mechanisms.
To immediately switch to a user *before* connections to the X display are made or any files opened use the "=" character: "-users =bob".  That user needs to be able to open the X display and any files of course.
The special user "guess=" means to examine the utmpx database (see who(1) ) looking for a user attached to the display number (from DISPLAY or -display option) and try him/her.  To limit the list of guesses, use: "-users guess=bob,betty".
Even more sinister is the special user "lurk=" that means to try to guess the DISPLAY from the utmpx login database as well.  So it "lurks" waiting for anyone to log into an X session and then connects to it.  Specify a list of users after the = to limit which users will be tried.  To enable a different searching mode, if the first user in the list is something like ":0" or ":0-2" that indicates a range of DISPLAY numbers that will be tried (regardless of whether they are in the utmpx database) for all users that are logged in.  Also see the "-display WAIT:..." functionality.  Examples: "-users lurk=" and also "-users lurk=:0-1,bob,mary"
Be especially careful using the "guess=" and "lurk=" modes.  They are not recommended for use on machines with untrustworthy local users.
-noshm
Do not use the MIT-SHM extension for the polling.  Remote displays can be polled this way: be careful this can use large amounts of network bandwidth.  This is also of use if the local machine has a limited number of shm segments and -onetile is not sufficient.
-flipbyteorder
Sometimes needed if remotely polled host has different endianness. Ignored unless -noshm is set.
-onetile
Do not use the new copy_tiles() framebuffer mechanism, just use 1 shm tile for polling.  Limits shm segments used to 3.
To disable any automatic shm reduction set the env. var. X11VNC_NO_LIMIT_SHM.
-solid [color]
To improve performance, when VNC clients are connected try to change the desktop background to a solid color.  The [color] is optional: the default color is "cyan4".  For a different one specify the X color (rgb.txt name, e.g. "darkblue" or numerical "#RRGGBB").
Currently this option only works on GNOME, KDE, CDE, XFCE, and classic X (i.e. with the background image on the root window). The "gconftool-2", "dcop" and "xfconf-query" external commands are run for GNOME, KDE, and XFCE respectively.  This also works on native MacOSX.  (There is no color selection for MacOSX or XFCE.) Other desktops won't work, (send us the corresponding commands if you find them).  If x11vnc is running as root ( inetd(8) or gdm(1) ), the -users option may be needed for GNOME, KDE, XFCE.  If x11vnc guesses your desktop incorrectly, you can force it by prefixing color with "gnome:", "kde:", "cde:", "xfce:", or "root:".
Update: -solid no longer works on KDE4.
This mode works in a limited way on the Mac OS X Console with one color ('kelp') using the screensaver writing to the background. Look in "~/Library/Screen Savers" for VncSolidColor.png to change the color.
-blackout string
Black out rectangles on the screen. string is a comma separated list of WxH+X+Y type geometries for 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.
-xinerama, -noxinerama
If your screen is composed of multiple monitors 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). default: -xinerama
In general, we have noticed on XINERAMA displays you may need to use the "-xwarppointer" option if the mouse pointer misbehaves and it is enabled by default. Use "-noxwarppointer" if you do not want this.
-xtrap
Use the DEC-XTRAP extension for keystroke and mouse input insertion.  For use on legacy systems, e.g. X11R5, running an incomplete or missing XTEST extension.  By default DEC-XTRAP will be used if XTEST server grab control is missing, use -xtrap to do the keystroke and mouse insertion via DEC-XTRAP as well.
-xrandr [mode]
If the display supports the XRANDR (X Resize, Rotate and Reflection) extension, and you expect XRANDR events to occur to the display while x11vnc is running, this options indicates x11vnc should try to respond to them (as opposed to simply crashing by assuming the old screen size).  See the xrandr(1) manpage and run ´xrandr -q' for more info.  [mode] is optional and described below.
Since watching for XRANDR events and trapping errors increases polling overhead, only use this option if XRANDR changes are expected.  For example on a rotatable screen PDA or laptop, or using a XRANDR-aware Desktop where you resize often.  It is best to be viewing with a vncviewer that supports the NewFBSize encoding, since it knows how to react to screen size changes. Otherwise, LibVNCServer tries to do so something reasonable for viewers that cannot do this (portions of the screen may be clipped, unused, etc).
Note: the default now is to check for XRANDR events, but do not trap every X call that may fail due to resize.  If a resize event is received, the full -xrandr mode is enabled.  To disable even checking for events supply: -noxrandr.
"mode" defaults to "resize", which means create a new, resized, framebuffer and hope all viewers can cope with the change. "newfbsize" means first disconnect all viewers that do not support the NewFBSize VNC encoding, and then resize the framebuffer. "exit" means disconnect all viewer clients, and then terminate x11vnc.
-rotate string
Rotate and/or flip the framebuffer view exported by VNC.  This transformation is independent of XRANDR and is done in software in main memory and so may be slower.  This mode could be useful on a handheld with portrait or landscape modes that do not correspond to the scanline order of the actual framebuffer.  string can be:
x     flip along x-axis y     flip along y-axis xy     flip along x- and y-axes +90     rotate 90 degrees clockwise -90     rotate 90 degrees counter-clockwise +90x     rotate 90 degrees CW, then flip along x +90y     rotate 90 degrees CW, then flip along y
these give all possible rotations and reflections.
Aliases: same as xy:  yx, +180, -180, 180 same as -90: +270, 270 same as +90: 90, (ditto for 90x, 90y)
Like -scale, this transformation is applied at the very end of any chain of framebuffer transformations and so any options with geometries, e.g. -blackout, -clip, etc.  are relative to the original X (or -rawfb) framebuffer, not the final one sent to VNC viewers.
If you do not want the cursor shape to be rotated prefix string with "nc:", e.g. "nc:+90", "nc:xy", etc.
-padgeom WxH
Whenever a new vncviewer connects, the framebuffer is replaced with a fake, solid black one of geometry WxH.  Shortly afterwards the framebuffer is replaced with the real one.  This is intended for use with vncviewers that do not support NewFBSize and one wants to make sure the initial viewer geometry will be big enough to handle all subsequent resizes (e.g. under -xrandr, -remote id:windowid, rescaling, etc.)
In -unixpw mode this sets the size of the login screen.  Use "once:WxH" it ignore padgeom after the login screen is set up.
-o logfile
Write stderr messages to file logfile instead of to the terminal. Same as "-logfile file".  To append to the file use "-oa file" or "-logappend file".  If logfile contains the string "%VNCDISPLAY" it is expanded to the vnc display (the name may need to be guessed at.)  "%HOME" works too.
-flag file
Write the "PORT=NNNN" (e.g. PORT=5900) string to file in addition to stdout.  This option could be useful by wrapper script to detect when x11vnc is ready.
-rmflag file
Remove file at exit to signal when x11vnc is done.  The file is created at startup if it does not already exist or if file is prefixed with "create:".  If the file is created, the x11vnc PID is placed in the file.  Otherwise the files contents is not changed.  Use prefix "nocreate:" to prevent creation.
-rc filename
Use filename instead of $HOME/.x11vncrc for rc file.
-norc
Do not process any .x11vncrc file for options.
-env VAR=VALUE
Set the environment variable 'VAR' to value 'VALUE' at x11vnc startup.  This is a convenience utility to avoid shell script wrappers, etc. to set the env. var.  You may specify as many of these as needed on the command line.
-prog /path/to/x11vnc
Set the full path to the x11vnc program for cases when it cannot be determined from argv[0] (e.g. tcpd/inetd)
-h, -help
Print this help text.  -?, -opts              Only list the x11vnc options.
-V, -version
Print program version and last modification date.
Print out license information.  Same as -copying and -warranty.
Instead of exiting after cleaning up, run a simple "debug crash shell" when fatal errors are trapped.
-q, -quiet
Be quiet by printing less informational output to stderr. (use -noquiet to undo an earlier -quiet.)
The -quiet option does not eliminate all informational output, it only reduces it.  It is ignored in most auxiliary usage modes, e.g. -storepasswd.  To eliminate all output use: 2>/dev/null 1>&2, etc.
-v, -verbose
Print out more information to stderr.
-bg
Go into the background after screen setup.  Messages to stderr are lost unless -o logfile is used.  Something like this could be useful in a script:
port=`ssh -t $host "x11vnc -display :0 -bg" | grep PORT`
port=`echo "$port" | sed -e 's/PORT=//'`
port=`expr $port - 5900`
vncviewer $host:$port
-modtweak, -nomodtweak
Option -modtweak automatically tries to adjust the AltGr and Shift modifiers for differing language keyboards between client and host.  Otherwise, only a single key press/release of a Keycode is simulated (i.e. ignoring the state of the modifiers: this usually works for identical keyboards).  Also useful in resolving cases where a Keysym is bound to multiple keys (e.g. "<" + ">" and "," + "<" keys).  Default: -modtweak
If you are having trouble with with keys and -xkb or -noxkb, and similar things don't help, try -nomodtweak.
On some HP-UX systems it is been noted that they have an odd keymapping where a single keycode will have a keysym, e.g. "#", up to three times.  You can check via "xmodmap -pk" or the -dk option.  The failure is when you try to type "#" it yields "3". If you see this problem try setting the environment variable MODTWEAK_LOWEST=1 to see if it helps.
-xkb, -noxkb
When in modtweak mode, use the XKEYBOARD extension (if the X display supports it) to do the modifier tweaking.  This is powerful and should be tried if there are still keymapping problems when using -modtweak by itself.  The default is to check whether some common keysyms, e.g. !, @, [, are only accessible via -xkb mode and if so then automatically enable the mode.  To disable this automatic detection use -noxkb.
When -xkb mode is active you can set these env. vars.  They apply only when there is ambiguity as to which key to choose (i.e the mapping is not one-to-one).  NOKEYHINTS=1: for up ascii keystrokes do not use score hints saved when the key was pressed down. NOANYDOWN=1: for up keystrokes do not resort to searching through keys that are currently pressed down.  KEYSDOWN=N: remember the last N keys press down for tie-breaking when an up keystroke comes in.
-capslock
When in -modtweak (the default) or -xkb mode, if a keysym in the range A-Z comes in check the X server to see if the Caps_Lock is set.  If it is do not artificially press Shift to generate the keysym.  This will enable the CapsLock key to behave correctly in some circumstances: namely *both* the VNC viewer machine and the x11vnc X server are in the CapsLock on state.  If one side has CapsLock on and the other off and the keyboard is not behaving as you think it should you should correct the CapsLock states (hint: pressing CapsLock inside and outside of the viewer can help toggle them both to the correct state).  However, for best results do not use this option, but rather *only* enable CapsLock on the VNC viewer side (i.e. by pressing CapsLock outside of the viewer window, also -skip_lockkeys below).  Also try -nomodtweak for a possible workaround.
-skip_lockkeys, -noskip_lockkeys
Have x11vnc ignore all Caps_Lock, Shift_Lock, Num_Lock, Scroll_Lock keysyms received from viewers.  The idea is you press Caps_Lock on the VNC Viewer side but that does not change the lock state in the x11vnc-side X server.  Nevertheless your capitalized letters come in over the wire and are applied correctly to the x11vnc-side X server.  Note this mode probably won't do what you want in -nomodtweak mode.  Also, a kludge for KP_n digits is always done in this mode: they are mapped to regular digit keysyms.  See also -capslock above.  The default is -noskip_lockkeys.
-skip_keycodes string
Ignore the comma separated list of decimal keycodes.  Perhaps these are keycodes not on your keyboard but your X server thinks exist.  Currently only applies to -xkb mode.  Use this option to help x11vnc in the reverse problem it tries to solve: Keysym -> Keycode(s) when ambiguities exist (more than one Keycode per Keysym).  Run 'xmodmap -pk' to see your keymapping.  Example: "-skip_keycodes 94,114"
-sloppy_keys
Experimental option that tries to correct some "sloppy" key behavior.  E.g. if at the viewer you press Shift+Key but then release the Shift before Key that could give rise to extra unwanted characters (usually only between keyboards of different languages).  Only use this option if you observe problems with some keystrokes.
-skip_dups, -noskip_dups
Some VNC viewers send impossible repeated key events, e.g. key- down, key-down, key-up, key-up all for the same key, or 20 downs in a row for the same modifier key!  Setting -skip_dups means to skip these duplicates and just process the first event. Note: some VNC viewers assume they can send down's without the corresponding up's and so you should not set this option for these viewers (symptom: some keys do not autorepeat) Default: -noskip_dups
-add_keysyms, -noadd_keysyms
If a Keysym is received from a VNC viewer and that Keysym does not exist in the X server, then add the Keysym to the X server's keyboard mapping on an unused key.  Added Keysyms will be removed periodically and also when x11vnc exits.  Default: -add_keysyms
-clear_mods
At startup and exit clear the modifier keys by sending KeyRelease for each one. The Lock modifiers are skipped.  Used to clear the state if the display was accidentally left with any pressed down.
-clear_keys
As -clear_mods, except try to release ANY pressed key.  Note that this option and -clear_mods can interfere with a person typing at the physical keyboard.
-clear_all
As -clear_keys, except try to release any CapsLock, NumLock, etc. locks as well.
-remap string
Read Keysym remappings from file named string.  Format is one pair of Keysyms per line (can be name or hex value) separated by a space.  If no file named string exists, it is instead interpreted as this form: key1-key2,key3-key4,...  See <X11/keysymdef.h> header file for a list of Keysym names, or use xev(1).
To map a key to a button click, use the fake Keysyms "Button1", ..., etc. E.g: "-remap Super_R-Button2" (useful for pasting on a laptop)
I use these if the machine I am viewing from does not have a scrollwheel or I don't like using the one it has:
-remap Super_R-Button4,Menu-Button5 -remap KP_Add- Button4,KP_Enter-Button5
the former would be used on a PC, the latter on a MacBook.  This way those little used keys can be used to generate bigger hops than the Up and Down arrows provide.  One can scroll through text or web pages more quickly this way (especially if x11vnc scroll detection is active.)
Use Button44, Button12, etc. for multiple clicks.
To disable a keysym (i.e. make it so it will not be injected), remap it to "NoSymbol" or "None".
Dead keys: "dead" (or silent, mute) keys are keys that do not produce a character but must be followed by a 2nd keystroke.  This is often used for accenting characters, e.g. to put "`" on top of "a" by pressing the dead key and then "a".  Note that this interpretation is not part of core X11, it is up to the toolkit or application to decide how to react to the sequence.  The X11 names for these keysyms are "dead_grave", "dead_acute", etc.  However some VNC viewers send the keysyms "grave", "acute" instead thereby disabling the accenting.  To work around this -remap can be used. For example "-remap grave-dead_grave,acute-dead_acute"
As a convenience, "-remap DEAD" applies these remaps:
g     grave-dead_grave a     acute-dead_acute c     asciicircum-dead_circumflex t     asciitilde-dead_tilde m     macron-dead_macron b     breve-dead_breve D     abovedot-dead_abovedot d     diaeresis-dead_diaeresis o     degree-dead_abovering A     doubleacute-dead_doubleacute r     caron-dead_caron e     cedilla-dead_cedilla
If you just want a subset use the first letter label, e.g. "-remap DEAD=ga" to get the first two.  Additional remaps may also be supplied via commas, e.g.  "-remap DEAD=ga,Super_R-Button2". Finally, "DEAD=missing" means to apply all of the above as long as the left hand member is not already in the X11 keymap.
-norepeat, -repeat
Option -norepeat disables X server key auto repeat when VNC clients are connected and VNC keyboard input is not idle for more than 5 minutes.  This works around a repeating keystrokes bug (triggered by long processing delays between key down and key up client events: either from large screen changes or high latency). Default: -norepeat
You can set the env. var. X11VNC_IDLE_TIMEOUT to the number of idle seconds you want (5min = 300secs).
Note: your VNC viewer side will likely do autorepeating, so this is no loss unless someone is simultaneously at the real X display.
Use "-norepeat N" to set how many times norepeat will be reset if something else (e.g. X session manager) undoes it.  The default is 2.  Use a negative value for unlimited resets.
-nofb
Ignore video framebuffer: only process keyboard and pointer. Intended for use with Win2VNC and x2vnc dual-monitor setups.
-nobell
Do not watch for XBell events. (no beeps will be heard) Note: XBell monitoring requires the XKEYBOARD extension.
-nosel
Do not manage exchange of X selection/cutbuffer between VNC viewers and the X server at all.
-noprimary
Do not poll the PRIMARY selection for changes to send back to clients.  (PRIMARY is still set on received changes, however).
-nosetprimary
Do not set the PRIMARY selection for changes received from VNC clients.
-noclipboard
Do not poll the CLIPBOARD selection for changes to send back to clients.  (CLIPBOARD is still set on received changes, however).
-nosetclipboard
Do not set the CLIPBOARD selection for changes received from VNC clients.
-seldir string
If direction string is "send", only send the selection to viewers, and if it is "recv" only receive it from viewers.  To work around apps setting the selection too frequently and messing up the other end.  You can actually supply a comma separated list of directions, including "debug" to turn on debugging output.
-cursor [mode], -nocursor
Sets how the pointer cursor shape (little icon at the mouse pointer) should be handled.  The "mode" string is optional and is described below.  The default is to show some sort of cursor shape(s).  How this is done depends on the VNC viewer and the X server.  Use -nocursor to disable cursor shapes completely.
Some VNC viewers support the TightVNC CursorPosUpdates and CursorShapeUpdates extensions (cuts down on network traffic by not having to send the cursor image every time the pointer is moved), in which case these extensions are used (see -nocursorshape and -nocursorpos below to disable).  For other viewers the cursor shape is written directly to the framebuffer every time the pointer is moved or changed and gets sent along with the other framebuffer updates.  In this case, there will be some lag between the vnc viewer pointer and the remote cursor position.
If the X display supports retrieving the cursor shape information from the X server, then the default is to use that mode.  On Solaris this can be done with the SUN_OVL extension using -overlay (see also the -overlay_nocursor option).  A similar overlay scheme is used on IRIX.  Xorg (e.g. Linux) and recent Solaris Xsun servers support the XFIXES extension to retrieve the exact cursor shape from the X server.  If XFIXES is present it is preferred over Overlay and is used by default (see -noxfixes below).  This can be disabled with -nocursor, and also some values of the "mode" option below.
Note that under XFIXES cursors with transparency (alpha channel) will usually not be exactly represented and one may find Overlay preferable.  See also the -alphacut and -alphafrac options below as fudge factors to try to improve the situation for cursors with transparency for a given theme.
The "mode" string can be used to fine-tune the displaying of cursor shapes.  It can be used the following ways:
"-cursor arrow" - just show the standard arrow nothing more or nothing less.
"-cursor none" - same as "-nocursor"
"-cursor X" - when the cursor appears to be on the root window, draw the familiar X shape.  Some desktops such as GNOME cover up the root window completely, and so this will not work, try "X1", etc, to try to shift the tree depth.  On high latency links or slow machines there will be a time lag between expected and the actual cursor shape.
"-cursor some" - like "X" but use additional heuristics to try to guess if the window should have a windowmanager-like resizer cursor or a text input I-beam cursor.  This is a complete hack, but may be useful in some situations because it provides a little more feedback about the cursor shape.
"-cursor most" - try to show as many cursors as possible.  Often this will only be the same as "some" unless the display has overlay visuals or XFIXES extensions available.  On Solaris and IRIX if XFIXES is not available, -overlay mode will be attempted.
-cursor_drag
Show cursor shape changes even when the mouse is being dragged with a mouse button down.  This is useful if you want to be able to see Drag-and-Drop cursor icons, etc.
-arrow n
Choose an alternate "arrow" cursor from a set of some common ones. n can be 1 to 6.  Default is: 1 Ignored when in XFIXES cursor- grabbing mode.
-noxfixes
Do not use the XFIXES extension to draw the exact cursor shape even if it is available.
Note: To work around a crash in Xorg 1.5 and later some people needed to use -noxfixes.  The Xorg crash occurred right after a Display Manager (e.g. GDM) login.  Starting with x11vnc 0.9.9 it tries to automatically avoid using XFIXES until it is sure a window manager is running.  See the -reopen option for more info and how to use X11VNC_AVOID_WINDOWS=never to disable it.
-alphacut n
When using the XFIXES extension for the cursor shape, cursors with transparency will not usually be displayed exactly (but opaque ones will).  This option sets n as a cutoff for cursors that have transparency ("alpha channel" with values ranging from 0 to 255) Any cursor pixel with alpha value less than n becomes completely transparent.  Otherwise the pixel is completely opaque.  Default 240
-alphafrac fraction
With the threshold in -alphacut some cursors will become almost completely transparent because their alpha values are not high enough.  For those cursors adjust the alpha threshold until fraction of the non-zero alpha channel pixels become opaque. Default 0.33
-alpharemove
By default, XFIXES cursors pixels with transparency have the alpha factor multiplied into the RGB color values (i.e. that corresponding to blending the cursor with a black background). Specify this option to remove the alpha factor. (useful for light colored semi-transparent cursors).
-noalphablend
In XFIXES mode do not send cursor alpha channel data to LibVNCServer.  The default is to send it.  The alphablend effect will only be visible in -nocursorshape mode or for clients with cursorshapeupdates turned off. (However there is a hack for 32bpp with depth 24, it uses the extra 8 bits to store cursor transparency for use with a hacked vncviewer that applies the transparency locally.  See the FAQ for more info).
-nocursorshape
Do not use the TightVNC CursorShapeUpdates extension even if clients support it.  See -cursor above.
-cursorpos, -nocursorpos
Option -cursorpos enables sending the X cursor position back to all vnc clients that support the TightVNC CursorPosUpdates extension.  Other clients will be able to see the pointer motions. Default: -cursorpos
-xwarppointer, -noxwarppointer
Move the pointer with XWarpPointer(3X) instead of the XTEST extension.  Use this as a workaround if the pointer motion behaves incorrectly, e.g.  on touchscreens or other non-standard setups.
It is also sometimes needed on XINERAMA displays and is enabled by default if XINERAMA is found to be active.  To prevent this, use -noxwarppointer.
-always_inject
Even if there is no displacement (dx = dy = 0) for a VNC mouse event force the pointer to the indicated x,y position anyway. Recent (2009) gui toolkits (gnome) have problems with x11vnc's original mouse input injection method.  So x11vnc's mouse input injection method has been modified.  To regain the OLD behavior use this option: -always_inject.  Then x11vnc will always force positioning the mouse to the x,y position even if that position has not changed since the previous VNC input event.
The first place this problem was noticed was in gnome terminal: if you pressed and released mouse button 3, a menu was posted and then its first element 'New Terminal Window' was activated.  This was because x11vnc injected the mouse position twice: once on ButtonPress and again on ButtonRelease.  The toolkit interpreted the 2nd one as mouse motion even though the mouse hadn't moved. So now by default x11vnc tries to avoid injecting the 2nd one.
Note that with the new default x11vnc will be oblivious to applications moving the pointer (warping) or the user at the physical display moving it.  So it might, e.g., inject ButtonRelease at the wrong position.  If this (or similar scenarios) causes problems in your environment, specify -always_inject for the old method.
-buttonmap string
String to remap mouse buttons.  Format: IJK-LMN, this maps buttons I -> L, etc., e.g.  -buttonmap 13-31
Button presses can also be mapped to keystrokes: replace a button digit on the right of the dash with :<sym>: or :<sym1>+<sym2>: etc. for multiple keys. For example, if the viewing machine has a mouse-wheel (buttons 4 5) but the x11vnc side does not, these will do scrolls:
-buttonmap 12345-123:Prior::Next:
-buttonmap 12345-123:Up+Up+Up::Down+Down+Down:
See <X11/keysymdef.h> header file for a list of Keysyms, or use the xev(1) program.  Note: mapping of button clicks to Keysyms may not work if -modtweak or -xkb is needed for the Keysym.
If you include a modifier like "Shift_L" the modifier's up/down state is toggled, e.g. to send "The" use :Shift_L+t+Shift_L+h+e: (the 1st one is shift down and the 2nd one is shift up). (note: the initial state of the modifier is ignored and not reset) To include button events use "Button1", ... etc.
-buttonmap currently does not work on MacOSX console or in -rawfb mode.
Workaround: use -buttonmap IJ...-LM...=n to limit the number of mouse buttons to n, e.g. 123-123=3.  This will prevent x11vnc from crashing if the X server reports there are 5 buttons (4/5 scroll wheel), but there are only really 3.
-nodragging
Do not update the display during mouse dragging events (mouse button held down).  Greatly improves response on slow setups, but you lose all visual feedback for drags, text selection, and some menu traversals.  It overrides any -pointer_mode setting.
-ncache n
Client-side caching scheme.  Framebuffer memory n (an integer) times that of the full display is allocated below the actual framebuffer to cache screen contents for rapid retrieval.  So a W x H frambuffer is expanded to a W x (n+1)*H one.  Use 0 to disable.
The n is actually optional, the default is 10.
For this and the other -ncache* options below you can abbreviate "-ncache" with "-nc".  Also, "-nonc" is the same as "-ncache 0"
This is an experimental option, currently implemented in an awkward way in that in the VNC Viewer you can see the pixel cache contents if you scroll down, etc.  So you will have to set things up so you can't see that region.  If this method is successful, the changes required for clients to do this less awkwardly will be investigated.
The SSVNC viewer does a good job at automatically hiding the pixel cache region.  Or use SSVNC's -ycrop option to explicitly hide the region.
Note that this mode consumes a huge amount of memory, both on the x11vnc server side and on the VNC Viewer side.  If n=2 then the amount of RAM used is roughly tripled for both x11vnc and the VNC Viewer.  As a rule of thumb, note that 1280x1024 at depth 24 is about 5MB of pixel data.
For reasonable response when cycling through 4 to 6 large (e.g. web browser) windows a value n of 6 to 12 is recommended. (that's right: ~10X more memory...)
Because of the way window backingstore and saveunders are implemented, n must be even.  It will be incremented by 1 if it is not.