The Remote Framebuffer Protocol

The RFB protocol can operate over any reliable transport, either byte-stream or message-based. It usually operates over a TCP/IP connection. There are three stages to the protocol. First is the handshaking phase, the purpose of which is to agree upon the protocol version and the type of security to be used. The second stage is an initialisation phase where the client and server exchange ClientInit and ServerInit messages. The final stage is the normal protocol interaction. The client can send whichever messages it wants, and may receive messages from the server as a result. All these messages begin with a message-type byte, followed by message-specific data. The following descriptions of protocol messages use the basic types U8, U16, U32, S8, S16, and S32. These represent respectively 8, 16 and 32-bit unsigned integers and 8, 16 and 32-bit signed integers. All multiple byte integers (other than pixel values themselves) are in big endian order (most significant byte first). Some messages use arrays of the basic types, with the number of entries in the array determined from fields preceding the array. The type PIXEL means a pixel value of bytesPerPixel bytes, where bytesPerPixel is the number of bits-per-pixel divided by 8. The bits-per-pixel is agreed by the client and server, either in the ServerInit message () or a SetPixelFormat message (). See for the detailed description of the pixel format.

When an RFB client and server first connect, they exchange a sequence of handshake messages that determine the protocol version, what type of connection security if any to use, a password check if the security type requires it, and some initialization information.

Handshaking begins by the server sending the client a ProtocolVersion message. This lets the client know which is the highest RFB protocol version number supported by the server. The client then replies with a similar message giving the version number of the protocol which should actually be used (which may be different to that quoted by the server). A client should never request a protocol version higher than that offered by the server. It is intended that both clients and servers may provide some level of backwards compatibility by this mechanism. The only published protocol versions at this time are 3.3, 3.7, and 3.8. Other version numbers are reported by some servers and clients, but should be interpreted as 3.3 since they do not implement the different handshake in 3.7 or 3.8. Addition of a new encoding or pseudo-encoding type does not require a change in protocol version, since a server can simply ignore encodings it does not understand. The ProtocolVersion message consists of 12 bytes interpreted as a string of ASCII characters in the format "RFB xxx.yyy\n" where xxx and yyy are the major and minor version numbers, left padded with zeros:

RFB 003.008\n (hex 52 46 42 20 30 30 33 2e 30 30 38 0a)

Once the protocol version has been decided, the server and client must agree on the type of security to be used on the connection. The server lists the security types which it supports: No. of bytes Type [Value] Description 1U8number-of-security-types number-of-security-typesU8 arraysecurity-types If the server listed at least one valid security type supported by the client, the client sends back a single byte indicating which security type is to be used on the connection: No. of bytes Type [Value] Description 1U8security-type If number-of-security-types is zero, then for some reason the connection failed (e.g. the server cannot support the desired protocol version). This is followed by a string describing the reason (where a string is specified as a length followed by that many ASCII characters): No. of bytes Type [Value] Description 4U32reason-length reason-lengthU8 arrayreason-string The server closes the connection after sending the reason-string. The security types defined in this document are: Number Name 0Invalid 1None 2VNC Authentication Other security types exist but are not publicly documented. Once the security-type has been decided, data specific to that security-type follows (see for details). At the end of the security handshaking phase, the protocol normally continues with the SecurityResult message. Note that after the security handshaking phase, it is possible that further communication is over an encrypted or otherwise altered channel if the two ends agree on an extended security type beyond the ones described here.

The server sends a word to inform the client whether the security handshaking was successful. No. of bytes Type [Value] Description 4U32 status: 0OK 1failed If successful, the protocol passes to the initialization phase (). If unsuccessful, the server sends a string describing the reason for the failure, and then closes the connection: No. of bytes Type [Value] Description 4U32reason-length reason-lengthU8 arrayreason-string

Two security types are defined here.

No authentication is needed. The protocol continues with the SecurityResult message.

VNC authentication is to be used. The server sends a random 16-byte challenge: No. of bytes Type [Value] Description 16U8challenge The client encrypts the challenge with DES, using a password supplied by the user as the key. To form the key, the password is truncated to eight characters, or padded with null bytes on the right. The client then sends the resulting 16-byte response: No. of bytes Type [Value] Description 16U8response The protocol continues with the SecurityResult message. This type of authentication is known to be cryptographically weak and is not intended for use on untrusted networks. Many implementations will want to use stronger security, such as running the session over an encrypted channel provided by IPSEC or SSH.

