+++ /dev/null
-#ifndef RFBPROTO_H
-#define RFBPROTO_H
-
-/*
- * Copyright (C) 2005 Rohit Kumar, Johannes E. Schindelin
- * 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., 59 Temple Place - Suite 330, Boston, MA 02111-1307,
- * 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.
- */
-
-
-#if defined(WIN32) && !defined(__MINGW32__)
-#define LIBVNCSERVER_WORDS_BIGENDIAN
-#define rfbBool int
-#include <sys/timeb.h>
-#include <winsock.h>
-#undef SOCKET
-#define SOCKET int
-#else
-#include <rfb/rfbconfig.h>
-#include <rfb/rfbint.h>
-#endif
-
-#ifdef LIBVNCSERVER_HAVE_LIBZ
-#include <zlib.h>
-#ifdef __CHECKER__
-#undef Z_NULL
-#define Z_NULL NULL
-#endif
-#endif
-
-
-#if !defined(WIN32) || defined(__MINGW32__)
-#define max(a,b) (((a)>(b))?(a):(b))
-#ifdef LIBVNCSERVER_HAVE_SYS_TIME_H
-#include <sys/time.h>
-#endif
-#ifdef LIBVNCSERVER_HAVE_NETINET_IN_H
-#include <netinet/in.h>
-#endif
-#define SOCKET int
-typedef int8_t rfbBool;
-#undef FALSE
-#define FALSE 0
-#undef TRUE
-#define TRUE -1
-#endif
-
-typedef uint32_t rfbKeySym;
-typedef uint32_t rfbPixel;
-
-#ifdef LIBVNCSERVER_NEED_INADDR_T
-typedef uint32_t in_addr_t;
-#endif
-
-#ifndef INADDR_NONE
-#define INADDR_NONE ((in_addr_t) 0xffffffff)
-#endif
-
-#define MAX_ENCODINGS 20
-
-/*****************************************************************************
- *
- * 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 {
- uint16_t x;
- uint16_t y;
- uint16_t w;
- uint16_t h;
-} rfbRectangle;
-
-#define sz_rfbRectangle 8
-
-
-/*-----------------------------------------------------------------------------
- * Structure used to specify pixel format.
- */
-
-typedef struct {
-
- uint8_t bitsPerPixel; /* 8,16,32 only */
-
- uint8_t depth; /* 8 to 32 */
-
- uint8_t 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 */
-
- uint8_t 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 */
-
- uint16_t 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. */
-
- uint16_t greenMax; /* similar for green */
-
- uint16_t blueMax; /* and blue */
-
- uint8_t 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. */
-
- uint8_t greenShift; /* similar for green */
-
- uint8_t blueShift; /* and blue */
-
- uint8_t pad1;
- uint16_t pad2;
-
-} rfbPixelFormat;
-
-#define sz_rfbPixelFormat 16
-
-/* UltraVNC: Color settings values */
-#define rfbPFFullColors 0
-#define rfbPF256Colors 1
-#define rfbPF64Colors 2
-#define rfbPF8Colors 3
-#define rfbPF8GreyColors 4
-#define rfbPF4GreyColors 5
-#define rfbPF2GreyColors 6
-
-
-/*****************************************************************************
- *
- * 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 8
-/* UltraVNC Viewer examines rfbProtocolMinorVersion number (4, and 6)
- * to identify if the server supports File Transfer
- */
-
-typedef char rfbProtocolVersionMsg[13]; /* allow extra byte for null */
-
-#define sz_rfbProtocolVersionMsg 12
-
-/*
- * Negotiation of the security type (protocol version 3.7)
- *
- * Once the protocol version has been decided, the server either sends a list
- * of supported security types, or informs the client about an error (when the
- * number of security types is 0). Security type rfbSecTypeTight is used to
- * enable TightVNC-specific protocol extensions. The value rfbSecTypeVncAuth
- * stands for classic VNC authentication.
- *
- * The client selects a particular security type from the list provided by the
- * server.
- */
-
-#define rfbSecTypeInvalid 0
-#define rfbSecTypeNone 1
-#define rfbSecTypeVncAuth 2
-
-
-/*-----------------------------------------------------------------------------
- * 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
-
-#define rfbRA2 5
-#define rfbRA2ne 6
-#define rfbSSPI 7
-#define rfbSSPIne 8
-#define rfbTight 16
-#define rfbUltra 17
-#define rfbTLS 18
-
-/*
- * 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 {
- uint8_t 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 {
- uint16_t framebufferWidth;
- uint16_t framebufferHeight;
- rfbPixelFormat format; /* the server's preferred pixel format */
- uint32_t 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
-/* Modif sf@2002 */
-#define rfbResizeFrameBuffer 4
-#define rfbKeyFrameUpdate 5
-#define rfbPalmVNCReSizeFrameBuffer 0xF
-
-/* 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
-/* Modif sf@2002 - actually bidirectionnal */
-#define rfbFileTransfer 7
-/* Modif sf@2002 */
-#define rfbSetScale 8
-/* Modif rdv@2002 */
-#define rfbSetServerInput 9
-/* Modif rdv@2002 */
-#define rfbSetSW 10
-/* Modif sf@2002 - TextChat - Bidirectionnal */
-#define rfbTextChat 11
-/* Modif cs@2005 */
-#define rfbKeyFrameRequest 12
-/* PalmVNC 1.4 & 2.0 SetScale Factor message */
-#define rfbPalmVNCSetScaleFactor 0xF
-
-
-
-
-/*****************************************************************************
- *
- * 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
-#define rfbEncodingUltra 9
-#define rfbEncodingZRLE 16
-#define rfbEncodingZYWRLE 17
-
-/* Cache & XOR-Zlib - rdv@2002 */
-#define rfbEncodingCache 0xFFFF0000
-#define rfbEncodingCacheEnable 0xFFFF0001
-#define rfbEncodingXOR_Zlib 0xFFFF0002
-#define rfbEncodingXORMonoColor_Zlib 0xFFFF0003
-#define rfbEncodingXORMultiColor_Zlib 0xFFFF0004
-#define rfbEncodingSolidColor 0xFFFF0005
-#define rfbEncodingXOREnable 0xFFFF0006
-#define rfbEncodingCacheZip 0xFFFF0007
-#define rfbEncodingSolMonoZip 0xFFFF0008
-#define rfbEncodingUltraZip 0xFFFF0009
-
-/*
- * 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.
- */
-
-#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 rfbEncodingPointerPos 0xFFFFFF18
-
-#define rfbEncodingLastRect 0xFFFFFF20
-#define rfbEncodingNewFBSize 0xFFFFFF21
-
-#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
-
-
-/* LibVNCServer additions. We claim 0xFFFE0000 - 0xFFFE00FF */
-#define rfbEncodingKeyboardLedState 0xFFFE0000
-#define rfbEncodingSupportedMessages 0xFFFE0001
-#define rfbEncodingSupportedEncodings 0xFFFE0002
-#define rfbEncodingServerIdentity 0xFFFE0003
-
-
-/*****************************************************************************
- *
- * 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 {
- uint8_t type; /* always rfbFramebufferUpdate */
- uint8_t pad;
- uint16_t nRects;
- /* followed by nRects rectangles */
-} rfbFramebufferUpdateMsg;
-
-#define sz_rfbFramebufferUpdateMsg 4
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * KeyFrameUpdate - Acknowledgment of a key frame request, it tells the client
- * that the next update received will be a key frame.
- */
-
-typedef struct {
- uint8_t type;
-} rfbKeyFrameUpdateMsg;
-
-#define sz_rfbKeyFrameUpdateMsg 1
-
-
-/*
- * 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;
- uint32_t encoding; /* one of the encoding types rfbEncoding... */
-} rfbFramebufferUpdateRectHeader;
-
-#define sz_rfbFramebufferUpdateRectHeader (sz_rfbRectangle + 4)
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * Supported Messages Encoding. This encoding does not contain any pixel data.
- * Instead, it contains 2 sets of bitflags. These bitflags indicate what messages
- * are supported by the server.
- * rect->w contains byte count
- */
-
-typedef struct {
- uint8_t client2server[32]; /* maximum of 256 message types (256/8)=32 */
- uint8_t server2client[32]; /* maximum of 256 message types (256/8)=32 */
-} rfbSupportedMessages;
-
-#define sz_rfbSupportedMessages 64
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * Supported Encodings Encoding. This encoding does not contain any pixel data.
- * Instead, it contains a list of (uint32_t) Encodings supported by this server.
- * rect->w contains byte count
- * rect->h contains encoding count
- */
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * Server Identity Encoding. This encoding does not contain any pixel data.
- * Instead, it contains a text string containing information about the server.
- * ie: "x11vnc: 0.8.1 lastmod: 2006-04-25 (libvncserver 0.9pre)\0"
- * rect->w contains byte count
- */
-
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * Raw Encoding. Pixels are sent in top-to-bottom scanline order,
- * left-to-right within a scanline with no padding in between.
- */
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * KeyboardLedState Encoding. The X coordinate contains the Locked Modifiers
- * so that a remote troubleshooter can identify that the users 'Caps Lock'
- * is set... (It helps a *lot* when the users are untrained)
- */
-#define rfbKeyboardMaskShift 1
-#define rfbKeyboardMaskCapsLock 2
-#define rfbKeyboardMaskControl 4
-#define rfbKeyboardMaskAlt 8
-#define rfbKeyboardMaskMeta 16
-#define rfbKeyboardMaskSuper 32
-#define rfbKeyboardMaskHyper 64
-#define rfbKeyboardMaskNumLock 128
-#define rfbKeyboardMaskScrollLock 256
-#define rfbKeyboardMaskAltGraph 512
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * CopyRect Encoding. The pixels are specified simply by the x and y position
- * of the source rectangle.
- */
-
-typedef struct {
- uint16_t srcX;
- uint16_t 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 {
- uint32_t 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 {
- uint8_t x;
- uint8_t y;
- uint8_t w;
- uint8_t 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.
- * (NOTE: also used by Ultra Encoding)
- */
-
-typedef struct {
- uint32_t nBytes;
-} rfbZlibHeader;
-
-#define sz_rfbZlibHeader 4
-
-#ifdef LIBVNCSERVER_HAVE_LIBZ
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * 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
-
-#endif
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * 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 {
- uint8_t foreRed;
- uint8_t foreGreen;
- uint8_t foreBlue;
- uint8_t backRed;
- uint8_t backGreen;
- uint8_t 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).
- */
-
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * ZRLE - encoding combining Zlib compression, tiling, palettisation and
- * run-length encoding.
- */
-
-typedef struct {
- uint32_t length;
-} rfbZRLEHeader;
-
-#define sz_rfbZRLEHeader 4
-
-#define rfbZRLETileWidth 64
-#define rfbZRLETileHeight 64
-
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * ZLIBHEX - zlib compressed Hextile Encoding. Essentially, this is the
- * hextile encoding with zlib compression on the tiles that can not be
- * efficiently encoded with one of the other hextile subencodings. The
- * new zlib subencoding uses two bytes to specify the length of the
- * compressed tile and then the compressed data follows. As with the
- * raw sub-encoding, the zlib subencoding invalidates the other
- * values, if they are also set.
- */
-
-#define rfbHextileZlibRaw (1 << 5)
-#define rfbHextileZlibHex (1 << 6)
-#define rfbHextileZlibMono (1 << 7)
-
-
-/*-----------------------------------------------------------------------------
- * 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 {
- uint8_t type; /* always rfbSetColourMapEntries */
- uint8_t pad;
- uint16_t firstColour;
- uint16_t nColours;
-
- /* Followed by nColours * 3 * uint16_t
- 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 {
- uint8_t type; /* always rfbBell */
-} rfbBellMsg;
-
-#define sz_rfbBellMsg 1
-
-
-
-/*-----------------------------------------------------------------------------
- * ServerCutText - the server has new text in its cut buffer.
- */
-
-typedef struct {
- uint8_t type; /* always rfbServerCutText */
- uint8_t pad1;
- uint16_t pad2;
- uint32_t length;
- /* followed by char text[length] */
-} rfbServerCutTextMsg;
-
-#define sz_rfbServerCutTextMsg 8
-
-
-/*-----------------------------------------------------------------------------
- * // Modif sf@2002
- * FileTransferMsg - The client sends FileTransfer message.
- * Bidirectional message - Files can be sent from client to server & vice versa
- */
-
-typedef struct _rfbFileTransferMsg {
- uint8_t type; /* always rfbFileTransfer */
- uint8_t contentType; /* See defines below */
- uint8_t contentParam;/* Other possible content classification (Dir or File name, etc..) */
- uint8_t pad; /* It appears that UltraVNC *forgot* to Swap16IfLE(contentParam) */
- uint32_t size; /* FileSize or packet index or error or other */
-/* uint32_t sizeH; Additional 32Bits params to handle big values. Only for V2 (we want backward compatibility between all V1 versions) */
- uint32_t length;
- /* followed by data char text[length] */
-} rfbFileTransferMsg;
-
-#define sz_rfbFileTransferMsg 12
-
-#define rfbFileTransferVersion 2 /* v1 is the old FT version ( <= 1.0.0 RC18 versions) */
-
-/* FileTransfer Content types and Params defines */
-#define rfbDirContentRequest 1 /* Client asks for the content of a given Server directory */
-#define rfbDirPacket 2 /* Full directory name or full file name. */
- /* Null content means end of Directory */
-#define rfbFileTransferRequest 3 /* Client asks the server for the transfer of a given file */
-#define rfbFileHeader 4 /* First packet of a file transfer, containing file's features */
-#define rfbFilePacket 5 /* One chunk of the file */
-#define rfbEndOfFile 6 /* End of file transfer (the file has been received or error) */
-#define rfbAbortFileTransfer 7 /* The file transfer must be aborted, whatever the state */
-#define rfbFileTransferOffer 8 /* The client offers to send a file to the server */
-#define rfbFileAcceptHeader 9 /* The server accepts or rejects the file */
-#define rfbCommand 10 /* The Client sends a simple command (File Delete, Dir create etc...) */
-#define rfbCommandReturn 11 /* The Client receives the server's answer about a simple command */
-#define rfbFileChecksums 12 /* The zipped checksums of the destination file (Delta Transfer) */
-#define rfbFileTransferAccess 14 /* Request FileTransfer authorization */
-
- /* rfbDirContentRequest client Request - content params */
-#define rfbRDirContent 1 /* Request a Server Directory contents */
-#define rfbRDrivesList 2 /* Request the server's drives list */
-#define rfbRDirRecursiveList 3 /* Request a server directory content recursive sorted list */
-#define rfbRDirRecursiveSize 4 /* Request a server directory content recursive size */
-
- /* rfbDirPacket & rfbCommandReturn server Answer - content params */
-#define rfbADirectory 1 /* Reception of a directory name */
-#define rfbAFile 2 /* Reception of a file name */
-#define rfbADrivesList 3 /* Reception of a list of drives */
-#define rfbADirCreate 4 /* Response to a create dir command */
-#define rfbADirDelete 5 /* Response to a delete dir command */
-#define rfbAFileCreate 6 /* Response to a create file command */
-#define rfbAFileDelete 7 /* Response to a delete file command */
-#define rfbAFileRename 8 /* Response to a rename file command */
-#define rfbADirRename 9 /* Response to a rename dir command */
-#define rfbADirRecursiveListItem 10
-#define rfbADirRecursiveSize 11
-
- /* rfbCommand Command - content params */
-#define rfbCDirCreate 1 /* Request the server to create the given directory */
-#define rfbCDirDelete 2 /* Request the server to delete the given directory */
-#define rfbCFileCreate 3 /* Request the server to create the given file */
-#define rfbCFileDelete 4 /* Request the server to delete the given file */
-#define rfbCFileRename 5 /* Request the server to rename the given file */
-#define rfbCDirRename 6 /* Request the server to rename the given directory */
-
- /* Errors - content params or "size" field */
-#define rfbRErrorUnknownCmd 1 /* Unknown FileTransfer command. */
-#define rfbRErrorCmd 0xFFFFFFFF/* Error when a command fails on remote side (ret in "size" field) */
-
-#define sz_rfbBlockSize 8192 /* Size of a File Transfer packet (before compression) */
-#define rfbZipDirectoryPrefix "!UVNCDIR-\0" /* Transfered directory are zipped in a file with this prefix. Must end with "-" */
-#define sz_rfbZipDirectoryPrefix 9
-#define rfbDirPrefix "[ "
-#define rfbDirSuffix " ]"
-
-
-
-/*-----------------------------------------------------------------------------
- * Modif sf@2002
- * TextChatMsg - Utilized to order the TextChat mode on server or client
- * Bidirectional message
- */
-
-typedef struct _rfbTextChatMsg {
- uint8_t type; /* always rfbTextChat */
- uint8_t pad1; /* Could be used later as an additionnal param */
- uint16_t pad2; /* Could be used later as text offset, for instance */
- uint32_t length; /* Specific values for Open, close, finished (-1, -2, -3) */
- /* followed by char text[length] */
-} rfbTextChatMsg;
-
-#define sz_rfbTextChatMsg 8
-
-#define rfbTextMaxSize 4096
-#define rfbTextChatOpen 0xFFFFFFFF
-#define rfbTextChatClose 0xFFFFFFFE
-#define rfbTextChatFinished 0xFFFFFFFD
-
-
-
-/*-----------------------------------------------------------------------------
- * Modif sf@2002
- * ResizeFrameBuffer - The Client must change the size of its framebuffer
- */
-
-typedef struct _rfbResizeFrameBufferMsg {
- uint8_t type; /* always rfbResizeFrameBuffer */
- uint8_t pad1;
- uint16_t framebufferWidth; /* FrameBuffer width */
- uint16_t framebufferHeigth; /* FrameBuffer height */
-} rfbResizeFrameBufferMsg;
-
-#define sz_rfbResizeFrameBufferMsg 6
-
-
-/*-----------------------------------------------------------------------------
- * Copyright (C) 2001 Harakan Software
- * PalmVNC 1.4 & 2.? ResizeFrameBuffer message
- * ReSizeFrameBuffer - tell the RFB client to alter its framebuffer, either
- * due to a resize of the server desktop or a client-requested scaling factor.
- * The pixel format remains unchanged.
- */
-
-typedef struct {
- uint8_t type; /* always rfbReSizeFrameBuffer */
- uint8_t pad1;
- uint16_t desktop_w; /* Desktop width */
- uint16_t desktop_h; /* Desktop height */
- uint16_t buffer_w; /* FrameBuffer width */
- uint16_t buffer_h; /* Framebuffer height */
- uint16_t pad2;
-
-} rfbPalmVNCReSizeFrameBufferMsg;
-
-#define sz_rfbPalmVNCReSizeFrameBufferMsg (12)
-
-
-
-
-/*-----------------------------------------------------------------------------
- * Union of all server->client messages.
- */
-
-typedef union {
- uint8_t type;
- rfbFramebufferUpdateMsg fu;
- rfbSetColourMapEntriesMsg scme;
- rfbBellMsg b;
- rfbServerCutTextMsg sct;
- rfbResizeFrameBufferMsg rsfb;
- rfbPalmVNCReSizeFrameBufferMsg prsfb;
- rfbFileTransferMsg ft;
- rfbTextChatMsg tc;
-} rfbServerToClientMsg;
-
-
-
-/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- * RDV Cache Encoding.
- * special is not used at this point, can be used to reset cache or other specials
- * just put it to make sure we don't have to change the encoding again.
- */
-
-typedef struct {
- uint16_t special;
-} rfbCacheRect;
-
-#define sz_rfbCacheRect 2
-
-
-
-
-/*****************************************************************************
- *
- * Message definitions (client -> server)
- *
- *****************************************************************************/
-
-
-/*-----------------------------------------------------------------------------
- * SetPixelFormat - tell the RFB server the format in which the client wants
- * pixels sent.
- */
-
-typedef struct {
- uint8_t type; /* always rfbSetPixelFormat */
- uint8_t pad1;
- uint16_t 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 {
- uint8_t type; /* always rfbFixColourMapEntries */
- uint8_t pad;
- uint16_t firstColour;
- uint16_t nColours;
-
- /* Followed by nColours * 3 * uint16_t
- 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 {
- uint8_t type; /* always rfbSetEncodings */
- uint8_t pad;
- uint16_t nEncodings;
- /* followed by nEncodings * uint32_t 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 {
- uint8_t type; /* always rfbFramebufferUpdateRequest */
- uint8_t incremental;
- uint16_t x;
- uint16_t y;
- uint16_t w;
- uint16_t 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 {
- uint8_t type; /* always rfbKeyEvent */
- uint8_t down; /* true if down (press), false if up */
- uint16_t pad;
- uint32_t key; /* key is specified as an X keysym */
-} rfbKeyEventMsg;
-
-#define sz_rfbKeyEventMsg 8
-
-
-/*-----------------------------------------------------------------------------
- * PointerEvent - mouse/pen move and/or button press.
- */
-
-typedef struct {
- uint8_t type; /* always rfbPointerEvent */
- uint8_t buttonMask; /* bits 0-7 are buttons 1-8, 0=up, 1=down */
- uint16_t x;
- uint16_t y;
-} rfbPointerEventMsg;
-
-#define rfbButton1Mask 1
-#define rfbButton2Mask 2
-#define rfbButton3Mask 4
-#define rfbButton4Mask 8
-#define rfbButton5Mask 16
-/* RealVNC 335 method */
-#define rfbWheelUpMask rfbButton4Mask
-#define rfbWheelDownMask rfbButton5Mask
-
-#define sz_rfbPointerEventMsg 6
-
-
-
-/*-----------------------------------------------------------------------------
- * ClientCutText - the client has new text in its cut buffer.
- */
-
-typedef struct {
- uint8_t type; /* always rfbClientCutText */
- uint8_t pad1;
- uint16_t pad2;
- uint32_t length;
- /* followed by char text[length] */
-} rfbClientCutTextMsg;
-
-#define sz_rfbClientCutTextMsg 8
-
-
-
-/*-----------------------------------------------------------------------------
- * sf@2002 - Set Server Scale
- * SetServerScale - Server must change the scale of the client buffer.
- */
-
-typedef struct _rfbSetScaleMsg {
- uint8_t type; /* always rfbSetScale */
- uint8_t scale; /* Scale value 1<sv<n */
- uint16_t pad;
-} rfbSetScaleMsg;
-
-#define sz_rfbSetScaleMsg 4
-
-
-/*-----------------------------------------------------------------------------
- * Copyright (C) 2001 Harakan Software
- * PalmVNC 1.4 & 2.? SetScale Factor message
- * SetScaleFactor - tell the RFB server to alter the scale factor for the
- * client buffer.
- */
-typedef struct {
- uint8_t type; /* always rfbPalmVNCSetScaleFactor */
-
- uint8_t scale; /* Scale factor (positive non-zero integer) */
- uint16_t pad2;
-} rfbPalmVNCSetScaleFactorMsg;
-
-#define sz_rfbPalmVNCSetScaleFactorMsg (4)
-
-
-/*-----------------------------------------------------------------------------
- * rdv@2002 - Set input status
- * SetServerInput - Server input is dis/enabled
- */
-
-typedef struct _rfbSetServerInputMsg {
- uint8_t type; /* always rfbSetScale */
- uint8_t status; /* Scale value 1<sv<n */
- uint16_t pad;
-} rfbSetServerInputMsg;
-
-#define sz_rfbSetServerInputMsg 4
-
-/*-----------------------------------------------------------------------------
- * rdv@2002 - Set SW
- * SetSW - Server SW/full desktop
- */
-
-typedef struct _rfbSetSWMsg {
- uint8_t type; /* always rfbSetSW */
- uint8_t status;
- uint16_t x;
- uint16_t y;
-} rfbSetSWMsg;
-
-#define sz_rfbSetSWMsg 6
-
-
-/*-----------------------------------------------------------------------------
- * Union of all client->server messages.
- */
-
-typedef union {
- uint8_t type;
- rfbSetPixelFormatMsg spf;
- rfbFixColourMapEntriesMsg fcme;
- rfbSetEncodingsMsg se;
- rfbFramebufferUpdateRequestMsg fur;
- rfbKeyEventMsg ke;
- rfbPointerEventMsg pe;
- rfbClientCutTextMsg cct;
- rfbSetScaleMsg ssc;
- rfbPalmVNCSetScaleFactorMsg pssf;
- rfbSetServerInputMsg sim;
- rfbFileTransferMsg ft;
- rfbSetSWMsg sw;
- rfbTextChatMsg tc;
-} rfbClientToServerMsg;
-
-/*
- * vncauth.h - describes the functions provided by the vncauth library.
- */
-
-#define MAXPWLEN 8
-#define CHALLENGESIZE 16
-
-extern int rfbEncryptAndStorePasswd(char *passwd, char *fname);
-extern char *rfbDecryptPasswdFromFile(char *fname);
-extern void rfbRandomBytes(unsigned char *bytes);
-extern void rfbEncryptBytes(unsigned char *bytes, char *passwd);
-
-
-#endif
projects / presencevnc / blobdiff