Table of Contents
ggivnc [-adhiv46] [-e <encodings>] [-E <endian>] [-f <pixfmt>]
[--gii <input>] [-p <password>] [--rfb <version>]
[-s <security>] [-b <interface>] -l[<display>|:<port>]
ggivnc [-adhiv46] [-e <encodings>] [-E <endian>] [-f <pixfmt>]
[--gii <input>] [-p <password>] [--rfb <version>]
[-s <security>] [server[:<display>|::<port>]]In the above, the square brackets denote optional arguments, but if server contains a colon or starts with a literal “[”, quote it with literal square brackets to have ggivnc not interpret part of the server name as the display or port. E.g. [::ffff:192.168.1.1] (for IPv6 users).
ggivnc makes a TCP connection to the specified VNC server and expects the server to communicate with the remote framebuffer (RFB) protocol. ggivnc can also operate in reverse and listen for connections from VNC servers. ggivnc supports RFB protocol versions 3.3 through 3.8. The display can optionally be specified, but if it is not display 0 is the default. The display is simply a shortcut for which TCP port to connect to, where the base display 0 maps to TCP port 5900. E.g. display 4 is equivalent to port 5904. An alternative is to directly specify the port. In reversed mode (when listening), the base is moved from port 5900 to port 5500.
The remote framebuffer is displayed on the selected libggi target. See libggi(7) for how to select the libggi target.
ggivnc supports the following RFB encodings:
Raw, CopyRect, RRE, CoRRE, Hextile, Zlib, Tight, ZlibHex, ZRLE, DesktopSize, LastRect, GII, DesktopName and WMVi.
The encodings are described in a few words below, in the ENCODINGS section.
Pressing F8 presents a menu with options to:
-a, —alone
—shared
-b, —bind <interface>
-l, —listen.
-d, —debug
-e, —encodings <encodings>
Give a comma separated list of encodings that should be requested from the server, in order of preference. If the -e option is not given, a preferred encoding is selected based on throughput.
The available encodings are: raw, copyrect, rre, corre, hextile, zlib, tight, zlibhex and zrle.
In addition to the above encodings, the pseudo-encodings desksize, deskname, lastrect and wmvi can also be selected and 10 tight encoding quality levels are also available, i.e. quality0 - quality9 where quality9 is better quality for faster data links. Also, 10 tight encoding compression levels are available, i.e. zip1 - zip9 where zip9 is slower with higher compression ratio. zip0 lets the server decide the compression level. Last but not least, the gii pseudo-encoding is available.
Example: -e copyrect,hextile,desksize,deskname,lastrect
-E, —endian <endian>
-f, —pixfmt <pixfmt>
pixfmt is either r<bits>g<bits>b<bits> (in any order, insert p<bits> as desired for padding), c<bits>, local or server.
r<bits>g<bits>b<bits> indicates that the on-the-wire pixel format will be this specific true-color variation.
c<bits> indicates that the on-the-wire pixel format will be palettized.
local (the default) indicates that the on-the-wire pixel format will be identical to that of the current GGI target.
server indicates that the on-the-wire pixel format will be whatever the server prefers. The on-the-wire endianess will in this case also be whatever the server prefers, unless the -E option is also used.
—gii <input>
-h, —help
-i, —no-input
-l[<display>|:<port>], —listen[=<display>|=:<port>]
-p, —password <password>
—rfb <version>
-s, —security-types <security-types>
Give a comma separated list of security types that should be allowed, in order of preference. If the -s option is not given, ggivnc prefers security type none over vnc-auth.
The available security types are: none, vnc-auth, tight
If a list of allowed security types is given and the server does not support any of the allowed security types, ggivnc will try to request the first security type in the given list, on the off chance that the server will allow it even if it is not saying so.
The security types are described in a few words below, in the SECURITY TYPES section.
-v, —version
-4, —ipv4
-6, —ipv6
Below follows a short description of each of the supported encodings.
This is a tiled encoding where each tile is 64x64 pixels. Each tile is encoded using one of these subencodings: Raw, Solid, Packed Palette, RLE or Palette RLE. The Packed Palette subencoding may be used when there are few colors (16 or less) in the tile. The pixels are represented with 1, 2 or 4 bits depending on the size of the palette, and the pixels are then packed as tightly as possible within bytes. The RLE subencoding stores the length of horizontal runs, and their color, while the Palette RLE subencoding does likewise, but using palette lookup (max 127 colors) in order to reduce the color specification overhead.
The whole ZRLE rectanle is then compressed using the zlib deflate algorithm.
The LastRect pseudo-encoding enables the server to start to transmit an update consisting of several rectangles, without knowing exactly how many rectangles the update will eventually consist of. It may start transmitting the update, and when it is done it just sends a fake rectangle saying that there are no more rectangles in the update.
In some situations this enables the server to start transmitting the update before it has completed all the work needed to calculate the contents of the update.
The application will simply exit when protocol errors are detected.
If the remote framebuffer is larger than the local GGI target, scrollbars are provided to select which part of the remote framebuffer to view, but only if ggivnc has been built with support for this. Without scrollbar support, ggivnc will pan the remote framebuffer when the mouse is moved close to a border.
If the server argument is not given, a dialog will prompt for what server to connect to, but only if ggivnc has been built with support for this. Without this support, ggivnc requires that the server argument is given on the command line.
Not all targets support passing on hotkeys to the remote end.
The -4 and -6 options are only available if ggivnc has been built with support for this.
The reason ggivnc came about was to fill the need of a companion to the VNC target in libggi. All existing VNC code was at the time of writing and to the best of my knowledge GPL and originating from the original AT&T code base (either that, or hidden from sight). This VNC client is an implementation from scratch.