Once the client and server agree on and perhaps validate a security type, the protocol passes to the initialization stage. The client sends a ClientInit message. Then the server sends a ServerInit message.

No. of bytes Type [Value] Description 1U8 shared-flag Shared-flag is non-zero (true) if the server should try to share the desktop by leaving other clients connected, zero (false) if it should give exclusive access to this client by disconnecting all other clients.

After receiving the ClientInit message, the server sends a ServerInit message. This tells the client the width and height of the server's framebuffer, its pixel format and the name associated with the desktop: No. of bytes Type [Value] Description 2U16framebuffer-width in pixels 2U16framebuffer-height in pixels 16PIXEL_FORMATserver-pixel-format 4U32name-length name-lengthU8 arrayname-string Server-pixel-format specifies the server's natural pixel format. This pixel format will be used unless the client requests a different format using the SetPixelFormat message ().

Several server to client messages include a PIXEL_FORMAT, a 16 byte structure that describes the way a pixel is transmited. No. of bytes Type [Value] Description 1U8bits-per-pixel 1U8depth 1U8big-endian-flag 1U8true-color-flag 2U16red-max 2U16green-max 2U16blue-max 1U8red-shift 1U8green-shift 1U8blue-shift 3padding Bits-per-pixel is the number of bits used for each pixel value on the wire. This must be greater than or equal to the depth which is the number of useful bits in the pixel value. Currently bits-per-pixel must be 8, 16 or 32. Big-endian-flag is non-zero (true) if multi-byte pixels are interpreted as big endian. Although the depth should be consistent with the bits-per-pixel and the various -max values, clients do not use it when interpreting pixel data. If true-color-flag is non-zero (true) then the last six items specify how to extract the red, green and blue intensities from the pixel value. Red-max is the maximum red value and must be 2^N - 1 where N is the number of bits used for red. Note the -max values are always in big endian order. Red-shift is the number of shifts needed to get the red value in a pixel to the least significant bit. Green-max, green-shift and blue-max, blue-shift are similar for green and blue. For example, to find the red value (between 0 and red-max) from a given pixel, do the following: Swap the pixel value according to big-endian-flag, e.g., if big-endian-flag is zero (false) and host byte order is big endian, then swap. Shift right by red-shift. AND with red-max (in host byte order). If true-color-flag is zero (false) then the server uses pixel values which are not directly composed from the red, green and blue intensities, but which serve as indices into a color map. Entries in the color map are set by the server using the SetColorMapEntries message (See ).

The client to server message types defined in this document are: Number Name 0SetPixelFormat 2SetEncodings 3FramebufferUpdateRequest 4KeyEvent 5PointerEvent 6ClientCutText Other message types exist but are not publicly documented. Before sending a message other than those described in this document a client must have determined that the server supports the relevant extension by receiving an appropriate extension-specific confirmation from the server.

Sets the format in which pixel values should be sent in FramebufferUpdate messages. If the client does not send a SetPixelFormat message then the server sends pixel values in its natural format as specified in the ServerInit message (). If true-color-flag is zero (false) then this indicates that a "color map" is to be used. The server can set any of the entries in the color map using the SetColorMapEntries message (). Immediately after the client has sent this message the contents of the color map are undefined, even if entries had previously been set by the server. No. of bytes Type [Value] Description 1U8 [0]message-type 3padding 16PIXEL_FORMATpixel-format PIXEL_FORMAT is as described in .

Sets the encoding types in which pixel data can be sent by the server. The order of the encoding types given in this message is a hint by the client as to its preference (the first encoding specified being most preferred). The server may or may not choose to make use of this hint. Pixel data may always be sent in raw encoding even if not specified explicitly here. In addition to genuine encodings, a client can request "pseudo-encodings" to declare to the server that it supports certain extensions to the protocol. A server which does not support the extension will simply ignore the pseudo-encoding. Note that this means the client must assume that the server does not support the extension until it gets some extension-specific confirmation from the server. See for a description of each encoding and for the meaning of pseudo-encodings. No. of bytes Type [Value] Description 1U8 [2]message-type 1padding 2U16number-of-encodings followed by number-of-encodings repetitions of the following: No. of bytes Type [Value] Description 4S32encoding-type

