| Linux-related notes
Shell, admin, and both:
- 1 linux tl;dr
- 2 Windows tl;dr
- 3 VNC implementations
- 4 More technical notes
- 5 Semi-sorted
- 6 Problems
VirtualGL and stuff
Decide between TurboVNC and TigerVNC. The below assumes TurboVNC.
- Have 3D drivers (and its development package) installed
- Install VirtualGL
- e.g. package from https://sourceforge.net/projects/virtualgl/files/
- Install TurboVNC / TigerVNC
- e.g. package from https://sourceforge.net/projects/turbovnc/files/
Client-side has no particular requirements, though TurboVNC / TigerVNC may be somewhat faster.
| These are primarily notes|
It won't be complete in any sense.
It exists to contain fragments of useful information.
(Note that practical details vary a bit with platform. E.g. on windows you can only directly share a logged-in sessions, while on X you can host many completely separate sessions)
Newer ones first (roughly)
- TigerVNC - branch of TightVNC(/TurboVNC)
- windows, linux, osx
- In part meant to update TurboVNC, and provides a few modern features (RealVNC-like) and some TurboVNC updates, though for performance TurboVNC is generally preferable(verify).
- TurboVNC - branch of TightVNC
- windows, linux, osx
- focuses on speed. By itself a little cleverer, so does better than tight at video and 3D content
- the optional use of VirualGL gives more performance for 3D
- the research / implementation details behind some of its design choices have been adopted by others, including TigerVNC, libvncserver, and recently UltraVNC
- on Linux there is a server (verify) (see also VirtualGL instructions. Use of VirtualGL is optional)
- on windows, the server end is recommended to be a post-2015 UltraVNC (verify)
- TightVNC: server and client, free
- windows and *nix
- Otherwise fairly minimal (e.g. no GLX support in the server(verify))
- Tight protocol was a good choice for a decent while (roughly until tiger/turbo)
- Not actively developed
- UltraVNC: Similar to RealVNC, but free.
- supports e.g. tight
- RealVNC: server and client, free and paid-for versions,
- has extra features like file transfer. Seems targeted at helpdesks.
- "WinVNC" is a bit vague, in that more than one thing has been referred to as such (verify)
- about various turbos:
- libjpeg-turbo is a SIMD-optimized variant of libjpeg (mostly drop-in)
- TurboJPEG is a higher-level API which can be backed by libjpeg-turbo, or similar such optimizations
- (developed for VirtualGL, TurboVNC)
- TurboVNC's speed comes in part from using TurboJPEG, partly from spending less (CPU)time deciding what to send how
- (itself in part because sending with jpeg is a bit cheaper via turbojpeg)
- about VirtualGL
- intercepts rendered GL results in-process, works out as indirect but hardware-accelerated rendering
- (where available; can also be built against mesa to be able to use 3D on GPU-less servers)
- which makes it pretty efficient to view 3D apps results (and video) rendered elsewhere on a fairly thin client (pretty impressive on LAN, by previous standards)
- intercepts: meaning does not require apps to be built against it, you just have to start it in a specific way (vglrun)
- can do its own transport, e.g. displaying the results of one X (3D) server in another (2D)
- perhaps more frequently seen with TurboVNC (or similar). This requires more CPU but provides other features, e.g. tending to be more reactive on high-latency, low-bandwidth connections.
- associated but not tied to TurboVNC
- some special cases where one or more of the more modern details apply, e.g. in virtualbox (verify)
- Other/specialzed: See e.g. 
More technical notes
A VNC client connects to an IP and either a display-number-dependent port.
The port VNC serves on is usually 5900+displaynumber (...on X. On windows that's usually 1)
(Port 5800+displaynumber, if you see it, is for serving the java client, if applicable)
VNC, X and window managers
Most VNC servers are X servers so are a session upon themselves. A few leech onto existing sessions somehow.
When they are independent, you often start one as and for a specific user. (In some setups it makes sense to run a session manager so that anyone can connect and the authentication is handled by it)
One of the few differences with a regular X server is that it has its own configuration file that lists what it should do when started.
For example, the TightVNC server places this in ~/.vnc/xstartup, and might e.g. contain:
xrdb $HOME/.Xresources xsetroot -solid grey xterm -geometry 80x24+10+10 -ls & twm &
- xrdb sets a number of properties on the root window that is created (I'm not sure how necessary this actually is)
- xsetroot sets the background (the 'root window') to a solid color instead of the default pattern so that it compresses better
- xterm -ls gives you a login shell in an xterm to start working with. (this shell is a child of the vnc server process, meaning it will outlive you killing the window manager, unlike shells you started from the window manager)
- twm is a very simple window manager. You may like blackbox or xfce4 or others. (Or even something like KDE if you turn the fancy graphics all the way down.)
On xfce and Tab: http://blog.zerosum42.com/2011/10/tech-fixing-tab-key-in-vnc.html
Starting a vnc server:
This is a perl script that will assume some defaults and start a vncserver on the first available X display. The local display, if applicable, usually takes up only :0, so this starts at :1. When more than one local / VNC display is used, you may want to specify a specific number to avoid confusion.
You can use more options:
vncserver :2 -geometry 900x700 -depth 16
Geometry controls the desktop size. Can be anything, I prefer something that makes the client window not cover everything.
Depth 16 will be a little easier on the network than 24, and a little uglier.
Stopping a vnc server:
vncserver -kill :2
You should save things, of course, and possibly log out of your windowing environment to let it save its settings.
Note that by default, VNC is not encrypted. Some flavours support it, but for more general security you may wish to look at ssh tunneling or the zebedee tunneling (apparently faster than ssh for this purpose) mentioned here.
A password is hashed and stored for a particular server (usually per-user), always one for interaction, and possibly one for viewing.
Clients may store this hash (The TightVNC client can store all connection info in a file so that a simple double-click will reconnect you). Therefore: don't use your best password, it may be brute forcable. Of course, the same goes for the password hash on the server side.
From an applet
Go to the TightVNC download page and download the 'javabin'.
Then put up a page that contains something like:
<applet code="VncViewer.class" archive="VncViewer.jar" width="1024" height="776"> <param name="PORT" value="5901"> </applet>
This example counts on this running on the same machine. Because of Java network security (the limitations on where applets can connect to), that's the easiest setup.
The applet has a pre-set size (as java applets do) and when this is smaller than the VNC screen's size it is simply not shown. The extra 8 pixels of height is for the buttons.
Possible applet parameters include:
- "HOST": Seems to default to localhost. Java's security restrictions apply.
- "PORT": Port you want to connect to. is :1, :2, etc.
- "Open New Window": "Yes" or anything else for no.
- "Show Controls": "No" to disable the buttons on top.
- "Offer Relogin": "No", or anyhing else for yes.
- "Show Offline Desktop" "Yes" to continue showing desktop if remotely disconnected.
- "PASSWORD" hard-coded password. Not generally a good idea to use.
- "ENCPASSWORD", just as bad an idea. (Don't know which hash yet, (verify))
- "Defer screen updates"
- "Defer cursor updates"
- "Defer update requests"
These (additionally GUI-configurable) options are also settable by PARAM:
- "Encoding": "Tight" by default, other possiblities are "Hextile", "RRE", "CoRRE", "Zlib"
- "Compression level": "Default" by default. (Range: 1..9)
- "JPEG image quality": "6" by default. (Range: 0..9)
- "Cursor shape updates": "Enable" by default. (Other options? "Ignore"?)
- "Use CopyRect": "Yes" by default
- "Restricted colors": "No" by default ("Yes" means 256 colors).
- "Mouse buttons 2 and 3": "Normal" by default, can be "Reversed".
- "View only": "No" by default.
- "Share desktop": "Yes" by default (multiple logins cooperate).
Client side config
On the same PC, bandwidth is irrelevant because it's largely a RAM transfer
- So Raw is the lowest-latency option
On LAN, bandwidth is barely relevant, and lowering latency is noticeable
- avoiding compression is usually worth the lower overhead
- Hextile is probably the most efficient of the raw-style variants (auto seems to prefer it because of that)
- it can help to avoid server-side and/or client-side pixelformat conversion
- if both sides are full color, then e.g. transferring 256 color is two conversions and probably not worth the saved bandwidth
On the internet, and particularly on wifi bandwidth can become important to response latency
- "auto" may land on hextile
- on wifi, ZRLE (lossless compression), or Tight without JPEG (then also lossless) tends to behave better than hextile when there are images and gradients
- if you want responsiveness and can accept lossful transfer, consider:
- tight with JPEG and/or 256 colors
Encodings - quality, bandwidth, and latency
- Hextile - sends tiles, as either raw or RRE.
- Basically "spend minimal CPU time on some wins we can easily get" 
- so often preferable over Raw, but still requires decent bandwidth. E.g. makes sense for LAN office use.
- Auto often ends up on this.
- Ultra - experimental, UltraVLC only.
- Uses LZO compresison, which is a more generic "whatever compression we can do for little CPU time"
- but lossless so not good at photographic areas (like most)
- So in theory something inbetween ZLRE and HexTile
- ZRLE - similar to tight, but:
- came later than tight(verify)
- seems slightly batter than it at the lossless part (verify), but is only lossless.
- good for mostly-monocolored regions
- does fewer incremental upgrades than tight, so tight may seem faster on certain types of regions(verify)
- For high-bandwidth the extra processing may actually be a bottlneck
- specific to realvnc, ultravnc (verify), whereas tight is supported by more
- based on zlib, with some pre-processing that should help compression ratio and CPU use
- optional JPEG compression, with quality setting
- handy for low-bandwidth connections in that it allows that lossiness tradeoff
- For high-bandwidth the extra processing may actually mean lower responsiveness than some others
- extends the tight protocol, giving more tweakability to JPEG
- other improvements are optinal use of libjpeg-turbo, multithreaded encoding, and ability to do interframe comparison
- requires TurboVNC or TigerVNC server. Recent UltraVNC servers also support it (184.108.40.206, judging from the changelog)
- ZYWRLE ('ZLib YUV Wavelet Run Length Encoding')
- lossy, video-aware.
- May be a decent tradeoff when e.g. HexTile eats too much bandwidth and ZRLE is too slow.
Usually less interesting
- least latency added by extra work, but also the largest bandwidth needs.
- usually less interesting, because in many all cases, Hextile can be at least a little cleverer
- RRE and CoRRE - basically a 2-D variant of RLE.
- Efficient for large single-color-area interfaces, and e.g. office use, not for photographic regions.
- less interesting to use specicailly, when Hextile exists and uses it adaptively
- Zlib - higher compression than ZRLE butat higher CPU cost.
- These days only useful as a fallback, e.g. when Tight or ZRLE are not available
- CopyRect - will send only areas that update (for any, or just for raw?(verify))
- generally helps, leave it on
- Cache encoding - needs CPU for checking, so is only worth it if you expect a bunch of areas to recur
- regularly doesn't help, so you can leave it off
- (note that artifacts from turbo mode and such can accumulate)
The actual exchange looks like a nonce challenge response thing.
VNC encrypts passwords using (ECB-mode) DES, with some extra details:
- If shorter than 8 bytes, the password is padded with NULs up to 8 bytes.
- ECB key is based on the password
- in ASCII form
- 8 bytes (truncated or right-padded with NULs as necessary)
- each byte bit-reversed
If you want to generate the password hash in other contexts, you may wish to find a utility like 
VNC servers tend to store the password hash in a file (or the Windows registry)
- (I've noticed at least one doing some padding of the resulting hex hash)
On linux you can change the password with , which deaults to alter - alternatively, point it at a specific file.
Can also work from stdin, e.g.
Black right half in multi-monitor (UltraVNC)
- The data seems to get to you (scrolling left and right on a smaller window works)
- making the window two monitors wide means the right side is black
Theory: The UltraVNC client seems to allocate a viewport it will draw in. By default this seems to be the first/left monitor's size (and order indeed seems to matter when you have monitors of different size). Presumably the reason is that the client allocates this before connecting, i.e. before knowing how large this viewport should be(verify)
Evidence: Some older clients allowed manual control this, with a dropdown that essentially listed each individual monitor size, and the combined desktop size. Choosing the larger one works.
Workaround: for me was an older client (e.g. 220.127.116.11), and choosing the largest size in that dropdown. You probably also want to "save connection settings as default".
HOWEVER, once you maximize the window it goes wrong again. So don't.
"Server did not offer supported security type"
Probably to Ubuntu desktop sharing, vino - by default it requires encryption, which tightvnc does not support.(verify)
(More technically, vino only allows auth method rfbTLS, and while it's auth, it also forces the socket to TLS - and it's the only one that does that)
- Switch to a VNC client that supports encryption (e.g. remmina),
- tell the server to not require encryption. Know what this means to security, though.
There is a vino-preferences, but it is just the basic settings that you also get via the taskbar icon.To not require encryption, use to find and uncheck:
org → gnome → desktop → remote-access → require-encryption
and you could additionally set to
Note that if you are comfortable with SSH, you can use it for an encrypted tunnel,
"Unknown authentication scheme from VNC server: 18" (Remmina)
Not disabling encryption helps.
More details: https://github.com/FreeRDP/Remmina/issues/433
Ultravnc forgets password, and other settings (WinXP)
That is, the Admin properties dialog lets you apply things, but once you click OK the settings are not saved in your ultravnc.ini
In our case, file permissions were not the problem.
It turns out it was a WinXP antimalware feature, specifically the "protect my computer and data from unauthorized program activity" checkmark on the "Run as" dialog that comes up when saving.
Uncheck that and you're fine.