Xvnc - the X VNC server
is the X VNC (Virtual Network Computing) server. It is based on a standard X
server, but it has a "virtual" screen rather than a physical one. X
applications display themselves on it as if it were a normal X display, but
they can only be accessed via a VNC viewer - see vncviewer(1).
So Xvnc is really two servers in one. To the applications it is
an X server, and to the remote VNC users it is a VNC server. By
convention we have arranged that the VNC server display number will be
the same as the X server display number, which means you can use
eg. snoopy:2 to refer to display 2 on machine "snoopy" in both the X
world and the VNC world.
The best way of starting
is via the
command. This sets up the environment appropriately and runs some
X applications to get you going. See the manual page for
for more information.
takes lots of options - running Xvnc -help gives a list. Many of these
are standard X server options, which are described in the Xserver(1)
manual page. In addition to options which can only be set via the
command-line, there are also "parameters" which can be set both via the
command-line and through the vncconfig(1) program.
- -geometry widthxheight
Specify the size of the desktop to be created. Default is 1024x768.
- -depth depth
Specify the pixel depth in bits of the desktop to be created. Default is 16,
other possible values are 8, 15, and 24 - anything else is likely to cause
strange behaviour by applications.
- -pixelformat format
Specify pixel format for server to use (BGRnnn or RGBnnn). The default for
depth 8 is BGR233 (meaning the most significant two bits represent blue, the
next three green, and the least significant three represent red), the default
for depth 16 is RGB565 and for depth 24 is RGB888.
- -cc 3
As an alternative to the default TrueColor visual, this allows you to run an
Xvnc server with a PseudoColor visual (i.e. one which uses a colour map or
palette), which can be useful for running some old X applications which only
work on such a display. Values other than 3 (PseudoColor) and 4 (TrueColor)
for the -cc option may result in strange behaviour, and PseudoColor desktops
must be 8 bits deep (i.e. -depth 8).
This significantly changes Xvnc's behaviour so that it can be launched from
inetd. See the section below on usage with inetd.
List all the options and parameters
VNC parameters can be set both via the command-line and through the
vncconfig(1) program, and with a VNC-enabled XFree86 server via Options
entries in the XF86Config file.
Parameters can be turned on with -param or off with
-param=0. Parameters which take a value can be specified as
-param value. Other valid forms are param=value,
-param=value and --param=value. Parameter names are
For a full list of the parameters and a brief description of what they
option. Most of these parameters will never need to be changed from
their default values. The following list describes the most common
parameters and what they do.
- -desktop desktop-name
Each desktop has a name which may be displayed by the viewer. It defaults to
- -rfbport port
Specifies the TCP port on which Xvnc listens for connections from viewers (the
protocol used in VNC is called RFB - "remote framebuffer"). The default is
5900 plus the display number.
- -rfbwait time, -ClientWaitTimeMillis time
Time in milliseconds to wait for a viewer which is blocking Xvnc. This is
necessary because Xvnc is single-threaded and sometimes blocks until the viewer
has finished sending or receiving a message - note that this does not mean an
update will be aborted after this time. Default is 20000 (20 seconds).
- -httpd directory
Run a mini-HTTP server which serves files from the given directory.
Normally the directory will contain the classes for the Java viewer.
In addition, files with a .vnc extension will have certain
substitutions made so that a single installation of the Java VNC
viewer can be served by separate instances of Xvnc. If this parameter
is set to "<inline>", then the Java viewer and associated files are
served directly from the Xvnc executable. Default is empty, meaning
that the Java viewer is not served.
- -httpPort port
Specifies the port on which the mini-HTTP server runs. Default is 5800 plus
the display number.
- -rfbauth passwd-file
Specifies the file containing the password used to authenticate
viewers if VNC authentication is in use. See also the
UserPasswdVerifier and PasswordFile parameters.
- -deferUpdate time
Xvnc uses a "deferred update" mechanism which enhances performance in many
cases. After any change to the framebuffer, Xvnc waits for this number of
milliseconds (default 40) before sending an update to any waiting clients. This
means that more changes tend to get coalesced together in a single
update. Setting it to 0 results in the same behaviour as earlier versions of
Xvnc, where the first change to the framebuffer causes an immediate update to
any waiting clients.
Send clipboard changes to clients (default is on). Note that you must also run
vncconfig(1) to get the clipboard to work.
Accept clipboard updates from clients (default is on). Note that you must also
run vncconfig(1) to get the clipboard to work.
Accept pointer press and release events from clients (default is on).
Accept key press and release events from clients (default is on).
Enable file sharing with clients (default is on).
Disconnect existing clients if an incoming connection is non-shared (default is
on). If DisconnectClients is false, then a new non-shared connection will
be refused while there is a client active. When combined with
NeverShared this means only one client is allowed at a time.
Never treat incoming connections as shared, regardless of the client-specified
setting (default is off).
Always treat incoming connections as shared, regardless of the client-specified
setting (default is off).
Always use protocol version 3.3 for backwards compatibility with badly-behaved
clients (default is off).
Perform pixel comparison on framebuffer to reduce unnecessary updates (default
- -SecurityTypes sec-types
Specify which security schemes to use separated by commas. At
present, "None", "VncAuth", "RA2" and "RA2ne" are supported. The
default is "RA2". See also
- -ReverseSecurityTypes sec-types
Specify which security schemes to use for reverse (server-initiated)
connections, separated by commas. At present, "None" and "RA2" are
supported. The default is "RA2".
- -IdleTimeout seconds
The number of seconds after which an idle VNC connection will be dropped
(default is 3600 i.e. an hour).
Prompts the user of the desktop to explicitly accept or reject incoming
connections. This is most useful when using the vnc.so module or
x0vncserver(1) program to access an existing X desktop via VNC.
For Xvnc(1) processes, this option can be combined with
settings or VNC Extended Authentication to allow certain users to
connect without the desktop user being prompted.
The vncconfig(1) program must be running on the desktop in order
for QueryConnect to be supported by the vnc.so(1) module or
Xvnc(1) program. If vncconfig(1) is not running then any
connection that should be queried is instead rejected. The
x0vncserver(1) program does not require vncconfig(1) to be
- -QueryConnectTimeout seconds
Specify the number of seconds for which the query connection dialog is
displayed. The default is 10 seconds.
- -QueryTimeoutRights rights
Specify the default action if the query connect dialog times out. The
default is that no rights should be granted (i.e. the connection is
refused). Setting this to an access string of the form described in the
AllowedUsers and AllowedGroups
parameters means that the connection will be accepted with the
Only allow connections from the same machine. Useful if you use SSH and want to
stop non-SSH connections from any other hosts. See the guide to using VNC with
SSH on the web site.
- -log logname:dest:level
Configures the debug log settings. dest can currently be
stderr or stdout, both of which send log output to
(but see below for the log file location when running with inetd).
Level is between 0 and 100,
100 meaning most verbose output. logname is usually *
meaning all, but you can target a specific source file if you know the
name of its "LogWriter". Default is *:stderr:30.
- -RemapKeys mapping
Sets up a keyboard mapping.
is a comma-separated string of character mappings, each of the form
is a hexadecimal keysym. For example, to exchange the " and @ symbols you would specify the following:
- -AllowedUsers users and -AllowedGroups groups
Which users/groups are allowed to connect, and what level of access they have. Both
users and groups
are comma-separated lists of access control specifications, each of the form:
is an optional string consisting of the following characters
v - User can view desktop.
p - User can send mouse input.
k - User can send keyboard input.
c - User can exchange clipboard contents.
q - User can bypass the QueryConnect prompt.
d - Default access (equivalent to vpkc).
f - Full access (equivalent to dq).
is not specified, it defaults to d. For example, to specify that the
superuser has full access, and that members of the group "staff" have
default access, the following options should be used:
If not specified explicitly in the AllowedUsers parameter, the desktop
owner is granted default access. To amend the above example to grant
the desktop owner full access, the following could be used in a
The permissions specified by the
AllowedUsers and AllowedGroups
are considered only if the corresponding global settings,
SendCutText, AcceptCutText, AcceptPointerEvents, AcceptKeyEvents, ShareFiles and QueryConnect
- -PasswordFile passwd-file, -AdminPasswordFile passwd-file, -ViewOnlyPasswordFile passwd-file and -InputOnlyPasswordFile passwd-file
The files from which the passwords for the "user" (or no user name),
"admin", "viewonly" and "inputonly" users should be read. The files
are accessed each time a connection comes in, so can be changed on the
fly via vncpasswd(1). These usernames and passwords are only
used if UserPasswdVerifier is set to "VncAuth". If any of these parameters is not set, then the corresponding user is disabled.
- -UserPasswdVerifier verifier
determines which method to use to verify a user's password. The
currently supported values are "None" (do not require a password to
access the server), "VncAuth" (use the passwords defined by the
PasswordFile, InputOnlyPasswordFile, ViewOnlyPasswordFile and AdminPasswordFile
parameters) or "UnixAuth" (use the standard UNIX login password in
conjunction with the
AllowedUsers and AllowedGroups
Allow users to connect using the guest user name and password (see
below). This option is usually set using the vncconfig
program. The default is off.
- -GuestUserName name
The user name for the guest login, if enabled. The default is "guest".
- -GuestAccess access
The level of access to grant the "guest" user specified as an access
control string as described under the AllowedUsers
parameter. The default is 0, meaning no access, even if the
EnableGuestLogin parameter is set.
- -GuestPasswordFile passwd-file
The file from which the password for the "guest" user should be
read. Like the VNC authentication password files, this file is
accessed each time a connection comes in, so can be changed on the fly
via vncpasswd(1). Unlike the other password parameters, if this
parameter is not set, then the "guest" user does not require a
Restrict vncconfig to be useable only by the owner of this
USAGE WITH INETD
By configuring the inetd(1) service appropriately, Xvnc can be launched
on demand when a connection comes in, rather than having to be started
manually. When given the -inetd option, instead of listening for TCP
connections on a given port it uses its standard input and standard output.
There are two modes controlled by the wait/nowait entry in the inetd.conf file.
Note that wait mode is only supported by inetd on some platforms.
In the nowait mode, Xvnc uses its standard input and output directly as the
connection to a viewer. It never has a listening socket, so cannot accept
further connections from viewers (it can however connect out to listening
viewers by use of the vncconfig program). Further viewer connections to the
same TCP port result in inetd spawning off a new Xvnc to deal with each
connection. When the connection to the viewer dies, the Xvnc and any
associated X clients die. This behaviour is most useful when combined with the
XDMCP options -query and -once. An typical example in inetd.conf might be (all
on one line):
5950 stream tcp nowait nobody /usr/local/bin/Xvnc Xvnc -inetd -query
localhost -once securitytypes=none
In this example a viewer connection to :50 will result in a new Xvnc for that
connection which should display the standard XDM login screen on that machine.
Because the user needs to login via XDM, it is usually OK to accept connections
without a VNC password in this case.
Note that on Solaris 2.6, 7 and 8 there is a bug in the dtlogin program which
provides the login window via XDMCP. To work around this give the option
"-nolisten named" to Xvnc as well. Also on Solaris because of a limitation in
the number of command-line arguments supported by inetd you will probably need
to write a wrapper script to launch Xvnc.
In the wait mode, when the first connection comes in, inetd gives the listening
socket to Xvnc. This means that for a given TCP port, there is only ever one
Xvnc at a time. Further viewer connections to the same port are accepted by
the same Xvnc in the normal way. Even when the original connection is broken,
the Xvnc will continue to run. If this is used with the XDMCP options -query
and -once, the Xvnc and associated X clients will die when the user logs out of
the X session in the normal way. It is important to use a VNC password in this
case. A typical entry in inetd.conf might be:
5951 stream tcp wait james /usr/local/bin/Xvnc Xvnc -inetd -query localhost -once passwordFile=/home/james/.vnc/passwd
In fact typically, you would have one entry for each user who uses VNC
regularly, each of whom has their own dedicated TCP port which they use. In
this example, when user "james" connects to :51, he enters his VNC password,
then gets the XDM login screen where he logs in in the normal way. However,
unlike the previous example, if he disconnects, the session remains persistent,
and when he reconnects he will get the same session back again. When he logs
out of the X session, the Xvnc will die, but of course a new one will be
created automatically the next time he connects.