Notifies the server that the client is interested in the area of the framebuffer specified by x-position, y-position, width and height. The server usually responds to a FramebufferUpdateRequest by sending a FramebufferUpdate. A single FramebufferUpdate may be sent in reply to several FramebufferUpdateRequests. The server assumes that the client keeps a copy of all parts of the framebuffer in which it is interested. This means that normally the server only needs to send incremental updates to the client. If the client has lost the contents of a particular area which it needs, then the client sends a FramebufferUpdateRequest with incremental set to zero (false). This requests that the server send the entire contents of the specified area as soon as possible. The area will not be updated using the CopyRect encoding. If the client has not lost any contents of the area in which it is interested, then it sends a FramebufferUpdateRequest with incremental set to non-zero (true). If and when there are changes to the specified area of the framebuffer, the server will send a FramebufferUpdate. Note that there may be an indefinite period between the FramebufferUpdateRequest and the FramebufferUpdate. In the case of a fast client, the client may want to regulate the rate at which it sends incremental FramebufferUpdateRequests to avoid excessive network traffic. No. of bytes Type [Value] Description 1U8 [3]message-type 1U8incremental 2U16 x-position 2U16 y-position 2U16 width 2U16 height

A key press or release. Down-flag is non-zero (true) if the key is now pressed, zero (false) if it is now released. The key itself is specified using the "keysym" values defined by the X Window System, even if the client or server is not running X. No. of bytes Type [Value] Description 1U8 [4]message-type 1U8down-flag 2padding 4U32key For most ordinary keys, the keysym is the same as the corresponding ASCII value. For full details, see or see the header file <X11/keysymdef.h> in the X Window System distribution. Some other common keys are: Key name Keysym value (hex) BackSpace0xff08 Tab0xff09 Return or Enter0xff0d Escape0xff1b Insert0xff63 Delete0xffff Home0xff50 End0xff57 Page Up0xff55 Page Down0xff56 Left0xff51 Up0xff52 Right0xff53 Down0xff54 F10xffbe F20xffbf F30xffc0 F40xffc1 ...... F120xffc9 Shift (left)0xffe1 Shift (right)0xffe2 Control (left)0xffe3 Control (right)0xffe4 Meta (left)0xffe7 Meta (right)0xffe8 Alt (left)0xffe9 Alt (right)0xffea The interpretation of keysyms is a complex area. In order to be as widely interoperable as possible the following guidelines should be followed: The "shift state" (i.e. whether either of the Shift keysyms is down) should only be used as a hint when interpreting a keysym. For example, on a US keyboard the '#' character is shifted, but on a UK keyboard it is not. A server with a US keyboard receiving a '#' character from a client with a UK keyboard will not have been sent any shift presses. In this case, it is likely that the server will internally need to simulate a shift press on its local system in order to get a '#' character and not a '3'. The difference between upper and lower case keysyms is significant. This is unlike some of the keyboard processing in the X Window System which treats them as the same. For example, a server receiving an uppercase 'A' keysym without any shift presses should interpret it as an uppercase 'A'. Again this may involve an internal simulated shift press. Servers should ignore "lock" keysyms such as CapsLock and NumLock where possible. Instead they should interpret each character-based keysym according to its case. Unlike Shift, the state of modifier keys such as Control and Alt should be taken as modifying the interpretation of other keysyms. Note that there are no keysyms for ASCII control characters such as Ctrl-A - these should be generated by viewers sending a Control press followed by an 'a' press. On a viewer where modifiers like Control and Alt can also be used to generate character-based keysyms, the viewer may need to send extra "release" events in order that the keysym is interpreted correctly. For example, on a German PC keyboard, Ctrl-Alt-Q generates the '@' character. In this case, the viewer needs to send simulated release events for Control and Alt in order that the '@' character is interpreted correctly, since Ctrl-Alt-@ may mean something completely different to the server. There is no universal standard for "backward tab" in the X Window System. On some systems shift+tab gives the keysym "ISO_Left_Tab", on others it gives a private "BackTab" keysym and on others it gives "Tab" and applications tell from the shift state that it means backward-tab rather than forward-tab. In the RFB protocol the latter approach is preferred. Viewers should generate a shifted Tab rather than ISO_Left_Tab. However, to be backwards-compatible with existing viewers, servers should also recognise ISO_Left_Tab as meaning a shifted Tab. Modern versions of the X Window system handle keysyms for Unicode characters, consisting of the Unicode character with the hex 1000000 bit set. For maximum compatibility, if a key has both a Unicode and a legacy encoding, clients should send the legacy encoding. Some systems give a special interpretation to key combinations such as Ctrl-Alt-Delete. VNC viewers typically provide a menu or toolbar function to send such key combinations. The VNC protocol does not treat them specially; to send Ctrl-Alt-Delete, the viewer sends the key presses for left or right Control, left or right Alt, and Delete, followed by the key releases. Many RFB servers accept Shift-Ctrl-Alt-Delete as a synonym for Ctrl-Alt-Delete that can be entered directly from the keyboard.

