VNCviewer for X (3.3.2r3 and earlier)
Note: this page documents the Xlib-based viewer in the 3.3.2r3 and earlier
releases. For the current release, see the documentation for the new Xt-based viewer.
Run it and give the display as an argument:
where 'snoopy' is the name of the machine, and '2' is the display number
of the VNC server on that machine. The -h argument will show you
the other options. The important ones are as follows:
When you make a connection to a VNC server, all other existing connections
are normally closed. This option requests that they be left open,
allowing you to share the desktop with someone already using it.
This allows you to specify the X display on which the VNCviewer window
If you are on a filesystem which gives you access to the password file
used by the server, you can specify it here to avoid typing it in.
Specifies that no keyboard or mouse events should be sent to the server.
Useful if you want to view a desktop without interfering; often needs to
be combined with -shared.
Standard X position and sizing specification.
This tells the VNC server to send pixels which are only 8 bits deep.
If your server desktop is deeper than this then it will translate the
pixels before sending them. Less data will generally be sent over then
network, which can be a big advantage on slow links, but the server
may have to work a bit harder, and you may get some colour mismatches.
This is the 8-bit true colour pixel format used by the java client,
with the most significant two bits of each byte representing the blue
component, the next three bits representing green and the least
significant three representing red, hence 'bgr233'.
-raw, -copyrect, -rre, -corre, -hextile, -nocopyrect, -norre, -nocorre,
These options affect which encodings vncviewer tells the VNC server it
can cope with. Normally it requests CopyRect, Hextile, CoRRE and
RRE in that order. The options alter this behaviour in the obvious
way, e.g. specifying just -raw means Raw will be requested before any of
the others, specifying -norre means don't request RRE, etc.
This is only useful on a (real) X server which supports multiple depths.
On such a display vncviewer will try to find a Visual of the given depth.
If successful this means that the appropriate pixel format will be requested
from the VNC server. You cannot use this to force a particular depth
from the VNC server. The only option which does this is -bgr233.
vncviewer will try to find an X visual of the TrueColor class.
vncviewer will try to find a PseudoColor visual and use its own Colormap.
This tells vncviewer not to request incremental framebuffer updates more
often than the given period in milliseconds. If you have a very fast
client and server, you can use this option to limit the rate of updates
- this can result in using less network bandwidth.
Normally the viewer window will be the same size as the desktop you're
connecting to, plus any decorations added by your local window manager.
If your local screen is too small to display this then it will make the
window as big as it can while still allowing room for decorations, and
display scrollbars. This option allows you to specify how big your
window manager's decorations are, so that it can make this decision correctly.
In particular, some people run without a local window manager, and specifying
-wmdecoration 0x0 will then allow a completely full-screen window.
This is useful for checking exactly which parts of the screen are being
updated. For each update rectangle vncviewer puts up a black rectangle
for the given time before putting up the pixel data. This only highlights
pixel data sent using the raw encoding.
This works as with -rawdelay above, but highlights the areas copied using
the copyrect encoding.
This prints out all the data received from the VNC server in both hex and
This is used for AT&T's internal version of VNC. It causes vncviewer
to listen on port 5500+<display-number> for reverse connections from
a VNC server. See http://www.cl.cam.ac.uk/Research/DTG/attarchive/vnc/internalversion.html