Peter Åstrand | 9fb4e0e | 2004-12-30 10:03:00 +0000 | [diff] [blame^] | 1 | .TH Xvnc 1 "30 December 2004" "TightVNC" "Virtual Network Computing" |
Constantin Kaplinsky | 47ed8d3 | 2004-10-08 09:43:57 +0000 | [diff] [blame] | 2 | .SH NAME |
| 3 | Xvnc \- the X VNC server |
| 4 | .SH SYNOPSIS |
| 5 | .B Xvnc |
| 6 | .RI [ options ] |
| 7 | .RI : display# |
| 8 | .SH DESCRIPTION |
| 9 | .B Xvnc |
| 10 | is the X VNC (Virtual Network Computing) server. It is based on a standard X |
| 11 | server, but it has a "virtual" screen rather than a physical one. X |
| 12 | applications display themselves on it as if it were a normal X display, but |
| 13 | they can only be accessed via a VNC viewer - see \fBvncviewer\fP(1). |
| 14 | |
| 15 | So Xvnc is really two servers in one. To the applications it is an X server, |
| 16 | and to the remote VNC users it is a VNC server. By convention we have arranged |
| 17 | that the VNC server display number will be the same as the X server display |
| 18 | number, which means you can use eg. snoopy:2 to refer to display 2 on machine |
| 19 | "snoopy" in both the X world and the VNC world. |
| 20 | |
| 21 | The best way of starting \fBXvnc\fP is via the \fBvncserver\fP script. This |
| 22 | sets up the environment appropriately and runs some X applications to get you |
| 23 | going. See the manual page for \fBvncserver\fP(1) for more information. |
| 24 | |
| 25 | .SH OPTIONS |
| 26 | .B Xvnc |
| 27 | takes lots of options - running \fBXvnc -help\fP gives a list. Many of these |
| 28 | are standard X server options, which are described in the \fBXserver\fP(1) |
| 29 | manual page. In addition to options which can only be set via the |
| 30 | command-line, there are also "parameters" which can be set both via the |
| 31 | command-line and through the \fBvncconfig\fP(1) program. |
| 32 | |
| 33 | .TP |
| 34 | .B \-geometry \fIwidth\fPx\fIheight\fP |
| 35 | Specify the size of the desktop to be created. Default is 1024x768. |
| 36 | |
| 37 | .TP |
| 38 | .B \-depth \fIdepth\fP |
| 39 | Specify the pixel depth in bits of the desktop to be created. Default is 16, |
| 40 | other possible values are 8, 15, and 24 - anything else is likely to cause |
| 41 | strange behaviour by applications. |
| 42 | |
| 43 | .TP |
| 44 | .B \-pixelformat \fIformat\fP |
| 45 | Specify pixel format for server to use (BGRnnn or RGBnnn). The default for |
| 46 | depth 8 is BGR233 (meaning the most significant two bits represent blue, the |
| 47 | next three green, and the least significant three represent red), the default |
| 48 | for depth 16 is RGB565 and for depth 24 is RGB888. |
| 49 | |
| 50 | .TP |
| 51 | .B \-cc 3 |
| 52 | As an alternative to the default TrueColor visual, this allows you to run an |
| 53 | Xvnc server with a PseudoColor visual (i.e. one which uses a colour map or |
| 54 | palette), which can be useful for running some old X applications which only |
| 55 | work on such a display. Values other than 3 (PseudoColor) and 4 (TrueColor) |
| 56 | for the \-cc option may result in strange behaviour, and PseudoColor desktops |
| 57 | must be 8 bits deep (i.e. \fB-depth 8\fP). |
| 58 | |
| 59 | .TP |
| 60 | .B \-inetd |
| 61 | This significantly changes Xvnc's behaviour so that it can be launched from |
| 62 | inetd. See the section below on usage with inetd. |
| 63 | |
| 64 | .TP |
| 65 | .B \-help |
| 66 | List all the options and parameters |
| 67 | |
| 68 | .SH PARAMETERS |
| 69 | VNC parameters can be set both via the command-line and through the |
| 70 | \fBvncconfig\fP(1) program, and with a VNC-enabled XFree86 server via Options |
| 71 | entries in the XF86Config file. |
| 72 | |
| 73 | Parameters can be turned on with -\fIparam\fP or off with |
| 74 | -\fIparam\fP=0. Parameters which take a value can be specified as |
| 75 | -\fIparam\fP \fIvalue\fP. Other valid forms are \fIparam\fP\fB=\fP\fIvalue\fP |
| 76 | -\fIparam\fP=\fIvalue\fP --\fIparam\fP=\fIvalue\fP. Parameter names are |
| 77 | case-insensitive. |
| 78 | |
| 79 | .TP |
| 80 | .B \-desktop \fIdesktop-name\fP |
| 81 | Each desktop has a name which may be displayed by the viewer. It defaults to |
| 82 | "x11". |
| 83 | |
| 84 | .TP |
| 85 | .B \-rfbport \fIport\fP |
| 86 | Specifies the TCP port on which Xvnc listens for connections from viewers (the |
| 87 | protocol used in VNC is called RFB - "remote framebuffer"). The default is |
| 88 | 5900 plus the display number. |
| 89 | |
| 90 | .TP |
| 91 | .B \-rfbwait \fItime\fP, \-ClientWaitTimeMillis \fItime\fP |
| 92 | |
| 93 | Time in milliseconds to wait for a viewer which is blocking Xvnc. This is |
| 94 | necessary because Xvnc is single-threaded and sometimes blocks until the viewer |
| 95 | has finished sending or receiving a message - note that this does not mean an |
| 96 | update will be aborted after this time. Default is 20000 (20 seconds). |
| 97 | |
| 98 | .TP |
| 99 | .B \-httpd \fIdirectory\fP |
| 100 | Run a mini-HTTP server which serves files from the given directory. Normally |
| 101 | the directory will contain the classes for the Java viewer. In addition, files |
| 102 | with a .vnc extension will have certain substitutions made so that a single |
| 103 | installation of the Java VNC viewer can be served by separate instances of |
| 104 | Xvnc. |
| 105 | |
| 106 | .TP |
| 107 | .B \-httpPort \fIport\fP |
| 108 | Specifies the port on which the mini-HTTP server runs. Default is 5800 plus |
| 109 | the display number. |
| 110 | |
| 111 | .TP |
| 112 | .B \-rfbauth \fIpasswd-file\fP, \-PasswordFile \fIpasswd-file\fP |
| 113 | Specifies the file containing the password used to authenticate viewers. The |
| 114 | file is accessed each time a connection comes in, so it can be changed on the |
| 115 | fly via \fBvncpasswd\fP(1). |
| 116 | |
| 117 | .TP |
| 118 | .B \-deferUpdate \fItime\fP |
| 119 | Xvnc uses a "deferred update" mechanism which enhances performance in many |
| 120 | cases. After any change to the framebuffer, Xvnc waits for this number of |
| 121 | milliseconds (default 40) before sending an update to any waiting clients. This |
| 122 | means that more changes tend to get coalesced together in a single |
| 123 | update. Setting it to 0 results in the same behaviour as earlier versions of |
| 124 | Xvnc, where the first change to the framebuffer causes an immediate update to |
| 125 | any waiting clients. |
| 126 | |
| 127 | .TP |
| 128 | .B \-SendCutText |
| 129 | Send clipboard changes to clients (default is on). Note that you must also run |
| 130 | \fBvncconfig\fP(1) to get the clipboard to work. |
| 131 | |
| 132 | .TP |
| 133 | .B \-AcceptCutText |
| 134 | Accept clipboard updates from clients (default is on). Note that you must also |
| 135 | run \fBvncconfig\fP(1) to get the clipboard to work. |
| 136 | |
| 137 | .TP |
| 138 | .B \-AcceptPointerEvents |
| 139 | Accept pointer press and release events from clients (default is on). |
| 140 | |
| 141 | .TP |
| 142 | .B \-AcceptKeyEvents |
| 143 | Accept key press and release events from clients (default is on). |
| 144 | |
| 145 | .TP |
| 146 | .B \-DisconnectClients |
| 147 | Disconnect existing clients if an incoming connection is non-shared (default is |
| 148 | on). If \fBDisconnectClients\fP is false, then a new non-shared connection will |
| 149 | be refused while there is a client active. When combined with |
| 150 | \fBNeverShared\fP this means only one client is allowed at a time. |
| 151 | |
| 152 | .TP |
| 153 | .B \-NeverShared |
| 154 | Never treat incoming connections as shared, regardless of the client-specified |
| 155 | setting (default is off). |
| 156 | |
| 157 | .TP |
| 158 | .B \-AlwaysShared |
| 159 | Always treat incoming connections as shared, regardless of the client-specified |
| 160 | setting (default is off). |
| 161 | |
| 162 | .TP |
| 163 | .B \-Protocol3.3 |
| 164 | Always use protocol version 3.3 for backwards compatibility with badly-behaved |
| 165 | clients (default is off). |
| 166 | |
| 167 | .TP |
| 168 | .B \-CompareFB |
| 169 | Perform pixel comparison on framebuffer to reduce unnecessary updates (default |
| 170 | is on). |
| 171 | |
| 172 | .TP |
| 173 | .B \-SecurityTypes \fIsec-types\fP |
| 174 | Specify which security schemes to use separated by commas. At present only |
| 175 | "None" and "VncAuth" are supported. The default is "VncAuth" - note that if |
| 176 | you want a server which does not require a password, you must set this |
| 177 | parameter to "None". |
| 178 | |
| 179 | .TP |
| 180 | .B \-IdleTimeout \fIseconds\fP |
| 181 | The number of seconds after which an idle VNC connection will be dropped |
| 182 | (default is 3600 i.e. an hour). |
| 183 | |
| 184 | .TP |
| 185 | .B \-localhost |
| 186 | Only allow connections from the same machine. Useful if you use SSH and want to |
| 187 | stop non-SSH connections from any other hosts. See the guide to using VNC with |
| 188 | SSH on the web site. |
| 189 | |
| 190 | .TP |
| 191 | .B \-log \fIlogname\fP:\fIdest\fP:\fIlevel\fP |
| 192 | Configures the debug log settings. \fIdest\fP can currently be \fBstderr\fP or |
| 193 | \fBstdout\fP, and \fIlevel\fP is between 0 and 100, 100 meaning most verbose |
| 194 | output. \fIlogname\fP is usually \fB*\fP meaning all, but you can target a |
| 195 | specific source file if you know the name of its "LogWriter". Default is |
| 196 | \fB*:stderr:30\fP. |
| 197 | |
| 198 | .SH USAGE WITH INETD |
| 199 | By configuring the \fBinetd\fP(1) service appropriately, Xvnc can be launched |
| 200 | on demand when a connection comes in, rather than having to be started |
| 201 | manually. When given the \fB-inetd\fP option, instead of listening for TCP |
| 202 | connections on a given port it uses its standard input and standard output. |
| 203 | There are two modes controlled by the wait/nowait entry in the inetd.conf file. |
| 204 | |
| 205 | In the nowait mode, Xvnc uses its standard input and output directly as the |
| 206 | connection to a viewer. It never has a listening socket, so cannot accept |
| 207 | further connections from viewers (it can however connect out to listening |
| 208 | viewers by use of the vncconfig program). Further viewer connections to the |
| 209 | same TCP port result in inetd spawning off a new Xvnc to deal with each |
| 210 | connection. When the connection to the viewer dies, the Xvnc and any |
| 211 | associated X clients die. This behaviour is most useful when combined with the |
| 212 | XDMCP options -query and -once. An typical example in inetd.conf might be (all |
| 213 | on one line): |
| 214 | |
| 215 | 5950 stream tcp nowait nobody /usr/local/bin/Xvnc Xvnc -inetd -query |
| 216 | localhost -once securitytypes=none |
| 217 | |
| 218 | In this example a viewer connection to :50 will result in a new Xvnc for that |
| 219 | connection which should display the standard XDM login screen on that machine. |
| 220 | Because the user needs to login via XDM, it is usually OK to accept connections |
| 221 | without a VNC password in this case. |
| 222 | |
| 223 | In the wait mode, when the first connection comes in, inetd gives the listening |
| 224 | socket to Xvnc. This means that for a given TCP port, there is only ever one |
| 225 | Xvnc at a time. Further viewer connections to the same port are accepted by |
| 226 | the same Xvnc in the normal way. Even when the original connection is broken, |
| 227 | the Xvnc will continue to run. If this is used with the XDMCP options -query |
| 228 | and -once, the Xvnc and associated X clients will die when the user logs out of |
| 229 | the X session in the normal way. It is important to use a VNC password in this |
| 230 | case. A typical entry in inetd.conf might be: |
| 231 | |
| 232 | 5951 stream tcp wait james /usr/local/bin/Xvnc Xvnc -inetd -query localhost -once passwordFile=/home/james/.vnc/passwd |
| 233 | |
| 234 | In fact typically, you would have one entry for each user who uses VNC |
| 235 | regularly, each of whom has their own dedicated TCP port which they use. In |
| 236 | this example, when user "james" connects to :51, he enters his VNC password, |
| 237 | then gets the XDM login screen where he logs in in the normal way. However, |
| 238 | unlike the previous example, if he disconnects, the session remains persistent, |
| 239 | and when he reconnects he will get the same session back again. When he logs |
| 240 | out of the X session, the Xvnc will die, but of course a new one will be |
| 241 | created automatically the next time he connects. |
| 242 | |
| 243 | .SH SEE ALSO |
| 244 | .BR vncconfig (1), |
| 245 | .BR vncpasswd (1), |
| 246 | .BR vncserver (1), |
| 247 | .BR vncviewer (1), |
| 248 | .BR Xserver (1), |
| 249 | .BR inetd (1) |
| 250 | .br |
Peter Åstrand | 9fb4e0e | 2004-12-30 10:03:00 +0000 | [diff] [blame^] | 251 | http://www.tightvnc.com |
Constantin Kaplinsky | 47ed8d3 | 2004-10-08 09:43:57 +0000 | [diff] [blame] | 252 | |
| 253 | .SH AUTHOR |
| 254 | Tristan Richardson, RealVNC Ltd. |
| 255 | |
Peter Åstrand | 9fb4e0e | 2004-12-30 10:03:00 +0000 | [diff] [blame^] | 256 | VNC was originally developed by the RealVNC team while at Olivetti |
| 257 | Research Ltd / AT&T Laboratories Cambridge. TightVNC additions was |
| 258 | implemented by Constantin Kaplinsky. Many other people participated in |
| 259 | development, testing and support. |