Indicates either pointer movement or a pointer button press or release. The pointer is now at ( x-position, y-position), and the current state of buttons 1 to 8 are represented by bits 0 to 7 of button-mask respectively, 0 meaning up, 1 meaning down (pressed). On a conventional mouse, buttons 1, 2 and 3 correspond to the left, middle and right buttons on the mouse. On a wheel mouse, each step of the wheel upwards is represented by a press and release of button 4, and each step downwards is represented by a press and release of button 5. No. of bytes Type [Value] Description 1U8 [5]message-type 1U8button-mask 2U16x-position 2U16y-position

RFB provides limited support for synchronizing the "cut buffer" of selected text between client and server. This message tells the server that the client has new ISO 8859-1 (Latin-1) text in its cut buffer. Ends of lines are represented by the newline character (hex 0a) alone. No carriage-return (hex 0d) is used. There is no way to transfer text outside the Latin-1 character set. No. of bytes Type [Value] Description 1U8 [6]message-type 3padding 4U32length lengthU8 arraytext

The server to client message types defined in this document are: Number Name 0FramebufferUpdate 1SetColorMapEntries 2Bell 3ServerCutText Other private message types exist but are not publicly documented. Before sending a message other than those described in this document a server must have determined that the client supports the relevant extension by receiving some extension-specific confirmation from the client - usually a request for a given pseudo-encoding.

A framebuffer update consists of a sequence of rectangles of pixel data which the client should put into its framebuffer. It is sent in response to a FramebufferUpdateRequest from the client. Note that there may be an indefinite period between the FramebufferUpdateRequest and the FramebufferUpdate. No. of bytes Type [Value] Description 1U8 [0]message-type 1padding 2U16number-of-rectangles This header is followed by number-of-rectangles rectangles of pixel data. Each rectangle starts with a rectangle header: No. of bytes Type [Value] Description 2U16x-position 2U16y-position 2U16width 2U16height 4S32encoding-type The rectangle header is followed by the pixel data in the specified encoding. See for the format of the data for each encoding and for the meaning of pseudo-encodings.

When the pixel format uses a "color map", this message tells the client that the specified pixel values should be mapped to the given RGB values. Note that this message may only update part of the color map. This message should not be sent by the server until after the client has sent at least one FramebufferUpdateRequest, and only when the agreed pixel format uses a color map. Color map values are always 16 bits, with the range of values running from 0 to 65535, regardless of the display hardware in use. The color map value for white, for example, is 65535,65535,65535. The message starts with a header describing the range of colormap entries to be updated. No. of bytes Type [Value] Description 1U8 [1]message-type 1padding 2U16first-color 2U16number-of-colors This header is followed by number-of-colors RGB values, each of which is in this format: No. of bytes Type [Value] Description 2U16red 2U16green 2U16blue

Make an audible signal on the client if it provides one. No. of bytes Type [Value] Description 1U8 [2]message-type

The server has new ISO 8859-1 (Latin-1) text in its cut buffer. Ends of lines are represented by the newline character (hex 0a) alone. No carriage-return (hex 0d) is used. There is no way to transfer text outside the Latin-1 character set. No. of bytes Type [Value] Description 1U8 [3]message-type 3padding 4U32length lengthU8 arraytext

