x11vnc: a VNC server for real X displays
x11vnc allows one to view remotely and interact with real X displays (i.e. a display corresponding to a physical monitor, keyboard, and mouse) with any VNC viewer. In this way it plays the role for Unix/X11 that WinVNC plays for Windows.
It has built-in SSL/TLS encryption and 2048 bit RSA authentication, including VeNCrypt support; UNIX account and password login support; server-side scaling ; single port HTTPS/HTTP+VNC; Zeroconf service advertising; and TightVNC and UltraVNC file-transfer. It has also been extended to work with non-X devices: natively on Mac OS X Aqua/Quartz. webcams and TV tuner capture devices, and embedded Linux systems such as Qtopia Core. Full IPv6 support is provided. More features are described here.
It also provides an encrypted Terminal Services mode ( -create. -svc. or -xdmsvc options) based on Unix usernames and Unix passwords where the user does not need to memorize his VNC display/port number. Normally a virtual X session (Xvfb ) is created for each user, but it also works with X sessions on physical hardware. See the tsvnc terminal services mode of the SSVNC viewer for one way to take advantage of this mode.
I wrote x11vnc back in 2002 because x0rfbserver was basically impossible to build on Solaris and had poor performance. The primary x0rfbserver build problems centered around esoteric C++ toolkits. x11vnc is written in plain C and needs only standard libraries and so should work on nearly all Unixes, even very old ones. I also created enhancements to improve the interactive response, added many features, and etc.
This page including the FAQ contains much information [*] ; solutions to many problems; and interesting applications, but nevertheless please feel free to contact me if you have problems or questions (and if I save you time or expense by giving you some of my time, please consider a PayPal Donation .) Do check the FAQ and this page first; I realize the pages are massive, but you can often use your browser's find-in-page search action using a keyword to find the answer to your problem or question.
SSVNC: An x11vnc side-project provides an Enhanced TightVNC Viewer package (SSVNC) for Unix, Windows, and Mac OS X with automatic SSL and/or SSH tunnelling support, SSL Certificate creation, Saved connection profiles, Zeroconf, VeNCrypt, and built-in Proxy support. Added features for the TightVNC Unix viewer: NewFBSize, ZRLE encoding, Viewer-side Scaling, cursor alphablending, low color modes, and enhanced popup menu; UltraVNC extensions support for: File Transfer, Text Chat, Single Window, Server Input, and 1/n Scaling extensions, and UltraVNC DSM encryption. The SSVNC bundle could be placed on, say, a USB memory stick for SSL/SSH VNC viewing from nearly any networked computer.
Important: If you created any permanent SSL certificates (e.g. via " x11vnc -ssl SAVE. ") on a Debian or Ubuntu system from Sept. 2006 through May 2008, then those keys are likely extremely weak and can be easily cracked. The certificate files should be deleted and recreated on a non-Debian system or an updated one. See http://www.debian.org/security/2008/dsa-1571 for details. The same applies to SSH keys (not used by x11vnc directly, but many people use SSH tunnels for VNC access.)
FAQ moved: The huge FAQ has finally been moved to its own page. If you are trying to follow someone's link to an FAQ once on this page it is now a broken link. Try inserting the string " faq.html ", e.g. Apologies for the inconvenience, unfortunately it is not possible to automatically redirect to the new page since the ' # ' anchor is not sent to the webserver.
VNC (Virtual Network Computing) is a very useful network graphics protocol (applications running on one computer but displaying their windows on another) in the spirit of X, however, unlike X, the viewing-end is very simple and maintains no state. It is a remote framebuffer (RFB) protocol.
For Unix, the traditional VNC implementation includes a "virtual" X11 server Xvnc (usually launched via the vncserver command) that is not associated with a physical display, but provides a "fake" one X11 clients ( xterm. firefox. etc. ) can attach to. A remote user then connects to Xvnc via the VNC client vncviewer from anywhere on the network to view and interact with the whole virtual X11 desktop.
The VNC protocol is in most cases better suited for remote connections with low bandwidth and high latency than is the X11 protocol because it involves far fewer "roundtrips" (an exception is the cached pixmap data on the viewing-end provided by X.) Also, with no state maintained the viewing-end can crash, be rebooted, or relocated and the applications and desktop continue running. Not so with X11.So the standard Xvnc/vncserver program is very useful, I use it for things like:
- Desktop conferencing with other users (e.g. code reviews.)
- Long running apps/tasks I want to be able to view from many places (e.g. from home and work.)
- Motif, GNOME, and similar applications that would yield very poor performance over a high latency link.
However . sometimes one wants to connect to a real X11 display (i.e. one attached to a physical monitor, keyboard, and mouse: a Workstation or a SunRay session) from far away. Maybe you want to close down an application cleanly rather than using kill. or want to work a bit in an already running application, or would like to help a distant colleague solve a problem with their desktop, or would just like to work out on the deck for a while. This is where x11vnc is useful.
How to use x11vnc:
In this basic example let's assume the remote machine with the X display you wish to view is " far-away.east:0 " and the workstation you are presently working at is " sitting-here.west ".
Step 0. Download x11vnc (see below ) and have it available to run on far-away.east (on some linux distros it is as easy as " apt-get install x11vnc ", " emerge x11vnc ", etc.) Similarly, have a VNC viewer (e.g. vncviewer ) ready to run on sitting-here.west. We recommend TightVNC Viewers (see also our SSVNC viewer .)
Step 1. By some means log in to far-away.east and get a command shell running there. You can use ssh. or even rlogin. telnet. or any other method to do this. We do this because the x11vnc process needs to be run on the same machine the X server process is running on (otherwise things would be extremely slow.)
Step 2. In that far-away.east shell (with command prompt " far-away> " in this example) run x11vnc directed at the far-away.east X session display:
You could have also set the environment variable DISPLAY=:0 instead of using " -display :0 ". This step attaches x11vnc to the far-away.east:0 X display (i.e. no viewer clients yet.)
Common Gotcha: To get X11 permissions right, you may also need to set the XAUTHORITY environment variable (or use the -auth option) to point to the correct MIT-MAGIC-COOKIE file (e.g. /home/joe/.Xauthority .) If x11vnc does not have the authority to connect to the display it exits immediately. More on how to fix this below.
If you suspect an X11 permissions problem do this simple test: while sitting at the physical X display open a terminal window (gnome-terminal, xterm, etc.) You should be able to run x11vnc successfully in that terminal without any need for command line options. If that works OK then you know X11 permissions are the only thing preventing it from working when you try to start x11vnc via a remote shell. Then fix this with the tips below.
Note as of Feb/2007 you can also try the -find option instead of " -display. " and see if that finds your display and Xauthority. Note as of Dec/2009 the -findauth and " -auth guess " options may be helpful as well.
(End of Common Gotcha )
When x11vnc starts up there will then be much chatter printed out (use " -q " to quiet it), until it finally says something like: which means all is OK, and we are ready for the final step.
Step 3. At the place where you are sitting ( sitting-here.west in this example) you now want to run a VNC viewer program. There are VNC viewers for Unix, Windows, MacOS, Java-enabled web browsers, and even for PDA's like the Palm Pilot and Cell Phones! You can use any of them to connect to x11vnc (see the above VNC links under "Background:" on how to obtain a viewer for your platform or see this FAQ. For Solaris, vncviewer is available in the Companion CD package SFWvnc .)
In this example we'll use the Unix vncviewer program on sitting-here by typing the following command in a second terminal window:
That should pop up a viewer window on sitting-here.west showing and allowing interaction with the far-away.east:0 X11 desktop. Pretty nifty! When finished, exit the viewer: the remote x11vnc process will shutdown automatically (or you can use the -forever option to have it wait for additional viewer connections.)
Common Gotcha: Nowadays there will likely be a host-level firewall on the x11vnc side that is blocking remote access to the VNC port (e.g. 5900.) You will either have to open up that port (or a range of ports) in your firewall administration tool, or try the SSH tunnelling method below (even still the firewall must allow in the SSH port, 22.)
Shortcut: Of course if you left x11vnc running on far-away.east:0 in a terminal window with the -forever option or as a service. you'd only have to do Step 3 as you moved around. Be sure to use a VNC Password or other measures if you do that.Super Shortcut: Here is a potentially very easy way to get all of it working.
- Have x11vnc (0.9.3 or later) available to run on the remote host (i.e. in $PATH.)
- Download and unpack a SSVNC bundle (1.0.19 or later, e.g. ssvnc_no_windows-1.0.28.tar.gz ) on the Viewer-side machine.
- Start the SSVNC Terminal Services mode GUI. /ssvnc/bin/tsvnc
- Enter your remote username@hostname (e.g. email@example.com ) in the "VNC Terminal Server" entry.
- Click "Connect".
There are a number of things assumed here, first that you are able to SSH into the remote host; i.e. that you have a Unix account there and the SSH server is running. On Unix and MacOS X it is assumed that the ssh client command is available on the local machine (on Windows a plink binary is included in the SSVNC bundle.) Finally, it is assumed that you are already logged into an X session on the remote machine, e.g. your workstation (otherwise, a virtual X server, e.g. Xvfb. will be started for you .)
In some cases the remote SSH server will not run commands with the same $PATH that you normally have in your shell there. In this case click on Options -> Advanced -> X11VNC Options, and type in the location of the x11vnc binary under "Full Path". (End of Super Shortcut )
Desktop Sharing: The above more or less assumed nobody was sitting at the workstation display " far-away.east:0 ". This is often the case: a user wants to access her workstation remotely. Another usage pattern has the user sitting at " far-away.east:0 " and invites one or more other people to view and interact with his desktop. Perhaps the user gives a demo or presentation this way (using the telephone for vocal communication.) A "Remote Help Desk" mode would be similar: a technician connects remotely to the user's desktop to interactively solve a problem the user is having.
For these cases it should be obvious how it is done. The above steps will work, but more easily the user sitting at far-away.east:0 simply starts up x11vnc from a terminal window, after which the guests would start their VNC viewers. For this usage mode the " -connect host1,host2 " option may be of use to automatically connect to the vncviewers in " -listen " mode on the list of hosts.
Tunnelling x11vnc via SSH:
The above example had no security or privacy at all. When logging into remote machines (certainly when going over the internet) it is best to use ssh. or use a VPN (for a VPN, Virtual Private Network, the above example should be pretty safe.)
For x11vnc one can tunnel the VNC protocol through an encrypted ssh channel. It would look something like running the following commands: (you will likely have to provide passwords/passphrases to login from sitting-here into your far-away.east Unix account; we assume you have a login account on far-away.east and it is running the SSH server)
And then in another terminal window on sitting-here run the command: Note: The -encodings option is very important: vncviewer will often default to "raw" encoding if it thinks the connection is to the local machine, and so vncviewer gets tricked this way by the ssh redirection. "raw" encoding will be extremely slow over a networked link, so you need to force the issue with -encodings "copyrect tight. ". Nowadays, not all viewers use the -encodings option, try " -PreferredEncoding=ZRLE " (although the newer viewers seem to autodetect well when to use raw or not.)
Note that " x11vnc -localhost. " limits incoming vncviewer connections to only those from the same machine. This is very natural for ssh tunnelling (the redirection appears to come from the same machine.) Use of a VNC password is also strongly recommended.
Note also the -t we used above (force allocate pseudoterminal), it actually seems to improve interactive typing response via VNC!
You may want to add the -C option to ssh to enable compression. The VNC compression is not perfect, and so this may help a bit. However, over a fast LAN you probably don't want to enable SSH compression because it can slow things down. Try both and see which is faster.
If your username is different on the remote machine use something like: " firstname.lastname@example.org " in the above ssh command line.
Some VNC viewers will do the ssh tunnelling for you automatically, the TightVNC Unix vncviewer does this when the " -via far-away.east " option is supplied to it (this requires x11vnc to be already running on far-away.east or having it started by inetd(8) .) See the 3rd script example below for more info.
SSVNC: You may also want to look at the Enhanced TightVNC Viewer (ssvnc) bundles because they contain scripts and GUIs to automatically set up SSH tunnels (e.g. the GUI, " ssvnc ", does it automatically and so does this command: " ssvnc_cmd -ssh email@example.com:0 ") and can even start up x11vnc as well.
The Terminal Services mode of SSVNC is perhaps the easiest way to use x11vnc. You just need to have x11vnc available in $PATH on the remote side (and can SSH to the host), and then on the viewer-side you type something like: everything else is done automatically for you. Normally this will start a virtual Terminal Services X session (RAM-only), but if you already have a real X session up on the physical hardware it will find that one for you.
Gateways: If the machine you SSH into is not the same machine with the X display you wish to view (e.g. your company provides incoming SSH access to a gateway machine), then you need to change the above to, e.g. " -L 5900:OtherHost:5900 ": Where gateway.east is the internet hostname (or IP) of the gateway machine (SSH server.) 'OtherHost' might be, e.g. freds-pc or 192.168.2.33 (it is OK for these to be private hostnames or private IP addresses, the host in -L is relative to the remote server side.)
Once logged in, you'll need to do a second login ( ssh. rsh. etc.) to the workstation machine 'OtherHost' and then start up x11vnc on it (if it isn't already running.) (The " -connect gateway:59xx " option may be another alternative here with the viewer already in -listen mode.) For an automatic way to use a gateway and have all the network traffic encrypted (including inside the firewall) see Chaining SSH's.
These gateway access modes also can be done automatically for you via the "Proxy/Gateway" setting in SSVNC (including the Chaining SSH's case, "Double Proxy".)
A lot of people have inexpensive devices for home or office that act as a Firewall and Router to the machines inside on a private LAN. One can usually configure the Firewall/Router from inside the LAN via a web browser.
Often having a Firewall/Router sitting between the vncviewer and x11vnc will make it impossible for the viewer to connect to x11vnc.
One thing that can be done is to redirect a port on the Firewall/Router to, say, the SSH port (22) on an inside machine (how to do this depends on your particular Firewall/Router, often the router config URL is http://192.168.100.1 See www.portforward.com for more info.) This way you reach these computers from anywhere
on the Internet and use x11vnc to view X sessions running on them.
Suppose you configured the Firewall/Router to redirect these ports to two internal machines: (where 192.168.1.3 is "jills-pc" and 192.168.1.4 is "freds-pc".) Then the ssh's would look something like: Where far-away.east means the hostname (or IP) that the Router/Firewall is using (for home setups this is usually the IP gotten from your ISP via DHCP, the site http://www.whatismyip.com/ is a convenient way to determine what it is.)
It is a good idea to add some obscurity to accessing your system via SSH by using some high random port (e.g. 12300 in the above example.) If you can't remember it, or are otherwise not worried about port scanners detecting the presence of your SSH server and there is just one internal PC involved you could map 22:
Again, this SSH gateway access can be done automatically for you via the "Proxy/Gateway" setting in SSVNC. And under the "Remote SSH Command" setting you can enter the x11vnc -localhost -display :0.
Host-Level-Firewalls: even with the hardware Firewall/Router problem solved via a port redirection, most PC systems have their own Host level "firewalls" enabled to protect users from themselves. I.e. the system itself blocks all incoming connections. So you will need to see what is needed to configure it to allow in the port (e.g. 22) that you desire. E.g. Yast, Firestarter, iptables(1). etc.
VNC Ports and Firewalls: The above discussion was for configuring the Firewall/Router to let in port 22 (SSH), but the same thing can be done for the default VNC port 5900: (where 192.168.1.3 is "jills-pc" and 192.168.1.4 is "freds-pc".) This could be used for normal, unencrypted connections and also for SSL encrypted ones.
The VNC displays to enter in the VNC viewer would be, say, " far-away.east:0 " to reach jills-pc and " far-away.east:1 " to reach freds-pc. We assume above that x11vnc is using port 5900 (and any Host-Level-firewalls on jills-pc has been configured to let that port in.) Use the " -rfbport " option to tell which port x11vnc should listen on.
For a home system one likely does not have a hostname and would have to use the IP address, say, " 126.96.36.199:0 ". E.g. You may want to choose a more obscure port on the router side, e.g. 5944, to avoid a lot of port scans finding your VNC server. For 5944 you would tell the viewer to use:
The IP address would need to be communicated to the person running the VNC Viewer. The site http://www.whatismyip.com/ can help here.
Scripts to automate ssh tunneling: As discussed below, there may be some problems with port 5900 being available. If that happens, the above port and display numbers may change a bit (e.g. -> 5901 and :1). However, if you "know" port 5900 will be free on the local and remote machines, you can easily automate the above two steps by using the x11vnc option -bg (forks into background after connection to the display is set up) or using the -f option of ssh. Some example scripts are shown below. Feel free to try the ssh -C to enable its compression and see if that speeds things up noticeably.
#1. A simple example script, assuming no problems with port 5900 being taken on the local or remote sides, looks like: See also rx11vnc.pl below.
#2. Another method is to start the VNC viewer in listen mode " vncviewer -listen " and have x11vnc initiate a reverse connection using the -connect option: Note the use of the ssh option " -R " instead of " -L " to set up a remote port redirection.
#3. A third way is specific to the TightVNC vncviewer special option -via for gateways. The only tricky part is we need to start up x11vnc and give it some time (5 seconds in this example) to start listening for connections (so we cannot use the TightVNC default setting for VNC_VIA_CMD ): Of course if you already have the x11vnc running waiting for connections (or have it started out of inetd(8) ), you can simply use the TightVNC " vncviewer -via gateway host:port " in its default mode to provide secure ssh tunnelling.
VNC password file: Also note in the #1. example script that the option " -rfbauth .vnc/passwd " provides additional protection by requiring a VNC password for every VNC viewer that connects. The vncpasswd or storepasswd programs, or the x11vnc -storepasswd option can be used to create the password file. x11vnc also has the slightly less secure -passwdfile and " -passwd XXXXX " options to specify passwords.
Very Important: It is up to YOU to tell x11vnc to use password protection ( -rfbauth or -passwdfile ), it will NOT do it for you automatically or force you to (use -usepw if you want to be forced to.) The same goes for encrypting the channel between the viewer and x11vnc. it is up to you to use ssh. stunnel. -ssl mode, a VPN, etc. (use the Enhanced TightVNC Viewer (SSVNC) GUI if you want to be forced to use SSL or SSH.) For additional safety, also look into the -allow and -localhost options and building x11vnc with tcp_wrappers support to limit host access.
Tunnelling x11vnc via SSL/TLS:
One can also encrypt the VNC traffic using an SSL/TLS tunnel such as stunnel.mirt.net (also stunnel.org ) or using the built-in (Mar/2006) -ssl openssl mode. A SSL-enabled Java applet VNC Viewer is also provided in the x11vnc package (and https can be used to download it.)
Although not as ubiquitous as ssh. SSL tunnelling still provides a useful alternative. See this FAQ on -ssl and -stunnel modes for details and examples.
The Enhanced TightVNC Viewer (SSVNC) bundles contain some convenient utilities to automatically set up an SSL tunnel from the viewer-side (i.e. to connect to " x11vnc -ssl. ".) And many other enhancements too.
x11vnc is a contributed program to the LibVNCServer project at SourceForge.net. I use libvncserver for all of the VNC aspects; I couldn't have done without it. The full source code may be found and downloaded (either file-release tarball or GIT tree) from the above link. As of Sep 2011, the x11vnc-0.9.13.tar.gz source package is released (recommended download ). The x11vnc 0.9.13 release notes.
The x11vnc package is the subset of the libvncserver package needed to build the x11vnc program. Also, you can get a copy of my latest, bleeding edge x11vnc-0.9.14-dev.tar.gz tarball to build the most up to date one.
Precompiled Binaries/Packages: See the FAQ below for information about where you might obtain a precompiled x11vnc binary from 3rd parties and some ones I create.
More tools . Here is a ssh/rsh wrapper script rx11vnc that attempts to automatically do the above Steps 1-3 for you (provided you have ssh/rsh login permission on the machine x11vnc is to be run on.) The above example would be: " rx11vnc far-away.east:0 " typed into a shell on sitting-here.west. Also included is an experimental script rx11vnc.pl that attempts to tunnel the vnc traffic through an ssh port redirection (and does not assume port 5900 is free.) Have a look at them to see what they do and customize as needed:
- rx11vnc wrapper script
- rx11vnc.pl wrapper script to tunnel traffic thru ssh
Make sure you have all the needed build/compile/development packages installed (e.g. Linux distributions foolishly don't install them by default.) See this build FAQ for more details.
If your OS has libjpeg.so and libz.so in standard locations you can build as follows (example given for the 0.9.13 release of x11vnc. replace with the version you downloaded): Or do make install. it will probably install to /usr/local/bin (run ./configure --help for information on customizing your configuration, e.g. --prefix=/my/place .) You can now run it via typing " x11vnc ", " x11vnc -help | more ", " x11vnc -forever -shared -display :0 ", etc.
Note: Currently gcc is recommended to build libvncserver. In some cases it will build with non-gcc compilers, but the resulting binary sometimes fails to run properly. For Solaris pre-built gcc binaries are at http://www.sunfreeware.com/. Some Solaris pre-built x11vnc binaries are here.
However, one user reports it does work fine when built with Sun Studio 10, so YMMV. In fact, here is a little build script to do this on Solaris 10: In general you can use the " make -e " trick if you don't like libvncserver's choice of AM_CFLAGS. See the build scripts below for more ideas. Scripts similar to the above have been shown to work with vendor C compilers on HP-UX (ccom: HP92453-01) and Tru64 (Compaq C V6.5-011.)
Building on Solaris, FreeBSD, etc: Depending on your version of Solaris or other Unix OS the jpeg and/or zlib libraries may be in non-standard places (e.g. /usr/local. /usr/sfw. /opt/sfw. etc.)
Note: If configure cannot find these two libraries then TightVNC and ZRLE encoding support will be disabled, and you don't want that. The TightVNC encoding gives very good compression and performance, it even makes a noticeable difference over a fast LAN.
Shortcuts: On Solaris 10 you can pick up almost everything just by insuring that your PATH has /usr/sfw/bin (for gcc) and /usr/ccs/bin (for other build tools), e.g. (The only thing this misses is /usr/X11/lib/libXrandr.so.2. which is for the little used -xrandr option, see the script below to pick it up as well.)
libjpeg is included in Solaris 9 and later ( /usr/sfw/include and /usr/sfw/lib ), and zlib in Solaris 8 and later ( /usr/include and /usr/lib .) So on Solaris 9 you can pick up everything with something like this: assuming your gcc is in /usr/local/bin and x11vnc 0.7.1 or later. These are getting pretty long, see those assignments split up in the build script below.
If your system does not have these libraries at all you can get the source for the libraries to build them: libjpeg is available at ftp://ftp.uu.net/graphics/jpeg/ and zlib at http://www.gzip.org/zlib/. See also http://www.sunfreeware.com/ for Solaris binary packages of these libraries as well as for gcc. Normally they will install into /usr/local but you can install them anywhere with the --prefix=/path/to/anywhere. etc.
Here is a build script that indicates one way to pass the library locations information to the libvncserver configuration via the CPPFLAGS and LDFLAGS environment variables. Then do make install or copy the x11vnc binary to your desired destination.
BTW, To run a shell script, just cut-and-paste the above into a file, say " myscript ", then modify the " /path/to/. " items to correspond to your system/environment, and then type: " sh myscript " to run it.
Note that on Solaris make is /usr/ccs/bin/make. so that is why the above puts /usr/ccs/bin in PATH. Other important build utilities are there too: ld. ar. etc. Also, it is probably a bad idea to have /usr/ucb in your PATH while building.
Starting with the 0.7.1 x11vnc release the " configure --with-jpeg=DIR --with-zlib=DIR " options are handy if you want to avoid making a script.
If you need to link OpenSSL libssl.a on Solaris see this method.
If you need to build on Solaris 2.5.1 or earlier or other older Unix OS's, see this workaround FAQ.
Building on FreeBSD, OpenBSD. The jpeg libraries seem to be in /usr/local or /usr/pkg on these OS's. You won't need the openwin stuff in the above script (but you may need /usr/X11R6/. ) Also starting with the 0.7.1 x11vnc release, this usually works:
Building on HP-UX: For jpeg and zlib you will need to do the same sort of thing as described above for Solaris. You set CPPFLAGS and LDFLAGS to find them (see below for an example.) You do not need to do any of the above /usr/openwin stuff. Also, HP-UX does not seem to support -R. so get rid of the -R items in LDFLAGS. Because of this, at runtime you may need to set LD_LIBRARY_PATH or SHLIB_PATH to indicate the directory paths so the libraries can be found. It is a good idea to have static archives, e.g. libz.a and libjpeg.a for the nonstandard libraries so that they get bolted into the x11vnc binary (and so won't get "lost".)
Here is what we recently did to build x11vnc 0.7.2 on HP-UX 11.11 Where we had static archives (libjpeg.a, libz.a) only and header files in the $HOME/hpux/. directories as discussed for the build script.
On HP-UX 11.23 and 11.31 we have had problems compiling with gcc. " /usr/include/rpc/auth.h:87: error: field 'syncaddr' has incomplete type ". As a workaround for x11vnc 0.9.4 and later set your CPPFLAGS to include: This disables a very rare usage mode for -unixpw_nis by not trying getspnam(3).
Using HP-UX's C compiler on 11.23 and 11.31 we have some severe compiler errors that have not been worked around yet. If you need to do this, contact me and I will give you a drastic recipe that will produce a working binary.
Building on AIX: AIX: one user had to add the "X11.adt" package to AIX 4.3.3 and 5.2 to get build header files like XShm.h. etc. You may also want to make sure that /usr/lpp/X11/include. etc is being picked up by the configure and make.
For a recent build on AIX 5.3 we needed to add these CFLAGS to be able to build with gcc: we also built our own libjpeg and libz using -maix64.
BTW, one way to run an Xvfb-like virtual X server for testing on AIX is something like " /usr/bin/X11/X -force -vfb -ac :1 ".
Building on Mac OS X: There is now native Mac OS X support for x11vnc by using the raw framebuffer feature. This mode does not use or need X11 at all. To build you may need to disable X11: However, if your system has the Mac OS X build package for X11 apps you will not need to supply the " --without-x " option (in this case the resulting x11vnc would be able to export both the native Mac OS X display and windows displayed in the XDarwin X server.) Be sure to include the ./configure option to find libjpeg on your system.
OpenSSL: Starting with version 0.8.3 x11vnc can now be built with SSL/TLS support. For this to be enabled the libssl.so library needs to be available at build time. So you may need to have additional CPPFLAGS and LDFLAGS items if your libssl.so is in a non-standard place. As of x11vnc 0.9.4 there is also the --with-ssl=DIR configure option.
On Solaris using static archives libssl.a and libcrypto.a instead of .so shared libraries (e.g. from www.sunfreeware.com), we found we needed to also set LDFLAGS as follows to get the configure to work:
I don't have any formal beta-testers for the releases of x11vnc. so I'd appreciate any additional testing very much.
Thanks to those who suggested features and helped beta test x11vnc 0.9.13 released in Sep 2011!
Please help test and debug the 0.9.14 version for release sometime in Winter 2011.
The version 0.9.14 beta tarball is kept here: x11vnc-0.9.14-dev.tar.gz
To aid testing of the built-in SSL/TLS support for x11vnc. a number of VNC Viewer packages for Unix, Mac OS X, and Windows have been created that provide SSL Support for the TightVNC Viewer (this is done by wrapper scripts and a GUI that starts STUNNEL .) It should be pretty convenient for automatic SSL and SSH connections. It is described in detail at and can be downloaded from the Enhanced TightVNC Viewer (SSVNC) page. The SSVNC Unix viewer also supports x11vnc's symmetric key encryption ciphers (see the 'UltraVNC DSM Encryption Plugin' settings panel.)Here are some features that will appear in the 0.9.14 release:
- Apple removed OpenGL screen capture in Mac OS X Lion. We plan to find a workaround in this x11vnc release. As of Nov/2011 we believe we have: please try out the 'MACOSX_10.6_OR_LATER' test binaries in our download area. If it works for you on macosx Lion, please let me know (I don't have access to a macosx lion machine.) Also: one can set ' -env X11VNC_DEBUG_OPENGL=1 ' to get some debugging info printed out for OpenGL on macosx.
- One can set ' -env X11VNC_NO_IDENT_USERNAME=1 ' to have x11vnc skip trying to use the identd service (port 113) to get a name for the user at the vncviewer. This can speed up connections, especially when starting many viewer connections at once (e.g. classroom broadcast.)
- There is a bug in the Xorg server introduced in 2009 for multiscreen displays that make it so x11vnc cannot send pointer motion events properly via XTestFakeMotionEvent to a screen that does not have the current focus. x11vnc now tries to automatically work around this bug by detecting multiple screens and enabling -xwarppointer .
- Some additional checks are taken in -inetd mode to see if the connection is over IPV6.
- -env X11VNC_ALLOW_FULLMATCH=1 now works for localhost including IPV6 '::1'
- One can set -env X11VNC_DEBUG_SEND_CLIENT_INFO=1 to debug the client info communication channel with the gui. A bug has been fixed for this channel for many simultaneous viewers.