summaryrefslogtreecommitdiffstats
path: root/krdc/vnc/rfbproto.h
diff options
context:
space:
mode:
Diffstat (limited to 'krdc/vnc/rfbproto.h')
-rw-r--r--krdc/vnc/rfbproto.h963
1 files changed, 0 insertions, 963 deletions
diff --git a/krdc/vnc/rfbproto.h b/krdc/vnc/rfbproto.h
deleted file mode 100644
index 6cf7c740..00000000
--- a/krdc/vnc/rfbproto.h
+++ /dev/null
@@ -1,963 +0,0 @@
-/*
- * Copyright (C) 2000-2002 Constantin Kaplinsky. All Rights Reserved.
- * Copyright (C) 2000 Tridia Corporation. All Rights Reserved.
- * Copyright (C) 1999 AT&T Laboratories Cambridge. All Rights Reserved.
- *
- * This is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * This software is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this software; if not, write to the Free Software
- * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
- * USA.
- */
-
-/*
- * rfbproto.h - header file for the RFB protocol version 3.3
- *
- * Uses types CARD<n> for an n-bit unsigned integer, INT<n> for an n-bit signed
- * integer (for n = 8, 16 and 32).
- *
- * All multiple byte integers are in big endian (network) order (most
- * significant byte first). Unless noted otherwise there is no special
- * alignment of protocol structures.
- *
- *
- * Once the initial handshaking is done, all messages start with a type byte,
- * (usually) followed by message-specific data. The order of definitions in
- * this file is as follows:
- *
- * (1) Structures used in several types of message.
- * (2) Structures used in the initial handshaking.
- * (3) Message types.
- * (4) Encoding types.
- * (5) For each message type, the form of the data following the type byte.
- * Sometimes this is defined by a single structure but the more complex
- * messages have to be explained by comments.
- */
-
-#include "vnctypes.h"
-
-/*****************************************************************************
- *
- * Structures used in several messages
- *
- *****************************************************************************/
-
-/*-----------------------------------------------------------------------------
- * Structure used to specify a rectangle. This structure is a multiple of 4
- * bytes so that it can be interspersed with 32-bit pixel data without
- * affecting alignment.
- */
-
-typedef struct {
- CARD16 x;
- CARD16 y;
- CARD16 w;
- CARD16 h;
-} rfbRectangle;
-
-#define sz_rfbRectangle 8
-
-
-/*-----------------------------------------------------------------------------
- * Structure used to specify pixel format.
- */
-
-typedef struct {
-
- CARD8 bitsPerPixel; /* 8,16,32 only */
-
- CARD8 depth; /* 8 to 32 */
-
- CARD8 bigEndian; /* True if multi-byte pixels are interpreted
- as big endian, or if single-bit-per-pixel
- has most significant bit of the byte
- corresponding to first (leftmost) pixel. Of
- course this is meaningless for 8 bits/pix */
-
- CARD8 trueColour; /* If false then we need a "colour map" to
- convert pixels to RGB. If true, xxxMax and
- xxxShift specify bits used for red, green
- and blue */
-
- /* the following fields are only meaningful if trueColour is true */
-
- CARD16 redMax; /* maximum red value (= 2^n - 1 where n is the
- number of bits used for red). Note this
- value is always in big endian order. */
-
- CARD16 greenMax; /* similar for green */
-
- CARD16 blueMax; /* and blue */
-
- CARD8 redShift; /* number of shifts needed to get the red
- value in a pixel to the least significant
- bit. To find the red value from a given
- pixel, do the following:
- 1) Swap pixel value according to bigEndian
- (e.g. if bigEndian is false and host byte
- order is big endian, then swap).
- 2) Shift right by redShift.
- 3) AND with redMax (in host byte order).
- 4) You now have the red value between 0 and
- redMax. */
-
- CARD8 greenShift; /* similar for green */
-
- CARD8 blueShift; /* and blue */
-
- CARD8 pad1;
- CARD16 pad2;
-
-} rfbPixelFormat;
-
-#define sz_rfbPixelFormat 16
-
-
-
-/*****************************************************************************
- *
- * Initial handshaking messages
- *
- *****************************************************************************/
-
-/*-----------------------------------------------------------------------------
- * Protocol Version
- *
- * The server always sends 12 bytes to start which identifies the latest RFB
- * protocol version number which it supports. These bytes are interpreted
- * as a string of 12 ASCII characters in the format "RFB xxx.yyy\n" where
- * xxx and yyy are the major and minor version numbers (for version 3.3
- * this is "RFB 003.003\n").
- *
- * The client then replies with a similar 12-byte message giving the version
- * number of the protocol which should actually be used (which may be different
- * to that quoted by the server).
- *
- * It is intended that both clients and servers may provide some level of
- * backwards compatibility by this mechanism. Servers in particular should
- * attempt to provide backwards compatibility, and even forwards compatibility
- * to some extent. For example if a client demands version 3.1 of the
- * protocol, a 3.0 server can probably assume that by ignoring requests for
- * encoding types it doesn't understand, everything will still work OK. This
- * will probably not be the case for changes in the major version number.
- *
- * The format string below can be used in sprintf or sscanf to generate or
- * decode the version string respectively.
- */
-
-#define rfbProtocolVersionFormat "RFB %03d.%03d\n"
-#define rfbProtocolMajorVersion 3
-#define rfbProtocolMinorVersion 3
-
-typedef char rfbProtocolVersionMsg[13]; /* allow extra byte for null */
-
-#define sz_rfbProtocolVersionMsg 12
-
-
-/*-----------------------------------------------------------------------------
- * Authentication
- *
- * Once the protocol version has been decided, the server then sends a 32-bit
- * word indicating whether any authentication is needed on the connection.
- * The value of this word determines the authentication scheme in use. For
- * version 3.0 of the protocol this may have one of the following values:
- */
-
-#define rfbConnFailed 0
-#define rfbNoAuth 1
-#define rfbVncAuth 2
-
-/*
- * rfbConnFailed: 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 32-bit length followed by that
- * many ASCII characters).
- *
- * rfbNoAuth: No authentication is needed.
- *
- * rfbVncAuth: The VNC authentication scheme is to be used. A 16-byte
- * challenge follows, which the client encrypts as
- * appropriate using the password and sends the resulting
- * 16-byte response. If the response is correct, the
- * server sends the 32-bit word rfbVncAuthOK. If a simple
- * failure happens, the server sends rfbVncAuthFailed and
- * closes the connection. If the server decides that too
- * many failures have occurred, it sends rfbVncAuthTooMany
- * and closes the connection. In the latter case, the
- * server should not allow an immediate reconnection by
- * the client.
- */
-
-#define rfbVncAuthOK 0
-#define rfbVncAuthFailed 1
-#define rfbVncAuthTooMany 2
-
-
-/*-----------------------------------------------------------------------------
- * Client Initialisation Message
- *
- * Once the client and server are sure that they're happy to talk to one
- * another, the client sends an initialisation message. At present this
- * message only consists of a boolean indicating whether the server should try
- * to share the desktop by leaving other clients connected, or give exclusive
- * access to this client by disconnecting all other clients.
- */
-
-typedef struct {
- CARD8 shared;
-} rfbClientInitMsg;
-
-#define sz_rfbClientInitMsg 1
-
-
-/*-----------------------------------------------------------------------------
- * Server Initialisation Message
- *
- * After the client initialisation message, the server sends one of its own.
- * This tells the client the width and height of the server's framebuffer,
- * its pixel format and the name associated with the desktop.
- */
-
-typedef struct {
- CARD16 framebufferWidth;
- CARD16 framebufferHeight;
- rfbPixelFormat format; /* the server's preferred pixel format */
- CARD32 nameLength;
- /* followed by char name[nameLength] */
-} rfbServerInitMsg;
-
-#define sz_rfbServerInitMsg (8 + sz_rfbPixelFormat)
-
-
-/*
- * Following the server initialisation message it's up to the client to send
- * whichever protocol messages it wants. Typically it will send a
- * SetPixelFormat message and a SetEncodings message, followed by a
- * FramebufferUpdateRequest. From then on the server will send
- * FramebufferUpdate messages in response to the client's
- * FramebufferUpdateRequest messages. The client should send
- * FramebufferUpdateRequest messages with incremental set to true when it has
- * finished processing one FramebufferUpdate and is ready to process another.
- * With a fast client, the rate at which FramebufferUpdateRequests are sent
- * should be regulated to avoid hogging the network.
- */
-
-
-
-/*****************************************************************************
- *
- * Message types
- *
- *****************************************************************************/
-
-/* server -> client */
-
-#define rfbFramebufferUpdate 0
-#define rfbSetColourMapEntries 1
-#define rfbBell 2
-#define rfbServerCutText 3
-
-
-/* client -> server */
-
-#define rfbSetPixelFormat 0
-#define rfbFixColourMapEntries 1 /* not currently supported */
-#define rfbSetEncodings 2
-#define rfbFramebufferUpdateRequest 3
-#define rfbKeyEvent 4
-#define rfbPointerEvent 5
-#define rfbClientCutText 6
-
-
-
-
-/*****************************************************************************
- *
- * Encoding types
- *
- *****************************************************************************/
-
-#define rfbEncodingRaw 0
-#define rfbEncodingCopyRect 1
-#define rfbEncodingRRE 2
-#define rfbEncodingCoRRE 4
-#define rfbEncodingHextile 5
-#define rfbEncodingZlib 6
-#define rfbEncodingTight 7
-#define rfbEncodingZlibHex 8
-
-/*
- * Special encoding numbers:
- * 0xFFFFFF00 .. 0xFFFFFF0F -- encoding-specific compression levels;
- * 0xFFFFFF10 .. 0xFFFFFF1F -- mouse cursor shape data;
- * 0xFFFFFF20 .. 0xFFFFFF2F -- various protocol extensions;
- * 0xFFFFFF30 .. 0xFFFFFFDF -- not allocated yet;
- * 0xFFFFFFE0 .. 0xFFFFFFEF -- quality level for JPEG compressor;
- * 0xFFFFFFF0 .. 0xFFFFFFFF -- cross-encoding compression levels.
- */
-
-/*
- * Reserved range for TDE:
- * 0xFFFE0100 - 0xFFFE01FF
- */
-
-#define rfbEncodingBackground 0xFFFE0125
-
-#define rfbEncodingCompressLevel0 0xFFFFFF00
-#define rfbEncodingCompressLevel1 0xFFFFFF01
-#define rfbEncodingCompressLevel2 0xFFFFFF02
-#define rfbEncodingCompressLevel3 0xFFFFFF03
-#define rfbEncodingCompressLevel4 0xFFFFFF04
-#define rfbEncodingCompressLevel5 0xFFFFFF05
-#define rfbEncodingCompressLevel6 0xFFFFFF06
-#define rfbEncodingCompressLevel7 0xFFFFFF07
-#define rfbEncodingCompressLevel8 0xFFFFFF08
-#define rfbEncodingCompressLevel9 0xFFFFFF09
-
-#define rfbEncodingXCursor 0xFFFFFF10
-#define rfbEncodingRichCursor 0xFFFFFF11
-#define rfbEncodingSoftCursor 0xFFFFFF12
-#define rfbEncodingPointerPos 0xFFFFFF18
-
-#define rfbEncodingLastRect 0xFFFFFF20
-
-#define rfbEncodingQualityLevel0 0xFFFFFFE0
-#define rfbEncodingQualityLevel1 0xFFFFFFE1
-#define rfbEncodingQualityLevel2 0xFFFFFFE2
-#define rfbEncodingQualityLevel3 0xFFFFFFE3
-#define rfbEncodingQualityLevel4 0xFFFFFFE4
-#define rfbEncodingQualityLevel5 0xFFFFFFE5
-#define rfbEncodingQualityLevel6 0xFFFFFFE6
-#define rfbEncodingQualityLevel7 0xFFFFFFE7
-#define rfbEncodingQualityLevel8 0xFFFFFFE8
-#define rfbEncodingQualityLevel9 0xFFFFFFE9
-
-
-/*****************************************************************************
- *
- * Server -> client message definitions
- *
- *****************************************************************************/
-
-
-/*-----------------------------------------------------------------------------
- * FramebufferUpdate - a block of rectangles to be copied to the framebuffer.
- *
- * This message consists of a header giving the number of rectangles of pixel
- * data followed by the rectangles themselves. The header is padded so that
- * together with the type byte it is an exact multiple of 4 bytes (to help
- * with alignment of 32-bit pixels):
- */
-
-typedef struct {
- CARD8 type; /* always rfbFramebufferUpdate */
- CARD8 pad;
- CARD16 nRects;
- /* followed by nRects rectangles */
-} rfbFramebufferUpdateMsg;
-
-#define sz_rfbFramebufferUpdateMsg 4
-
-/*
- * Each rectangle of pixel data consists of a header describing the position
- * and size of the rectangle and a type word describing the encoding of the
- * pixel data, followed finally by the pixel data. Note that if the client has
- * not sent a SetEncodings message then it will only receive raw pixel data.
- * Also note again that this structure is a multiple of 4 bytes.
- */
-
-typedef struct {
- rfbRectangle r;
- CARD32 encoding; /* one of the encoding types rfbEncoding... */
-} rfbFramebufferUpdateRectHeader;
-
-#define sz_rfbFramebufferUpdateRectHeader (sz_rfbRectangle + 4)
-
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * Raw Encoding. Pixels are sent in top-to-bottom scanline order,
- * left-to-right within a scanline with no padding in between.
- */
-
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * CopyRect Encoding. The pixels are specified simply by the x and y position
- * of the source rectangle.
- */
-
-typedef struct {
- CARD16 srcX;
- CARD16 srcY;
-} rfbCopyRect;
-
-#define sz_rfbCopyRect 4
-
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * RRE - Rise-and-Run-length Encoding. We have an rfbRREHeader structure
- * giving the number of subrectangles following. Finally the data follows in
- * the form [<bgpixel><subrect><subrect>...] where each <subrect> is
- * [<pixel><rfbRectangle>].
- */
-
-typedef struct {
- CARD32 nSubrects;
-} rfbRREHeader;
-
-#define sz_rfbRREHeader 4
-
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * CoRRE - Compact RRE Encoding. We have an rfbRREHeader structure giving
- * the number of subrectangles following. Finally the data follows in the form
- * [<bgpixel><subrect><subrect>...] where each <subrect> is
- * [<pixel><rfbCoRRERectangle>]. This means that
- * the whole rectangle must be at most 255x255 pixels.
- */
-
-typedef struct {
- CARD8 x;
- CARD8 y;
- CARD8 w;
- CARD8 h;
-} rfbCoRRERectangle;
-
-#define sz_rfbCoRRERectangle 4
-
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * Hextile Encoding. The rectangle is divided up into "tiles" of 16x16 pixels,
- * starting at the top left going in left-to-right, top-to-bottom order. If
- * the width of the 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 is not an exact multiple of 16 then the height of each tile in the
- * final row will also be smaller. Each tile begins with a "subencoding" type
- * byte, which is a mask made up of a number of bits. If the Raw bit is set
- * then the other bits are irrelevant; w*h pixel values follow (where w and h
- * are the width and height of the tile). Otherwise the tile is encoded in a
- * similar way to RRE, except that the position and size of each subrectangle
- * can be specified in just two bytes. The other bits in the mask are as
- * follows:
- *
- * BackgroundSpecified - if set, a pixel value follows which specifies
- * the background colour 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.
- *
- * ForegroundSpecified - if set, a pixel value follows which specifies
- * the foreground colour to be used for all subrectangles in this tile.
- * If this bit is set then the SubrectsColoured bit must be zero.
- *
- * AnySubrects - 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 colour).
- *
- * SubrectsColoured - if set then each subrectangle is preceded by a pixel
- * value giving the colour of that subrectangle. If not set, all
- * subrectangles are the same colour, the foreground colour; if the
- * ForegroundSpecified bit wasn't set then the foreground is the same as
- * the last tile.
- *
- * The position and size of each subrectangle is specified in two bytes. The
- * Pack macros below can be used to generate the two bytes from x, y, w, h,
- * and the Extract macros can be used to extract the x, y, w, h values from
- * the two bytes.
- */
-
-#define rfbHextileRaw (1 << 0)
-#define rfbHextileBackgroundSpecified (1 << 1)
-#define rfbHextileForegroundSpecified (1 << 2)
-#define rfbHextileAnySubrects (1 << 3)
-#define rfbHextileSubrectsColoured (1 << 4)
-
-#define rfbHextilePackXY(x,y) (((x) << 4) | (y))
-#define rfbHextilePackWH(w,h) ((((w)-1) << 4) | ((h)-1))
-#define rfbHextileExtractX(byte) ((byte) >> 4)
-#define rfbHextileExtractY(byte) ((byte) & 0xf)
-#define rfbHextileExtractW(byte) (((byte) >> 4) + 1)
-#define rfbHextileExtractH(byte) (((byte) & 0xf) + 1)
-
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * zlib - zlib compressed Encoding. We have an rfbZlibHeader structure
- * giving the number of bytes following. Finally the data follows is
- * zlib compressed version of the raw pixel data as negotiated.
- */
-
-typedef struct {
- CARD32 nBytes;
-} rfbZlibHeader;
-
-#define sz_rfbZlibHeader 4
-
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * Tight Encoding.
- *
- *-- The first byte of each Tight-encoded rectangle is a "compression control
- * byte". Its format is as follows (bit 0 is the least significant one):
- *
- * bit 0: if 1, then compression stream 0 should be reset;
- * bit 1: if 1, then compression stream 1 should be reset;
- * bit 2: if 1, then compression stream 2 should be reset;
- * bit 3: if 1, then compression stream 3 should be reset;
- * bits 7-4: if 1000 (0x08), then the compression type is "fill",
- * if 1001 (0x09), then the compression type is "jpeg",
- * if 0xxx, then the compression type is "basic",
- * values greater than 1001 are not valid.
- *
- * If the compression type is "basic", then bits 6..4 of the
- * compression control byte (those xxx in 0xxx) specify the following:
- *
- * bits 5-4: decimal representation is the index of a particular zlib
- * stream which should be used for decompressing the data;
- * bit 6: if 1, then a "filter id" byte is following this byte.
- *
- *-- The data that follows after the compression control byte described
- * above depends on the compression type ("fill", "jpeg" or "basic").
- *
- *-- If the compression type is "fill", then the only pixel value follows, in
- * client pixel format (see NOTE 1). This value applies to all pixels of the
- * rectangle.
- *
- *-- If the compression type is "jpeg", the following data stream looks like
- * this:
- *
- * 1..3 bytes: data size (N) in compact representation;
- * N bytes: JPEG image.
- *
- * Data size is compactly represented in one, two or three bytes, according
- * to the following scheme:
- *
- * 0xxxxxxx (for values 0..127)
- * 1xxxxxxx 0yyyyyyy (for values 128..16383)
- * 1xxxxxxx 1yyyyyyy zzzzzzzz (for values 16384..4194303)
- *
- * Here each character denotes one bit, xxxxxxx are the least significant 7
- * bits of the value (bits 0-6), yyyyyyy are bits 7-13, and zzzzzzzz are the
- * most significant 8 bits (bits 14-21). For example, decimal value 10000
- * should be represented as two bytes: binary 10010000 01001110, or
- * hexadecimal 90 4E.
- *
- *-- If the compression type is "basic" and bit 6 of the compression control
- * byte was set to 1, then the next (second) byte specifies "filter id" which
- * tells the decoder what filter type was used by the encoder to pre-process
- * pixel data before the compression. The "filter id" byte can be one of the
- * following:
- *
- * 0: no filter ("copy" filter);
- * 1: "palette" filter;
- * 2: "gradient" filter.
- *
- *-- If bit 6 of the compression control byte is set to 0 (no "filter id"
- * byte), or if the filter id is 0, then raw pixel values in the client
- * format (see NOTE 1) will be compressed. See below details on the
- * compression.
- *
- *-- The "gradient" filter pre-processes pixel data with a simple algorithm
- * which converts each color component to a difference between a "predicted"
- * intensity and the actual intensity. Such a technique does not affect
- * uncompressed data size, but helps to compress photo-like images better.
- * Pseudo-code for converting intensities to differences is the following:
- *
- * P[i,j] := V[i-1,j] + V[i,j-1] - V[i-1,j-1];
- * if (P[i,j] < 0) then P[i,j] := 0;
- * if (P[i,j] > MAX) then P[i,j] := MAX;
- * D[i,j] := V[i,j] - P[i,j];
- *
- * Here V[i,j] is the intensity of a color component for a pixel at
- * coordinates (i,j). MAX is the maximum value of intensity for a color
- * component.
- *
- *-- The "palette" filter converts true-color pixel data to indexed colors
- * and a palette which can consist of 2..256 colors. If the number of colors
- * is 2, then each pixel is encoded in 1 bit, otherwise 8 bits is used to
- * encode one pixel. 1-bit encoding is performed such way that the most
- * significant bits correspond to the leftmost pixels, and each raw of pixels
- * is aligned to the byte boundary. When "palette" filter is used, the
- * palette is sent before the pixel data. The palette begins with an unsigned
- * byte which value is the number of colors in the palette minus 1 (i.e. 1
- * means 2 colors, 255 means 256 colors in the palette). Then follows the
- * palette itself which consist of pixel values in client pixel format (see
- * NOTE 1).
- *
- *-- The pixel data is compressed using the zlib library. But if the data
- * size after applying the filter but before the compression is less then 12,
- * then the data is sent as is, uncompressed. Four separate zlib streams
- * (0..3) can be used and the decoder should read the actual stream id from
- * the compression control byte (see NOTE 2).
- *
- * If the compression is not used, then the pixel data is sent as is,
- * otherwise the data stream looks like this:
- *
- * 1..3 bytes: data size (N) in compact representation;
- * N bytes: zlib-compressed data.
- *
- * Data size is compactly represented in one, two or three bytes, just like
- * in the "jpeg" compression method (see above).
- *
- *-- NOTE 1. If the color depth is 24, and all three color components are
- * 8-bit wide, then one pixel in Tight encoding is always represented by
- * three bytes, where the first byte is red component, the second byte is
- * green component, and the third byte is blue component of the pixel color
- * value. This applies to colors in palettes as well.
- *
- *-- NOTE 2. The decoder must reset compression streams' states before
- * decoding the rectangle, if some of bits 0,1,2,3 in the compression control
- * byte are set to 1. Note that the decoder must reset zlib streams even if
- * the compression type is "fill" or "jpeg".
- *
- *-- NOTE 3. The "gradient" filter and "jpeg" compression may be used only
- * when bits-per-pixel value is either 16 or 32, not 8.
- *
- *-- NOTE 4. The width of any Tight-encoded rectangle cannot exceed 2048
- * pixels. If a rectangle is wider, it must be split into several rectangles
- * and each one should be encoded separately.
- *
- */
-
-#define rfbTightExplicitFilter 0x04
-#define rfbTightFill 0x08
-#define rfbTightJpeg 0x09
-#define rfbTightMaxSubencoding 0x09
-
-/* Filters to improve compression efficiency */
-#define rfbTightFilterCopy 0x00
-#define rfbTightFilterPalette 0x01
-#define rfbTightFilterGradient 0x02
-
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * XCursor encoding. This is a special encoding used to transmit X-style
- * cursor shapes from server to clients. Note that for this encoding,
- * coordinates in rfbFramebufferUpdateRectHeader structure hold hotspot
- * position (r.x, r.y) and cursor size (r.w, r.h). If (w * h != 0), two RGB
- * samples are sent after header in the rfbXCursorColors structure. They
- * denote foreground and background colors of the cursor. If a client
- * supports only black-and-white cursors, it should ignore these colors and
- * assume that foreground is black and background is white. Next, two bitmaps
- * (1 bits per pixel) follow: first one with actual data (value 0 denotes
- * background color, value 1 denotes foreground color), second one with
- * transparency data (bits with zero value mean that these pixels are
- * transparent). Both bitmaps represent cursor data in a byte stream, from
- * left to right, from top to bottom, and each row is byte-aligned. Most
- * significant bits correspond to leftmost pixels. The number of bytes in
- * each row can be calculated as ((w + 7) / 8). If (w * h == 0), cursor
- * should be hidden (or default local cursor should be set by the client).
- */
-
-typedef struct {
- CARD8 foreRed;
- CARD8 foreGreen;
- CARD8 foreBlue;
- CARD8 backRed;
- CARD8 backGreen;
- CARD8 backBlue;
-} rfbXCursorColors;
-
-#define sz_rfbXCursorColors 6
-
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * RichCursor encoding. This is a special encoding used to transmit cursor
- * shapes from server to clients. It is similar to the XCursor encoding but
- * uses client pixel format instead of two RGB colors to represent cursor
- * image. For this encoding, coordinates in rfbFramebufferUpdateRectHeader
- * structure hold hotspot position (r.x, r.y) and cursor size (r.w, r.h).
- * After header, two pixmaps follow: first one with cursor image in current
- * client pixel format (like in raw encoding), second with transparency data
- * (1 bit per pixel, exactly the same format as used for transparency bitmap
- * in the XCursor encoding). If (w * h == 0), cursor should be hidden (or
- * default local cursor should be set by the client).
- */
-
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * SoftCursor encoding. This encoding is used to transmit image and position
- * of the remote cursor. It has two sub-messages: SetImage is used to upload
- * one of 16 images, and Move selects the image and sets the position of the
- * cursor.
- * Each SoftCursor message starts with a CARD8. If it is in the 0-15 range
- * it specifies the number of the cursor image and is followed by the
- * rfbSoftCursorMove message. If the given cursor has not been set yet the
- * message will be ignored. If the first CARD8 is in the 128-143 range it
- * specifies the cursor that will be set in the following
- * rfbSoftCursorSetImage message. To hide the cursor send a SetImage
- * message with width and height 0 and imageLength 0.
- * SetImage transmits the hotspot coordinates in the x/y fields of the
- * rfbFramebufferUpdateRectHeader, width and height of the image are in the
- * header's width and height fields.
- * Move transmits the pointer coordinates in the w/h fields of the
- * header, x/y are always 0.
- */
-
-typedef struct {
- CARD8 imageIndex;
- CARD8 buttonMask; /* bits 0-7 are buttons 1-8, 0=up, 1=down */
-} rfbSoftCursorMove;
-
-typedef struct {
- CARD8 imageIndex;
- CARD8 padding;
- CARD16 imageLength;
- /*
- * Followed by an image of the cursor in the client's image format
- * with the following RLE mask compression. It begins with CARD8 that
- * specifies the number of mask'ed pixels that will be NOT transmitted.
- * Then follows a CARD8 that specified by the number of unmask'd pixels
- * that will be transmitted next. Then a CARD8 with the number of mask'd
- * pixels and so on.
- */
-} rfbSoftCursorSetImage;
-
-typedef union {
- CARD8 type;
- rfbSoftCursorMove move;
- rfbSoftCursorSetImage setImage;
-} rfbSoftCursorMsg;
-
-#define rfbSoftCursorMaxImages 16
-#define rfbSoftCursorSetIconOffset 128
-
-/*-----------------------------------------------------------------------------
- * SetColourMapEntries - these messages are only sent if the pixel
- * format uses a "colour map" (i.e. trueColour false) and the client has not
- * fixed the entire colour map using FixColourMapEntries. In addition they
- * will only start being sent after the client has sent its first
- * FramebufferUpdateRequest. So if the client always tells the server to use
- * trueColour then it never needs to process this type of message.
- */
-
-typedef struct {
- CARD8 type; /* always rfbSetColourMapEntries */
- CARD8 pad;
- CARD16 firstColour;
- CARD16 nColours;
-
- /* Followed by nColours * 3 * CARD16
- r1, g1, b1, r2, g2, b2, r3, g3, b3, ..., rn, bn, gn */
-
-} rfbSetColourMapEntriesMsg;
-
-#define sz_rfbSetColourMapEntriesMsg 6
-
-
-
-/*-----------------------------------------------------------------------------
- * Bell - ring a bell on the client if it has one.
- */
-
-typedef struct {
- CARD8 type; /* always rfbBell */
-} rfbBellMsg;
-
-#define sz_rfbBellMsg 1
-
-
-
-/*-----------------------------------------------------------------------------
- * ServerCutText - the server has new text in its cut buffer.
- */
-
-typedef struct {
- CARD8 type; /* always rfbServerCutText */
- CARD8 pad1;
- CARD16 pad2;
- CARD32 length;
- /* followed by char text[length] */
-} rfbServerCutTextMsg;
-
-#define sz_rfbServerCutTextMsg 8
-
-
-/*-----------------------------------------------------------------------------
- * Union of all server->client messages.
- */
-
-typedef union {
- CARD8 type;
- rfbFramebufferUpdateMsg fu;
- rfbSetColourMapEntriesMsg scme;
- rfbBellMsg b;
- rfbServerCutTextMsg sct;
-} rfbServerToClientMsg;
-
-
-
-/*****************************************************************************
- *
- * Message definitions (client -> server)
- *
- *****************************************************************************/
-
-
-/*-----------------------------------------------------------------------------
- * SetPixelFormat - tell the RFB server the format in which the client wants
- * pixels sent.
- */
-
-typedef struct {
- CARD8 type; /* always rfbSetPixelFormat */
- CARD8 pad1;
- CARD16 pad2;
- rfbPixelFormat format;
-} rfbSetPixelFormatMsg;
-
-#define sz_rfbSetPixelFormatMsg (sz_rfbPixelFormat + 4)
-
-
-/*-----------------------------------------------------------------------------
- * FixColourMapEntries - when the pixel format uses a "colour map", fix
- * read-only colour map entries.
- *
- * ***************** NOT CURRENTLY SUPPORTED *****************
- */
-
-typedef struct {
- CARD8 type; /* always rfbFixColourMapEntries */
- CARD8 pad;
- CARD16 firstColour;
- CARD16 nColours;
-
- /* Followed by nColours * 3 * CARD16
- r1, g1, b1, r2, g2, b2, r3, g3, b3, ..., rn, bn, gn */
-
-} rfbFixColourMapEntriesMsg;
-
-#define sz_rfbFixColourMapEntriesMsg 6
-
-
-/*-----------------------------------------------------------------------------
- * SetEncodings - tell the RFB server which encoding types we accept. Put them
- * in order of preference, if we have any. We may always receive raw
- * encoding, even if we don't specify it here.
- */
-
-typedef struct {
- CARD8 type; /* always rfbSetEncodings */
- CARD8 pad;
- CARD16 nEncodings;
- /* followed by nEncodings * CARD32 encoding types */
-} rfbSetEncodingsMsg;
-
-#define sz_rfbSetEncodingsMsg 4
-
-
-/*-----------------------------------------------------------------------------
- * FramebufferUpdateRequest - request for a framebuffer update. If incremental
- * is true then the client just wants the changes since the last update. If
- * false then it wants the whole of the specified rectangle.
- */
-
-typedef struct {
- CARD8 type; /* always rfbFramebufferUpdateRequest */
- CARD8 incremental;
- CARD16 x;
- CARD16 y;
- CARD16 w;
- CARD16 h;
-} rfbFramebufferUpdateRequestMsg;
-
-#define sz_rfbFramebufferUpdateRequestMsg 10
-
-
-/*-----------------------------------------------------------------------------
- * KeyEvent - key press or release
- *
- * Keys are specified using the "keysym" values defined by the X Window System.
- * For most ordinary keys, the keysym is the same as the corresponding ASCII
- * value. Other common keys are:
- *
- * BackSpace 0xff08
- * Tab 0xff09
- * Return or Enter 0xff0d
- * Escape 0xff1b
- * Insert 0xff63
- * Delete 0xffff
- * Home 0xff50
- * End 0xff57
- * Page Up 0xff55
- * Page Down 0xff56
- * Left 0xff51
- * Up 0xff52
- * Right 0xff53
- * Down 0xff54
- * F1 0xffbe
- * F2 0xffbf
- * ... ...
- * F12 0xffc9
- * Shift 0xffe1
- * Control 0xffe3
- * Meta 0xffe7
- * Alt 0xffe9
- */
-
-typedef struct {
- CARD8 type; /* always rfbKeyEvent */
- CARD8 down; /* true if down (press), false if up */
- CARD16 pad;
- CARD32 key; /* key is specified as an X keysym */
-} rfbKeyEventMsg;
-
-#define sz_rfbKeyEventMsg 8
-
-
-/*-----------------------------------------------------------------------------
- * PointerEvent - mouse/pen move and/or button press.
- */
-
-typedef struct {
- CARD8 type; /* always rfbPointerEvent */
- CARD8 buttonMask; /* bits 0-7 are buttons 1-8, 0=up, 1=down */
- CARD16 x;
- CARD16 y;
-} rfbPointerEventMsg;
-
-#define rfbButton1Mask 1
-#define rfbButton2Mask 2
-#define rfbButton3Mask 4
-
-#define sz_rfbPointerEventMsg 6
-
-
-
-/*-----------------------------------------------------------------------------
- * ClientCutText - the client has new text in its cut buffer.
- */
-
-typedef struct {
- CARD8 type; /* always rfbClientCutText */
- CARD8 pad1;
- CARD16 pad2;
- CARD32 length;
- /* followed by char text[length] */
-} rfbClientCutTextMsg;
-
-#define sz_rfbClientCutTextMsg 8
-
-
-
-/*-----------------------------------------------------------------------------
- * Union of all client->server messages.
- */
-
-typedef union {
- CARD8 type;
- rfbSetPixelFormatMsg spf;
- rfbFixColourMapEntriesMsg fcme;
- rfbSetEncodingsMsg se;
- rfbFramebufferUpdateRequestMsg fur;
- rfbKeyEventMsg ke;
- rfbPointerEventMsg pe;
- rfbClientCutTextMsg cct;
-} rfbClientToServerMsg;