The encodings defined in this document are: Number Name 0Raw 1CopyRect 2RRE 5Hextile 15TRLE 16ZRLE -239Cursor pseudo-encoding -223DesktopSize pseudo-encoding Other encoding types exist but are not publicly documented.

The simplest encoding type is raw pixel data. In this case the data consists of width*height pixel values (where width and height are the width and height of the rectangle). The values simply represent each pixel in left-to-right scan line order. All RFB clients must be able to handle pixel data in this raw encoding, and RFB servers should only produce raw encoding unless the client specifically asks for some other encoding type. No. of bytes Type [Value] Description width*height*bytesPerPixelPIXEL arraypixels

The CopyRect (copy rectangle) encoding is a very simple and efficient encoding which can be used when the client already has the same pixel data elsewhere in its framebuffer. The encoding on the wire simply consists of an X,Y coordinate. This gives a position in the framebuffer from which the client can copy the rectangle of pixel data. This can be used in a variety of situations, the most common of which are when the user moves a window across the screen, and when the contents of a window are scrolled. No. of bytes Type [Value] Description 2U16src-x-position 2U16 src-y-position For maximum compatibility the source rectangle of a CopyRect should not include pixels updated by previous entries in the same FramebufferUpdate message.

Note: RRE encoding is obsolescent. In general, ZRLE and TRLE encoding are more compact. RRE stands for rise-and-run-length encoding. As its name implies, it is essentially a two-dimensional analogue of run-length encoding. RRE-encoded rectangles arrive at the client in a form which can be rendered immediately by the simplest of graphics engines. RRE is not appropriate for complex desktops, but can be useful in some situations. The basic idea behind RRE is the partitioning of a rectangle of pixel data into rectangular subregions (subrectangles) each of which consists of pixels of a single value and the union of which comprises the original rectangular region. The near-optimal partition of a given rectangle into such subrectangles is relatively easy to compute. The encoding consists of a background pixel value, Vb (typically the most prevalent pixel value in the rectangle) and a count N, followed by a list of N subrectangles, each of which consists of a tuple <v,x,y,w,h> where v (which should be different from Vb) is the pixel value, (x,y) are the coordinates of the subrectangle relative to the top-left corner of the rectangle, and (w,h) are the width and height of the subrectangle. The client can render the original rectangle by drawing a filled rectangle of the background pixel value and then drawing a filled rectangle corresponding to each subrectangle. On the wire, the data begins with the header: No. of bytes Type [Value] Description 4U32 number-of-subrectangles bytesPerPixelPIXEL background-pixel-value This is followed by number-of-subrectangles instances of the following structure: No. of bytes Type [Value] Description bytesPerPixelPIXELsubrect-pixel-value 2U16x-position 2U16y-position 2U16width 2U16height

Note: Hextile encoding is obsolescent. In general, ZRLE and TRLE encoding are more compact. Hextile is a variation on RRE. Rectangles are split up into 16x16 tiles, allowing the dimensions of the subrectangles to be specified in 4 bits each, 16 bits in total. The rectangle is split into tiles starting at the top left going in left-to-right, top-to-bottom order. The encoded contents of the tiles simply follow one another in the predetermined order. If the width of the whole rectangle is not an exact multiple of 16 then the width of the last tile in each row will be correspondingly smaller. Similarly if the height of the whole rectangle is not an exact multiple of 16 then the height of each tile in the final row will also be smaller. Each tile is either encoded as raw pixel data, or as a variation on RRE. Each tile has a background pixel value, as before. However, the background pixel value does not need to be explicitly specified for a given tile if it is the same as the background of the previous tile. If all of the subrectangles of a tile have the same pixel value, this can be specified once as a foreground pixel value for the whole tile. As with the background, the foreground pixel value can be left unspecified, meaning it is carried over from the previous tile. The data consists of each tile encoded in order. Each tile begins with a subencoding type byte, which is a mask made up of a number of bits: No. of bytes Type [Value] Description 1U8subencoding-mask: [1]Raw [2]BackgroundSpecified [4]ForegroundSpecified [8]AnySubrects [16]SubrectsColored If the Raw bit is set then the other bits are irrelevant; width*height pixel values follow (where width and height are the width and height of the tile). Otherwise the other bits in the mask are as follows: If set, a pixel value of bytesPerPixel bytes follows which specifies the background color for this tile. The first non-raw tile in a rectangle must have this bit set. If this bit isn't set then the background is the same as the last tile. If set, a pixel value of bytesPerPixel bytes follows which specifies the foreground color to be used for all subrectangles in this tile. If this bit is set then the SubrectsColored bit must be zero. If set, a single byte follows giving the number of subrectangles following. If not set, there are no subrectangles (i.e. the whole tile is just solid background color). If set then each subrectangle is preceded by a pixel value giving the color of that subrectangle, so a subrectangle is: No. of bytes Type [Value] Description bytesPerPixelPIXELsubrect-pixel-value 1U8 x-and-y-position 1U8 width-and-height If not set, all subrectangles are the same color, the foreground color; if the ForegroundSpecified bit wasn't set then the foreground is the same as the last tile. A subrectangle is: No. of bytes Type [Value] Description 1U8 x-and-y-position 1U8 width-and-height The position and size of each subrectangle is specified in two bytes, x-and-y-position and width-and-height. The most-significant four bits of x-and-y-position specify the X position, the least-significant specify the Y position. The most-significant four bits of width-and-height specify the width minus one, the least-significant specify the height minus one.

TRLE stands for Tiled Run-Length Encoding, and combines tiling, palettisation and run-length encoding. The rectangle is divided into tiles of 16x16 pixels in left-to-right, top-to-bottom order, similar to hextile. If the width of the rectangle is not an exact multiple of 16 then the width of the last tile in each row is smaller, and if the height of the rectangle is not an exact multiple of 16 then the height of each tile in the final row is smaller. TRLE makes use of a new type CPIXEL (compressed pixel). This is the same as a PIXEL for the agreed pixel format, except where true-color-flag is non-zero, bits-per-pixel is 32, depth is 24 or less and all of the bits making up the red, green and blue intensities fit in either the least significant 3 bytes or the most significant 3 bytes. In this case a CPIXEL is only 3 bytes long, and contains the least significant or the most significant 3 bytes as appropriate. bytesPerCPixel is the number of bytes in a CPIXEL. Each tile begins with a subencoding type byte. The top bit of this byte is set if the tile has been run-length encoded, clear otherwise. The bottom seven bits indicate the size of the palette used: zero means no palette, one means that the tile is of a single color, and 2 to 127 indicate a palette of that size. The special values 129 and 127 indicate that the palette is to be reused from the previous tile, with and without RLE respectively. Note: in this discussion, the div(a,b) function means the result of dividing a/b truncated to an integer. The possible values of subencoding are: Raw pixel data. width*height pixel values follow (where width and height are the width and height of the tile): No. of bytes Type [Value] Description width*height*BytesPerCPixel CPIXEL arraypixels A solid tile consisting of a single color. The pixel value follows: No. of bytes Type [Value] Description bytesPerCPixelCPIXELpixelValue Packed palette types. The palleteSize is the value of the subencoding, which is followed by the palette, consisting of paletteSize pixel values. The packed pixels follow, with each pixel represented as a bit field yielding a 0-based index into the palette. For paletteSize 2, a 1-bit field is used, for paletteSize 3 or 4 a 2-bit field is used, and for paletteSize from 5 to 16 a 4-bit field is used. The bit fields are packed into bytes, with the most significant bits representing the leftmost pixel (i.e. big endian). For tiles not a multiple of 8, 4 or 2 pixels wide (as appropriate), padding bits are used to align each row to an exact number of bytes. No. of bytes Type [Value] Description paletteSize*bytesPerCPixelCPIXEL arraypalette mU8 arraypackedPixels where m is the number of bytes representing the packed pixels. For paletteSize of 2 this is div(width+7,8)*height, for paletteSize of 3 or 4 this is div(width+3,4)*height, or for paletteSize of 5 to 16 this is div(width+1,2)*height. Unused. (Packed palettes of these sizes would offer no advantage over palette RLE). Packed palette with the palette reused from the previous tile. The subencoding byte is followed by the packed pixels as described above for packed palette types. Plain RLE. The data consists of a number of runs, repeated until the tile is done. Runs may continue from the end of one row to the beginning of the next. Each run is a represented by a single pixel value followed by the length of the run. The length is represented as one or more bytes. The length is calculated as one more than the sum of all the bytes representing the length. Any byte value other than 255 indicates the final byte. So for example length 1 is represented as [0], 255 as [254], 256 as [255,0], 257 as [255,1], 510 as [255,254], 511 as [255,255,0] and so on. No. of bytes Type [Value] Description bytesPerCPixelCPIXELpixelValue div(runLength - 1, 255)U8 array255 1U8(runLength-1) mod 255 Palette RLE with the palette reused from the previous tile. Followed by a number of runs, repeated until the tile is done, as described below for 130 to 255. Palette RLE. Followed by the palette, consisting of paletteSize = (subencoding - 128) pixel values: No. of bytes Type [Value] Description paletteSize*bytesPerCPixelCPIXEL arraypalette Following the palette is, as with plain RLE, of a number of runs, repeated until the tile is done. A run of length one is represented simply by a palette index: No. of bytes Type [Value] Description 1U8paletteIndex A run of length more than one is represented by a palette index with the top bit set, followed by the length of the run as for plain RLE. No. of bytes Type [Value] Description 1U8paletteIndex + 128 div(runLength - 1, 255)U8 array255 1U8(runLength-1) mod 255

ZRLE stands for Zlib (see and ) Run-Length Encoding, and combines an encoding similar to TRLE with zlib compression. On the wire, the rectangle consists of zlib-compressed data which continues until the end of the message. A single zlib "stream" object is used for a given RFB protocol connection, so that ZRLE rectangles must be encoded and decoded strictly in order. No. of bytes Type [Value] Description lengthU8 arrayzlibData The zlibData when uncompressed represents tiles in left-to-right, top-to-bottom order, similar to TRLE, but with a tile size of 64x64 pixels. If the width of the rectangle is not an exact multiple of 64 then the width of the last tile in each row is smaller, and if the height of the rectangle is not an exact multiple of 64 then the height of each tile in the final row is smaller. The tiles are encoded in exactly the same way as TRLE, except that subencoding may not take the values 127 or 129, i.e. palettes cannot be reused between tiles. The server flushes the zlib stream to a byte boundary at the end of each ZRLE encoded message. It need not flush the stream between tiles within a message. Since the zlibData for a single message can potentially be quite large, clients can incrementally decode and interpret the zlibData but must not assume that encoded tile data is byte aligned.

An update rectangle with a "pseudo-encoding" does not directly represent pixel data but instead allows the server to send arbitrary data to the client. How this data is interpreted depends on the pseudo-encoding.

A client which requests the Cursor pseudo-encoding is declaring that it is capable of drawing a pointer cursor locally. This can significantly improve perceived performance over slow links. The server sets the cursor shape by sending a rectangle with the Cursor pseudo-encoding as part of an update. The rectangle's x-position and y-position indicate the hotspot of the cursor, and width and height indicate the width and height of the cursor in pixels. The data consists of width*height raw pixel values followed by a shape bitmask, with one bit corresponding to each pixel in the cursor rectangle. The bitmask consists of left-to-right, top-to-bottom scan lines, where each scan line is padded to a whole number of bytes div(width+7,8). Within each byte the most significant bit represents the leftmost pixel, with a 1-bit meaning the corresponding pixel in the cursor is valid. No. of bytes Type [Value] Description width*height*bytesPerPixelPIXEL arraycursor-pixels div(width+7,8)*heightU8 arraybitmask

A client which requests the DesktopSize pseudo-encoding is declaring that it is capable of coping with a change in the framebuffer width and height. The server changes the desktop size by sending a rectangle with the DesktopSize pseudo-encoding as the last rectangle in an update. The rectangle's x-position and y-position are ignored, and width and height indicate the new width and height of the framebuffer. There is no further data associated with the rectangle. After changing the desktop size, the server must assume that the client no longer has the previous framebuffer contents. This will usually result in a complete update of the framebuffer at the next update. However for maximum interoperability with existing servers the client should preserve the top-left portion of the framebuffer between the old and new sizes.