acid-drop

- Hacking the planet from a LilyGo T-Deck using custom firmware
git clone git://git.acid.vegas/acid-drop.git
Log | Files | Refs | Archive | README | LICENSE

rfbproto.h (56851B)

      1 /*
      2  *  Copyright (C) 2009-2010, 2012 D. R. Commander. All Rights Reserved.
      3  *  Copyright (C) 2004-2008 Sun Microsystems, Inc. All Rights Reserved.
      4  *  Copyright (C) 2004 Landmark Graphics Corporation. All Rights Reserved.
      5  *  Copyright (C) 2000-2006 Constantin Kaplinsky. All Rights Reserved.
      6  *  Copyright (C) 2000 Tridia Corporation. All Rights Reserved.
      7  *  Copyright (C) 1999 AT&T Laboratories Cambridge. All Rights Reserved.
      8  *
      9  *  This is free software; you can redistribute it and/or modify
     10  *  it under the terms of the GNU General Public License as published by
     11  *  the Free Software Foundation; either version 2 of the License, or
     12  *  (at your option) any later version.
     13  *
     14  *  This software is distributed in the hope that it will be useful,
     15  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
     16  *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
     17  *  GNU General Public License for more details.
     18  *
     19  *  You should have received a copy of the GNU General Public License
     20  *  along with this software; if not, write to the Free Software
     21  *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301,
     22  *  USA.
     23  */
     24 
     25 /*
     26  * rfbproto.h - header file for the RFB protocol, versions 3.3, 3.7 and 3.7t,
     27  * 3.8 and 3.8t ("t" suffix denotes TightVNC protocol extensions enabled)
     28  *
     29  * Uses types CARD<n> for an n-bit unsigned integer, INT<n> for an n-bit signed
     30  * integer (for n = 8, 16 and 32).
     31  *
     32  * All multiple byte integers are in big endian (network) order (most
     33  * significant byte first).  Unless noted otherwise there is no special
     34  * alignment of protocol structures.
     35  *
     36  *
     37  * Once the initial handshaking is done, all messages start with a type byte,
     38  * (usually) followed by message-specific data.  The order of definitions in
     39  * this file is as follows:
     40  *
     41  *  (1) Structures used in several types of message.
     42  *  (2) Structures used in the initial handshaking.
     43  *  (3) Message types.
     44  *  (4) Encoding types.
     45  *  (5) For each message type, the form of the data following the type byte.
     46  *      Sometimes this is defined by a single structure but the more complex
     47  *      messages have to be explained by comments.
     48  */
     49 
     50 /*****************************************************************************
     51  *
     52  * Structures used in several messages
     53  *
     54  *****************************************************************************/
     55 
     56 /*-----------------------------------------------------------------------------
     57  * Structure used to specify a rectangle.  This structure is a multiple of 4
     58  * bytes so that it can be interspersed with 32-bit pixel data without
     59  * affecting alignment.
     60  */
     61 
     62 typedef struct _rfbRectangle
     63 {
     64     CARD16 x;
     65     CARD16 y;
     66     CARD16 w;
     67     CARD16 h;
     68 } rfbRectangle;
     69 
     70 #define sz_rfbRectangle 8
     71 
     72 /*-----------------------------------------------------------------------------
     73  * Structure used to specify pixel format.
     74  */
     75 
     76 typedef struct _rfbPixelFormat
     77 {
     78 
     79     CARD8 bitsPerPixel; /* 8,16,32 only */
     80 
     81     CARD8 depth; /* 8 to 32 */
     82 
     83     CARD8 bigEndian; /* True if multi-byte pixels are interpreted
     84             as big endian, or if single-bit-per-pixel
     85             has most significant bit of the byte
     86             corresponding to first (leftmost) pixel. Of
     87             course this is meaningless for 8 bits/pix */
     88 
     89     CARD8 trueColour; /* If false then we need a "colour map" to
     90              convert pixels to RGB.  If true, xxxMax and
     91              xxxShift specify bits used for red, green
     92              and blue */
     93 
     94     /* the following fields are only meaningful if trueColour is true */
     95 
     96     CARD16 redMax; /* maximum red value (= 2^n - 1 where n is the
     97               number of bits used for red). Note this
     98               value is always in big endian order. */
     99 
    100     CARD16 greenMax; /* similar for green */
    101 
    102     CARD16 blueMax; /* and blue */
    103 
    104     CARD8 redShift; /* number of shifts needed to get the red
    105                value in a pixel to the least significant
    106                bit. To find the red value from a given
    107                pixel, do the following:
    108                1) Swap pixel value according to bigEndian
    109                   (e.g. if bigEndian is false and host byte
    110                   order is big endian, then swap).
    111                2) Shift right by redShift.
    112                3) AND with redMax (in host byte order).
    113                4) You now have the red value between 0 and
    114                   redMax. */
    115 
    116     CARD8 greenShift; /* similar for green */
    117 
    118     CARD8 blueShift; /* and blue */
    119 
    120     CARD8 pad1;
    121     CARD16 pad2;
    122 
    123 } rfbPixelFormat;
    124 
    125 #define sz_rfbPixelFormat 16
    126 
    127 /*-----------------------------------------------------------------------------
    128  * Structure used to describe protocol options such as tunneling methods,
    129  * authentication schemes and message types (protocol versions 3.7t, 3.8t).
    130  */
    131 
    132 typedef struct _rfbCapabilityInfo
    133 {
    134 
    135     CARD32 code;              /* numeric identifier */
    136     CARD8 vendorSignature[4]; /* vendor identification */
    137     CARD8 nameSignature[8];   /* abbreviated option name */
    138 
    139 } rfbCapabilityInfo;
    140 
    141 #define sz_rfbCapabilityInfoVendor 4
    142 #define sz_rfbCapabilityInfoName 8
    143 #define sz_rfbCapabilityInfo 16
    144 
    145 /*
    146  * Vendors known by TightVNC: standard VNC/RealVNC, TridiaVNC, and TightVNC.
    147  */
    148 
    149 #define rfbStandardVendor "STDV"
    150 #define rfbTridiaVncVendor "TRDV"
    151 #define rfbTightVncVendor "TGHT"
    152 
    153 /*****************************************************************************
    154  *
    155  * Initial handshaking messages
    156  *
    157  *****************************************************************************/
    158 
    159 /*-----------------------------------------------------------------------------
    160  * Protocol Version
    161  *
    162  * The server always sends 12 bytes to start which identifies the latest RFB
    163  * protocol version number which it supports.  These bytes are interpreted
    164  * as a string of 12 ASCII characters in the format "RFB xxx.yyy\n" where
    165  * xxx and yyy are the major and minor version numbers (e.g. for version 3.8
    166  * this is "RFB 003.008\n").
    167  *
    168  * The client then replies with a similar 12-byte message giving the version
    169  * number of the protocol which should actually be used (which may be different
    170  * to that quoted by the server).
    171  *
    172  * It is intended that both clients and servers may provide some level of
    173  * backwards compatibility by this mechanism.  Servers in particular should
    174  * attempt to provide backwards compatibility, and even forwards compatibility
    175  * to some extent.  For example if a client demands version 3.1 of the
    176  * protocol, a 3.0 server can probably assume that by ignoring requests for
    177  * encoding types it doesn't understand, everything will still work OK.  This
    178  * will probably not be the case for changes in the major version number.
    179  *
    180  * The format string below can be used in sprintf or sscanf to generate or
    181  * decode the version string respectively.
    182  */
    183 
    184 #define rfbProtocolVersionFormat "RFB %03d.%03d\n"
    185 #define rfbProtocolMajorVersion 3
    186 #define rfbProtocolMinorVersion 8
    187 
    188 typedef char rfbProtocolVersionMsg[13]; /* allow extra byte for null */
    189 
    190 #define sz_rfbProtocolVersionMsg 12
    191 
    192 /*
    193  * Negotiation of the security type (protocol versions 3.7, 3.8)
    194  *
    195  * Once the protocol version has been decided, the server either sends a list
    196  * of supported security types, or informs the client about an error (when the
    197  * number of security types is 0).  Security type rfbSecTypeTight is used to
    198  * enable TightVNC-specific protocol extensions.  The value rfbSecTypeVncAuth
    199  * stands for classic VNC authentication.
    200  *
    201  * The client selects a particular security type from the list provided by the
    202  * server.
    203  */
    204 
    205 #define rfbSecTypeInvalid 0
    206 #define rfbSecTypeNone 1
    207 #define rfbSecTypeVncAuth 2
    208 #define rfbSecTypeTight 16
    209 
    210 #define sz_rfbVncChallenge 16
    211 
    212 /*-----------------------------------------------------------------------------
    213  * Negotiation of Tunneling Capabilities (protocol versions 3.7t, 3.8t)
    214  *
    215  * If the chosen security type is rfbSecTypeTight, the server sends a list of
    216  * supported tunneling methods ("tunneling" refers to any additional layer of
    217  * data transformation, such as encryption or external compression.)
    218  *
    219  * nTunnelTypes specifies the number of following rfbCapabilityInfo structures
    220  * that list all supported tunneling methods in the order of preference.
    221  *
    222  * NOTE: If nTunnelTypes is 0, that tells the client that no tunneling can be
    223  * used, and the client should not send a response requesting a tunneling
    224  * method.
    225  */
    226 
    227 typedef struct _rfbTunnelingCapsMsg
    228 {
    229     CARD32 nTunnelTypes;
    230     /* followed by nTunnelTypes * rfbCapabilityInfo structures */
    231 } rfbTunnelingCapsMsg;
    232 
    233 #define sz_rfbTunnelingCapsMsg 4
    234 
    235 /*-----------------------------------------------------------------------------
    236  * Tunneling Method Request (protocol versions 3.7t, 3.8t)
    237  *
    238  * If the list of tunneling capabilities sent by the server was not empty, the
    239  * client should reply with a 32-bit code specifying a particular tunneling
    240  * method.  The following code should be used for no tunneling.
    241  */
    242 
    243 #define rfbNoTunneling 0
    244 #define sig_rfbNoTunneling "NOTUNNEL"
    245 
    246 /*-----------------------------------------------------------------------------
    247  * Negotiation of Authentication Capabilities (protocol versions 3.7t, 3.8t)
    248  *
    249  * After setting up tunneling, the server sends a list of supported
    250  * authentication schemes.
    251  *
    252  * nAuthTypes specifies the number of following rfbCapabilityInfo structures
    253  * that list all supported authentication schemes in the order of preference.
    254  *
    255  * NOTE: If nAuthTypes is 0, that tells the client that no authentication is
    256  * necessary, and the client should not send a response requesting an
    257  * authentication scheme.
    258  */
    259 
    260 typedef struct _rfbAuthenticationCapsMsg
    261 {
    262     CARD32 nAuthTypes;
    263     /* followed by nAuthTypes * rfbCapabilityInfo structures */
    264 } rfbAuthenticationCapsMsg;
    265 
    266 #define sz_rfbAuthenticationCapsMsg 4
    267 
    268 /*-----------------------------------------------------------------------------
    269  * Authentication Scheme Request (protocol versions 3.7t, 3.8t)
    270  *
    271  * If the list of authentication capabilities sent by the server was not empty,
    272  * the client should reply with a 32-bit code specifying a particular
    273  * authentication scheme.  The following codes are supported.
    274  */
    275 
    276 /* Standard authentication methods. */
    277 #define rfbAuthNone 1
    278 #define rfbAuthVNC 2
    279 
    280 #define sig_rfbAuthNone "NOAUTH__"
    281 #define sig_rfbAuthVNC "VNCAUTH_"
    282 
    283 /* These two are not used in the mainstream version. */
    284 #define rfbAuthUnixLogin 129
    285 #define rfbAuthExternal 130
    286 
    287 #define sig_rfbAuthUnixLogin "ULGNAUTH"
    288 #define sig_rfbAuthExternal "XTRNAUTH"
    289 
    290 /*-----------------------------------------------------------------------------
    291  * Authentication result codes (all protocol versions, but rfbAuthTooMany is
    292  * not used in protocol versions above 3.3)
    293  *
    294  * In the protocol version 3.8 and above, rfbAuthFailed is followed by a text
    295  * string describing the reason of failure. The text string is preceded with a
    296  * 32-bit counter of bytes in the string.
    297  */
    298 
    299 #define rfbAuthOK 0
    300 #define rfbAuthFailed 1
    301 #define rfbAuthTooMany 2
    302 
    303 /*-----------------------------------------------------------------------------
    304  * Client Initialisation Message
    305  *
    306  * Once the client and server are sure that they're happy to talk to one
    307  * another, the client sends an initialisation message.  At present this
    308  * message only consists of a boolean indicating whether the server should try
    309  * to share the desktop by leaving other clients connected, or give exclusive
    310  * access to this client by disconnecting all other clients.
    311  */
    312 
    313 typedef struct _rfbClientInitMsg
    314 {
    315     CARD8 shared;
    316 } rfbClientInitMsg;
    317 
    318 #define sz_rfbClientInitMsg 1
    319 
    320 /*-----------------------------------------------------------------------------
    321  * Server Initialisation Message
    322  *
    323  * After the client initialisation message, the server sends one of its own.
    324  * This tells the client the width and height of the server's framebuffer,
    325  * its pixel format and the name associated with the desktop.
    326  */
    327 
    328 typedef struct _rfbServerInitMsg
    329 {
    330     CARD16 framebufferWidth;
    331     CARD16 framebufferHeight;
    332     rfbPixelFormat format; /* the server's preferred pixel format */
    333     CARD32 nameLength;
    334     /* followed by char name[nameLength] */
    335 } rfbServerInitMsg;
    336 
    337 #define sz_rfbServerInitMsg (8 + sz_rfbPixelFormat)
    338 
    339 /*-----------------------------------------------------------------------------
    340  * Server Interaction Capabilities Message (protocol versions 3.7t, 3.8t)
    341  *
    342  * If TightVNC protocol extensions are enabled, the server informs the client
    343  * what message types it supports in addition to ones defined in the standard
    344  * RFB protocol.
    345  * Also, the server sends the list of all supported encodings (note that it's
    346  * not necessary to advertise the "raw" encoding sinse it MUST be supported in
    347  * RFB 3.x protocols).
    348  *
    349  * This data immediately follows the server initialisation message.
    350  */
    351 
    352 typedef struct _rfbInteractionCapsMsg
    353 {
    354     CARD16 nServerMessageTypes;
    355     CARD16 nClientMessageTypes;
    356     CARD16 nEncodingTypes;
    357     CARD16 pad; /* reserved, must be 0 */
    358     /* followed by nServerMessageTypes * rfbCapabilityInfo structures */
    359     /* followed by nClientMessageTypes * rfbCapabilityInfo structures */
    360 } rfbInteractionCapsMsg;
    361 
    362 #define sz_rfbInteractionCapsMsg 8
    363 
    364 /*
    365  * Following the server initialisation message it's up to the client to send
    366  * whichever protocol messages it wants.  Typically it will send a
    367  * SetPixelFormat message and a SetEncodings message, followed by a
    368  * FramebufferUpdateRequest.  From then on the server will send
    369  * FramebufferUpdate messages in response to the client's
    370  * FramebufferUpdateRequest messages.  The client should send
    371  * FramebufferUpdateRequest messages with incremental set to true when it has
    372  * finished processing one FramebufferUpdate and is ready to process another.
    373  * With a fast client, the rate at which FramebufferUpdateRequests are sent
    374  * should be regulated to avoid hogging the network.
    375  */
    376 
    377 /*****************************************************************************
    378  *
    379  * Message types
    380  *
    381  *****************************************************************************/
    382 
    383 /* server -> client */
    384 
    385 #define rfbFramebufferUpdate 0
    386 #define rfbSetColourMapEntries 1
    387 #define rfbBell 2
    388 #define rfbServerCutText 3
    389 
    390 #define rfbFileListData 130
    391 #define rfbFileDownloadData 131
    392 #define rfbFileUploadCancel 132
    393 #define rfbFileDownloadFailed 133
    394 
    395 /* signatures for non-standard messages */
    396 #define sig_rfbFileListData "FTS_LSDT"
    397 #define sig_rfbFileDownloadData "FTS_DNDT"
    398 #define sig_rfbFileUploadCancel "FTS_UPCN"
    399 #define sig_rfbFileDownloadFailed "FTS_DNFL"
    400 
    401 /* client -> server */
    402 
    403 #define rfbSetPixelFormat 0
    404 #define rfbFixColourMapEntries 1 /* not currently supported */
    405 #define rfbSetEncodings 2
    406 #define rfbFramebufferUpdateRequest 3
    407 #define rfbKeyEvent 4
    408 #define rfbPointerEvent 5
    409 #define rfbClientCutText 6
    410 
    411 #define rfbFileListRequest 130
    412 #define rfbFileDownloadRequest 131
    413 #define rfbFileUploadRequest 132
    414 #define rfbFileUploadData 133
    415 #define rfbFileDownloadCancel 134
    416 #define rfbFileUploadFailed 135
    417 #define rfbFileCreateDirRequest 136
    418 
    419 #define rfbEnableContinuousUpdates 150
    420 #define rfbEndOfContinuousUpdates 150
    421 #define rfbFence 248
    422 
    423 #define rfbSetDesktopSize 251
    424 
    425 /* fence flags */
    426 #define rfbFenceFlagBlockBefore 1
    427 #define rfbFenceFlagBlockAfter 2
    428 #define rfbFenceFlagSyncNext 4
    429 #define rfbFenceFlagRequest 0x80000000
    430 #define rfbFenceFlagsSupported (rfbFenceFlagBlockBefore | \
    431                                 rfbFenceFlagBlockAfter |  \
    432                                 rfbFenceFlagSyncNext |    \
    433                                 rfbFenceFlagRequest)
    434 
    435 /* signatures for non-standard messages */
    436 #define sig_rfbFileListRequest "FTC_LSRQ"
    437 #define sig_rfbFileDownloadRequest "FTC_DNRQ"
    438 #define sig_rfbFileUploadRequest "FTC_UPRQ"
    439 #define sig_rfbFileUploadData "FTC_UPDT"
    440 #define sig_rfbFileDownloadCancel "FTC_DNCN"
    441 #define sig_rfbFileUploadFailed "FTC_UPFL"
    442 #define sig_rfbFileCreateDirRequest "FTC_FCDR"
    443 
    444 /*****************************************************************************
    445  *
    446  * Encoding types
    447  *
    448  *****************************************************************************/
    449 
    450 #define rfbEncodingRaw 0      // RFC6143
    451 #define rfbEncodingCopyRect 1 // RFC6143
    452 #define rfbEncodingRRE 2      // RFC6143
    453 #define rfbEncodingCoRRE 4
    454 #define rfbEncodingHextile 5 // RFC6143
    455 #define rfbEncodingZlib 6
    456 #define rfbEncodingTight 7
    457 #define rfbEncodingZlibHex 8
    458 #define rfbEncodingTRLE 15 // RFC6143
    459 #define rfbEncodingZRLE 16 // RFC6143
    460 #define rfbEncodingZYWRLE 17
    461 
    462 /* signatures for basic encoding types */
    463 #define sig_rfbEncodingRaw "RAW_____"
    464 #define sig_rfbEncodingCopyRect "COPYRECT"
    465 #define sig_rfbEncodingRRE "RRE_____"
    466 #define sig_rfbEncodingCoRRE "CORRE___"
    467 #define sig_rfbEncodingHextile "HEXTILE_"
    468 #define sig_rfbEncodingZlib "ZLIB____"
    469 #define sig_rfbEncodingTight "TIGHT___"
    470 #define sig_rfbEncodingZlibHex "ZLIBHEX_"
    471 #define sig_rfbEncodingZRLE "ZRLE____"
    472 #define sig_rfbEncodingZYWRLE "ZYWRLE__"
    473 
    474 /*
    475  * Special encoding numbers:
    476  *   0xFFFFFD00 .. 0xFFFFFD05 -- subsampling level;
    477  *   0xFFFFFE00 .. 0xFFFFFE64 -- fine-grained quality level (0-100 scale);
    478  *   0xFFFFFEC7 .. 0xFFFFFEC8 -- flow control extensions;
    479  *   0xFFFFFF00 .. 0xFFFFFF0F -- encoding-specific compression levels;
    480  *   0xFFFFFF10 .. 0xFFFFFF1F -- mouse cursor shape data;
    481  *   0xFFFFFF20 .. 0xFFFFFF2F -- various protocol extensions;
    482  *   0xFFFFFF30 .. 0xFFFFFFDF -- not allocated yet;
    483  *   0xFFFFFFE0 .. 0xFFFFFFEF -- quality level for JPEG compressor;
    484  *   0xFFFFFFF0 .. 0xFFFFFFFF -- not allocated yet.
    485  */
    486 
    487 #define rfbEncodingFineQualityLevel0 0xFFFFFE00
    488 #define rfbEncodingFineQualityLevel100 0xFFFFFE64
    489 #define rfbEncodingSubsamp1X 0xFFFFFD00
    490 #define rfbEncodingSubsamp4X 0xFFFFFD01
    491 #define rfbEncodingSubsamp2X 0xFFFFFD02
    492 #define rfbEncodingSubsampGray 0xFFFFFD03
    493 #define rfbEncodingSubsamp8X 0xFFFFFD04
    494 #define rfbEncodingSubsamp16X 0xFFFFFD05
    495 
    496 #define rfbEncodingContinuousUpdates 0xFFFFFEC7
    497 #define rfbEncodingFence 0xFFFFFEC8
    498 #define rfbEncodingCompressLevel0 0xFFFFFF00
    499 #define rfbEncodingCompressLevel1 0xFFFFFF01
    500 #define rfbEncodingCompressLevel2 0xFFFFFF02
    501 #define rfbEncodingCompressLevel3 0xFFFFFF03
    502 #define rfbEncodingCompressLevel4 0xFFFFFF04
    503 #define rfbEncodingCompressLevel5 0xFFFFFF05
    504 #define rfbEncodingCompressLevel6 0xFFFFFF06
    505 #define rfbEncodingCompressLevel7 0xFFFFFF07
    506 #define rfbEncodingCompressLevel8 0xFFFFFF08
    507 #define rfbEncodingCompressLevel9 0xFFFFFF09
    508 
    509 #define rfbEncodingXCursor 0xFFFFFF10
    510 #define rfbEncodingRichCursor 0xFFFFFF11
    511 #define rfbEncodingPointerPos 0xFFFFFF18
    512 
    513 #define rfbEncodingLastRect 0xFFFFFF20
    514 #define rfbEncodingNewFBSize 0xFFFFFF21
    515 
    516 #define rfbEncodingQualityLevel0 0xFFFFFFE0
    517 #define rfbEncodingQualityLevel1 0xFFFFFFE1
    518 #define rfbEncodingQualityLevel2 0xFFFFFFE2
    519 #define rfbEncodingQualityLevel3 0xFFFFFFE3
    520 #define rfbEncodingQualityLevel4 0xFFFFFFE4
    521 #define rfbEncodingQualityLevel5 0xFFFFFFE5
    522 #define rfbEncodingQualityLevel6 0xFFFFFFE6
    523 #define rfbEncodingQualityLevel7 0xFFFFFFE7
    524 #define rfbEncodingQualityLevel8 0xFFFFFFE8
    525 #define rfbEncodingQualityLevel9 0xFFFFFFE9
    526 
    527 /* signatures for "fake" encoding types */
    528 #define sig_rfbEncodingCompressLevel0 "COMPRLVL"
    529 #define sig_rfbEncodingXCursor "X11CURSR"
    530 #define sig_rfbEncodingRichCursor "RCHCURSR"
    531 #define sig_rfbEncodingPointerPos "POINTPOS"
    532 #define sig_rfbEncodingLastRect "LASTRECT"
    533 #define sig_rfbEncodingNewFBSize "NEWFBSIZ"
    534 #define sig_rfbEncodingFineQualityLevel0 "FINEQLVL"
    535 #define sig_rfbEncodingSubsamp1X "SSAMPLVL"
    536 #define sig_rfbEncodingQualityLevel0 "JPEGQLVL"
    537 
    538 /*****************************************************************************
    539  *
    540  * Server -> client message definitions
    541  *
    542  *****************************************************************************/
    543 
    544 /*-----------------------------------------------------------------------------
    545  * FramebufferUpdate - a block of rectangles to be copied to the framebuffer.
    546  *
    547  * This message consists of a header giving the number of rectangles of pixel
    548  * data followed by the rectangles themselves.  The header is padded so that
    549  * together with the type byte it is an exact multiple of 4 bytes (to help
    550  * with alignment of 32-bit pixels):
    551  */
    552 
    553 typedef struct _rfbFramebufferUpdateMsg
    554 {
    555     CARD8 type; /* always rfbFramebufferUpdate */
    556     CARD8 pad;
    557     CARD16 nRects;
    558     /* followed by nRects rectangles */
    559 } rfbFramebufferUpdateMsg;
    560 
    561 #define sz_rfbFramebufferUpdateMsg 4
    562 
    563 /*
    564  * Each rectangle of pixel data consists of a header describing the position
    565  * and size of the rectangle and a type word describing the encoding of the
    566  * pixel data, followed finally by the pixel data.  Note that if the client has
    567  * not sent a SetEncodings message then it will only receive raw pixel data.
    568  * Also note again that this structure is a multiple of 4 bytes.
    569  */
    570 
    571 typedef struct _rfbFramebufferUpdateRectHeader
    572 {
    573     rfbRectangle r;
    574     CARD32 encoding; /* one of the encoding types rfbEncoding... */
    575 } rfbFramebufferUpdateRectHeader;
    576 
    577 #define sz_rfbFramebufferUpdateRectHeader (sz_rfbRectangle + 4)
    578 
    579 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    580  * Raw Encoding.  Pixels are sent in top-to-bottom scanline order,
    581  * left-to-right within a scanline with no padding in between.
    582  */
    583 
    584 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    585  * CopyRect Encoding.  The pixels are specified simply by the x and y position
    586  * of the source rectangle.
    587  */
    588 
    589 typedef struct _rfbCopyRect
    590 {
    591     CARD16 srcX;
    592     CARD16 srcY;
    593 } rfbCopyRect;
    594 
    595 #define sz_rfbCopyRect 4
    596 
    597 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    598  * RRE - Rise-and-Run-length Encoding.  We have an rfbRREHeader structure
    599  * giving the number of subrectangles following.  Finally the data follows in
    600  * the form [<bgpixel><subrect><subrect>...] where each <subrect> is
    601  * [<pixel><rfbRectangle>].
    602  */
    603 
    604 typedef struct _rfbRREHeader
    605 {
    606     CARD32 nSubrects;
    607 } rfbRREHeader;
    608 
    609 #define sz_rfbRREHeader 4
    610 
    611 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    612  * CoRRE - Compact RRE Encoding.  We have an rfbRREHeader structure giving
    613  * the number of subrectangles following.  Finally the data follows in the form
    614  * [<bgpixel><subrect><subrect>...] where each <subrect> is
    615  * [<pixel><rfbCoRRERectangle>].  This means that
    616  * the whole rectangle must be at most 255x255 pixels.
    617  */
    618 
    619 typedef struct _rfbCoRRERectangle
    620 {
    621     CARD8 x;
    622     CARD8 y;
    623     CARD8 w;
    624     CARD8 h;
    625 } rfbCoRRERectangle;
    626 
    627 #define sz_rfbCoRRERectangle 4
    628 
    629 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    630  * Hextile Encoding.  The rectangle is divided up into "tiles" of 16x16 pixels,
    631  * starting at the top left going in left-to-right, top-to-bottom order.  If
    632  * the width of the rectangle is not an exact multiple of 16 then the width of
    633  * the last tile in each row will be correspondingly smaller.  Similarly if the
    634  * height is not an exact multiple of 16 then the height of each tile in the
    635  * final row will also be smaller.  Each tile begins with a "subencoding" type
    636  * byte, which is a mask made up of a number of bits.  If the Raw bit is set
    637  * then the other bits are irrelevant; w*h pixel values follow (where w and h
    638  * are the width and height of the tile).  Otherwise the tile is encoded in a
    639  * similar way to RRE, except that the position and size of each subrectangle
    640  * can be specified in just two bytes.  The other bits in the mask are as
    641  * follows:
    642  *
    643  * BackgroundSpecified - if set, a pixel value follows which specifies
    644  *    the background colour for this tile.  The first non-raw tile in a
    645  *    rectangle must have this bit set.  If this bit isn't set then the
    646  *    background is the same as the last tile.
    647  *
    648  * ForegroundSpecified - if set, a pixel value follows which specifies
    649  *    the foreground colour to be used for all subrectangles in this tile.
    650  *    If this bit is set then the SubrectsColoured bit must be zero.
    651  *
    652  * AnySubrects - if set, a single byte follows giving the number of
    653  *    subrectangles following.  If not set, there are no subrectangles (i.e.
    654  *    the whole tile is just solid background colour).
    655  *
    656  * SubrectsColoured - if set then each subrectangle is preceded by a pixel
    657  *    value giving the colour of that subrectangle.  If not set, all
    658  *    subrectangles are the same colour, the foreground colour;  if the
    659  *    ForegroundSpecified bit wasn't set then the foreground is the same as
    660  *    the last tile.
    661  *
    662  * The position and size of each subrectangle is specified in two bytes.  The
    663  * Pack macros below can be used to generate the two bytes from x, y, w, h,
    664  * and the Extract macros can be used to extract the x, y, w, h values from
    665  * the two bytes.
    666  */
    667 
    668 #define rfbHextileRaw (1 << 0)
    669 #define rfbHextileBackgroundSpecified (1 << 1)
    670 #define rfbHextileForegroundSpecified (1 << 2)
    671 #define rfbHextileAnySubrects (1 << 3)
    672 #define rfbHextileSubrectsColoured (1 << 4)
    673 
    674 #define rfbHextilePackXY(x, y) (((x) << 4) | (y))
    675 #define rfbHextilePackWH(w, h) ((((w)-1) << 4) | ((h)-1))
    676 #define rfbHextileExtractX(byte) ((byte) >> 4)
    677 #define rfbHextileExtractY(byte) ((byte)&0xf)
    678 #define rfbHextileExtractW(byte) (((byte) >> 4) + 1)
    679 #define rfbHextileExtractH(byte) (((byte)&0xf) + 1)
    680 
    681 typedef struct __attribute__((packed, aligned(1)))
    682 {
    683     unsigned color : 16;
    684     unsigned y : 4;
    685     unsigned x : 4;
    686 
    687     unsigned h : 4;
    688     unsigned w : 4;
    689 } HextileSubrectsColoured_t;
    690 
    691 typedef struct __attribute__((packed, aligned(1)))
    692 {
    693     unsigned y : 4;
    694     unsigned x : 4;
    695 
    696     unsigned h : 4;
    697     unsigned w : 4;
    698 } HextileSubrects_t;
    699 
    700 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    701  * ZLIB - zlib compression Encoding.  We have an rfbZlibHeader structure
    702  * giving the number of bytes to follow.  Finally the data follows in
    703  * zlib compressed format.
    704  */
    705 
    706 typedef struct _rfbZlibHeader
    707 {
    708     CARD32 nBytes;
    709 } rfbZlibHeader;
    710 
    711 #define sz_rfbZlibHeader 4
    712 
    713 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    714  * Tight Encoding.
    715  *
    716  *-- The first byte of each Tight-encoded rectangle is a "compression control
    717  *   byte". Its format is as follows (bit 0 is the least significant one):
    718  *
    719  *   bit 0:    if 1, then compression stream 0 should be reset;
    720  *   bit 1:    if 1, then compression stream 1 should be reset;
    721  *   bit 2:    if 1, then compression stream 2 should be reset;
    722  *   bit 3:    if 1, then compression stream 3 should be reset;
    723  *   bits 7-4: if 1000 (0x08), then the compression type is "fill",
    724  *             if 1001 (0x09), then the compression type is "jpeg",
    725  *             if 1010 (0x0A), then the compression type is "basic" and no
    726  *               Zlib compression was used,
    727  *             if 1110 (0x0E), then the compression type is "basic", no Zlib
    728  *               compression was used, and a "filter id" byte follows this
    729  *               byte,
    730  *             if 0xxx, then the compression type is "basic" and Zlib
    731  *               compression was used,
    732  *             values greater than 1010 are not valid.
    733  *
    734  * If the compression type is "basic" and Zlib compression was used, then bits
    735  * 6..4 of the compression control byte (those xxx in 0xxx) specify the
    736  * following:
    737  *
    738  *   bits 5-4:  decimal representation is the index of a particular zlib
    739  *              stream which should be used for decompressing the data;
    740  *   bit 6:     if 1, then a "filter id" byte is following this byte.
    741  *
    742  *-- The data that follows after the compression control byte described
    743  * above depends on the compression type ("fill", "jpeg" or "basic").
    744  *
    745  *-- If the compression type is "fill", then the only pixel value follows, in
    746  * client pixel format (see NOTE 1). This value applies to all pixels of the
    747  * rectangle.
    748  *
    749  *-- If the compression type is "jpeg", the following data stream looks like
    750  * this:
    751  *
    752  *   1..3 bytes:  data size (N) in compact representation;
    753  *   N bytes:     JPEG image.
    754  *
    755  * Data size is compactly represented in one, two or three bytes, according
    756  * to the following scheme:
    757  *
    758  *  0xxxxxxx                    (for values 0..127)
    759  *  1xxxxxxx 0yyyyyyy           (for values 128..16383)
    760  *  1xxxxxxx 1yyyyyyy zzzzzzzz  (for values 16384..4194303)
    761  *
    762  * Here each character denotes one bit, xxxxxxx are the least significant 7
    763  * bits of the value (bits 0-6), yyyyyyy are bits 7-13, and zzzzzzzz are the
    764  * most significant 8 bits (bits 14-21). For example, decimal value 10000
    765  * should be represented as two bytes: binary 10010000 01001110, or
    766  * hexadecimal 90 4E.
    767  *
    768  *-- If the compression type is "basic" and bit 6 of the compression control
    769  * byte was set to 1, then the next (second) byte specifies "filter id" which
    770  * tells the decoder what filter type was used by the encoder to pre-process
    771  * pixel data before the compression. The "filter id" byte can be one of the
    772  * following:
    773  *
    774  *   0:  no filter ("copy" filter);
    775  *   1:  "palette" filter;
    776  *   2:  "gradient" filter.
    777  *
    778  *-- If bit 6 of the compression control byte is set to 0 (no "filter id"
    779  * byte), or if the filter id is 0, then raw pixel values in the client
    780  * format (see NOTE 1) will be compressed. See below details on the
    781  * compression.
    782  *
    783  *-- The "gradient" filter pre-processes pixel data with a simple algorithm
    784  * which converts each color component to a difference between a "predicted"
    785  * intensity and the actual intensity. Such a technique does not affect
    786  * uncompressed data size, but helps to compress photo-like images better.
    787  * Pseudo-code for converting intensities to differences is the following:
    788  *
    789  *   P[i,j] := V[i-1,j] + V[i,j-1] - V[i-1,j-1];
    790  *   if (P[i,j] < 0) then P[i,j] := 0;
    791  *   if (P[i,j] > MAX) then P[i,j] := MAX;
    792  *   D[i,j] := V[i,j] - P[i,j];
    793  *
    794  * Here V[i,j] is the intensity of a color component for a pixel at
    795  * coordinates (i,j). MAX is the maximum value of intensity for a color
    796  * component.
    797  *
    798  *-- The "palette" filter converts true-color pixel data to indexed colors
    799  * and a palette which can consist of 2..256 colors. If the number of colors
    800  * is 2, then each pixel is encoded in 1 bit, otherwise 8 bits is used to
    801  * encode one pixel. 1-bit encoding is performed such way that the most
    802  * significant bits correspond to the leftmost pixels, and each raw of pixels
    803  * is aligned to the byte boundary. When "palette" filter is used, the
    804  * palette is sent before the pixel data. The palette begins with an unsigned
    805  * byte which value is the number of colors in the palette minus 1 (i.e. 1
    806  * means 2 colors, 255 means 256 colors in the palette). Then follows the
    807  * palette itself which consist of pixel values in client pixel format (see
    808  * NOTE 1).
    809  *
    810  *-- The pixel data is compressed using the zlib library. But if the data
    811  * size after applying the filter but before the compression is less then 12,
    812  * then the data is sent as is, uncompressed. Four separate zlib streams
    813  * (0..3) can be used and the decoder should read the actual stream id from
    814  * the compression control byte (see NOTE 2).
    815  *
    816  * If the compression is not used, then the pixel data is sent as is,
    817  * otherwise the data stream looks like this:
    818  *
    819  *   1..3 bytes:  data size (N) in compact representation;
    820  *   N bytes:     zlib-compressed data.
    821  *
    822  * Data size is compactly represented in one, two or three bytes, just like
    823  * in the "jpeg" compression method (see above).
    824  *
    825  *-- NOTE 1. If the color depth is 24, and all three color components are
    826  * 8-bit wide, then one pixel in Tight encoding is always represented by
    827  * three bytes, where the first byte is red component, the second byte is
    828  * green component, and the third byte is blue component of the pixel color
    829  * value. This applies to colors in palettes as well.
    830  *
    831  *-- NOTE 2. The decoder must reset compression streams' states before
    832  * decoding the rectangle, if some of bits 0,1,2,3 in the compression control
    833  * byte are set to 1. Note that the decoder must reset zlib streams even if
    834  * the compression type is "fill" or "jpeg".
    835  *
    836  *-- NOTE 3. The "gradient" filter and "jpeg" compression may be used only
    837  * when bits-per-pixel value is either 16 or 32, not 8.
    838  *
    839  *-- NOTE 4. The width of any Tight-encoded rectangle cannot exceed 2048
    840  * pixels. If a rectangle is wider, it must be split into several rectangles
    841  * and each one should be encoded separately.
    842  *
    843  */
    844 
    845 #define rfbTightExplicitFilter 0x04
    846 #define rfbTightFill 0x08
    847 #define rfbTightJpeg 0x09
    848 #define rfbTightNoZlib 0x0A
    849 #define rfbTightMaxSubencoding 0x09
    850 
    851 /* Filters to improve compression efficiency */
    852 #define rfbTightFilterCopy 0x00
    853 #define rfbTightFilterPalette 0x01
    854 #define rfbTightFilterGradient 0x02
    855 
    856 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    857  * ZLIBHEX - zlib compressed Hextile Encoding.  Essentially, this is the
    858  * hextile encoding with zlib compression on the tiles that can not be
    859  * efficiently encoded with one of the other hextile subencodings.  The
    860  * new zlib subencoding uses two bytes to specify the length of the
    861  * compressed tile and then the compressed data follows.  As with the
    862  * raw sub-encoding, the zlib subencoding invalidates the other
    863  * values, if they are also set.
    864  */
    865 
    866 #define rfbHextileZlibRaw (1 << 5)
    867 #define rfbHextileZlibHex (1 << 6)
    868 
    869 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
    870  * 7.7.5. TRLE
    871  * TRLE stands for Tiled Run-Length Encoding, and combines tiling,
    872  * palettization, and run-length encoding.  The rectangle is divided
    873  * into tiles of 16x16 pixels in left-to-right, top-to-bottom order,
    874  * similar to Hextile.  If the width of the rectangle is not an exact
    875  * multiple of 16, then the width of the last tile in each row is
    876  * smaller, and if the height of the rectangle is not an exact multiple
    877  * of 16, then the height of each tile in the final row is smaller.
    878  *
    879  * TRLE makes use of a new type CPIXEL (compressed pixel).  This is the
    880  * same as a PIXEL for the agreed pixel format, except as a special
    881  * case, it uses a more compact format if true-color-flag is non-zero,
    882  * bits-per-pixel is 32, depth is 24 or less, and all of the bits making
    883  * up the red, green, and blue intensities fit in either the least
    884  * significant 3 bytes or the most significant 3 bytes.  If all of these
    885  * are the case, a CPIXEL is only 3 bytes long, and contains the least
    886  * significant or the most significant 3 bytes as appropriate.
    887  * bytesPerCPixel is the number of bytes in a CPIXEL.
    888  *
    889  * Each tile begins with a subencoding type byte.  The top bit of this
    890  * byte is set if the tile has been run-length encoded, clear otherwise.
    891  * The bottom 7 bits indicate the size of the palette used: zero means
    892  * no palette, 1 means that the tile is of a single color, and 2 to 127
    893  * indicate a palette of that size.  The special subencoding values 129
    894  * and 127 indicate that the palette is to be reused from the last tile
    895  * that had a palette, with and without RLE, respectively.
    896  *
    897  * Note: in this discussion, the div(a,b) function means the result of
    898  * dividing a/b truncated to an integer.
    899  *
    900  * The possible values of subencoding are:
    901  *
    902  * 0: Raw pixel data. width*height pixel values follow (where width and
    903  *    height are the width and height of the tile):
    904  *
    905  *     +-----------------------------+--------------+-------------+
    906  *     | No. of bytes                | Type [Value] | Description |
    907  *     +-----------------------------+--------------+-------------+
    908  *     | width*height*BytesPerCPixel | CPIXEL array | pixels      |
    909  *     +-----------------------------+--------------+-------------+
    910  *
    911  * 1: A solid tile consisting of a single color.  The pixel value
    912  *    follows:
    913  *
    914  *            +----------------+--------------+-------------+
    915  *            | No. of bytes   | Type [Value] | Description |
    916  *            +----------------+--------------+-------------+
    917  *            | bytesPerCPixel | CPIXEL       | pixelValue  |
    918  *            +----------------+--------------+-------------+
    919  *
    920  * 2 to 16:  Packed palette types.  The paletteSize is the value of the
    921  *    subencoding, which is followed by the palette, consisting of
    922  *    paletteSize pixel values.  The packed pixels follow, with each
    923  *    pixel represented as a bit field yielding a zero-based index into
    924  *    the palette.  For paletteSize 2, a 1-bit field is used; for
    925  *    paletteSize 3 or 4, a 2-bit field is used; and for paletteSize
    926  *    from 5 to 16, a 4-bit field is used.  The bit fields are packed
    927  *    into bytes, with the most significant bits representing the
    928  *    leftmost pixel (i.e., big endian).  For tiles not a multiple of 8,
    929  *    4, or 2 pixels wide (as appropriate), padding bits are used to
    930  *    align each row to an exact number of bytes.
    931  *
    932  *     +----------------------------+--------------+--------------+
    933  *     | No. of bytes               | Type [Value] | Description  |
    934  *     +----------------------------+--------------+--------------+
    935  *     | paletteSize*bytesPerCPixel | CPIXEL array | palette      |
    936  *     | m                          | U8 array     | packedPixels |
    937  *     +----------------------------+--------------+--------------+
    938  *
    939  *    where m is the number of bytes representing the packed pixels.
    940  *    For paletteSize of 2, this is div(width+7,8)*height; for
    941  *    paletteSize of 3 or 4, this is div(width+3,4)*height; or for
    942  *    paletteSize of 5 to 16, this is div(width+1,2)*height.
    943  *
    944  * 17 to 126:  Unused.  (Packed palettes of these sizes would offer no
    945  *    advantage over palette RLE).
    946  *
    947  * 127:  Packed palette with the palette reused from the previous tile.
    948  *    The subencoding byte is followed by the packed pixels as described
    949  *    above for packed palette types.
    950  *
    951  * 128:  Plain RLE.  The data consists of a number of runs, repeated
    952  *    until the tile is done.  Runs may continue from the end of one row
    953  *    to the beginning of the next.  Each run is represented by a single
    954  *    pixel value followed by the length of the run.  The length is
    955  *    represented as one or more bytes.  The length is calculated as one
    956  *    more than the sum of all the bytes representing the length.  Any
    957  *    byte value other than 255 indicates the final byte.  So for
    958  *    example, length 1 is represented as [0], 255 as [254], 256 as
    959  *    [255,0], 257 as [255,1], 510 as [255,254], 511 as [255,255,0], and
    960  *    so on.
    961  *
    962  *  +-------------------------+--------------+-----------------------+
    963  *  | No. of bytes            | Type [Value] | Description           |
    964  *  +-------------------------+--------------+-----------------------+
    965  *  | bytesPerCPixel          | CPIXEL       | pixelValue            |
    966  *  | div(runLength - 1, 255) | U8 array     | 255                   |
    967  *  | 1                       | U8           | (runLength-1) mod 255 |
    968  *  +-------------------------+--------------+-----------------------+
    969  *
    970  * 129:  Palette RLE with the palette reused from the previous tile.
    971  *    Followed by a number of runs, repeated until the tile is done, as
    972  *    described below for 130 to 255.
    973  *
    974  * 130 to 255:  Palette RLE.  Followed by the palette, consisting of
    975  *    paletteSize = (subencoding - 128) pixel values:
    976  *
    977  *      +----------------------------+--------------+-------------+
    978  *      | No. of bytes               | Type [Value] | Description |
    979  *      +----------------------------+--------------+-------------+
    980  *      | paletteSize*bytesPerCPixel | CPIXEL array | palette     |
    981  *      +----------------------------+--------------+-------------+
    982  *
    983  *    Following the palette is, as with plain RLE, a number of runs,
    984  *    repeated until the tile is done.  A run of length one is
    985  *    represented simply by a palette index:
    986  *
    987  *            +--------------+--------------+--------------+
    988  *            | No. of bytes | Type [Value] | Description  |
    989  *            +--------------+--------------+--------------+
    990  *            | 1            | U8           | paletteIndex |
    991  *            +--------------+--------------+--------------+
    992  *
    993  *    A run of length more than one is represented by a palette index
    994  *    with the top bit set, followed by the length of the run as for
    995  *    plain RLE.
    996  *
    997  *  +-------------------------+--------------+-----------------------+
    998  *  | No. of bytes            | Type [Value] | Description           |
    999  *  +-------------------------+--------------+-----------------------+
   1000  *  | 1                       | U8           | paletteIndex + 128    |
   1001  *  | div(runLength - 1, 255) | U8 array     | 255                   |
   1002  *  | 1                       | U8           | (runLength-1) mod 255 |
   1003  *  +-------------------------+--------------+-----------------------+
   1004  */
   1005 
   1006 #define rfbTrleRaw 0
   1007 #define rfbTrleSolid 1
   1008 #define rfbTrleReusePackedPalette 127
   1009 #define rfbTrlePlainRLE 128
   1010 #define rfbTrleReusePaletteRLE 129
   1011 
   1012 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   1013  * 7.7.6. ZRLE
   1014  * ZRLE stands for Zlib (see [RFC1950] and [RFC1951]) Run-Length
   1015  * Encoding, and combines an encoding similar to TRLE with zlib
   1016  * compression.  On the wire, the rectangle begins with a 4-byte length
   1017  * field, and is followed by that many bytes of zlib-compressed data.  A
   1018  * single zlib "stream" object is used for a given RFB protocol
   1019  * connection, so that ZRLE rectangles must be encoded and decoded
   1020  * strictly in order.
   1021  *             +--------------+--------------+-------------+
   1022  *             | No. of bytes | Type [Value] | Description |
   1023  *             +--------------+--------------+-------------+
   1024  *             | 4            | U32          | length      |
   1025  *             | length       | U8 array     | zlibData    |
   1026  *             +--------------+--------------+-------------+
   1027  * The zlibData when uncompressed represents tiles in left-to-right,
   1028  * top-to-bottom order, similar to TRLE, but with a tile size of 64x64
   1029  * pixels.  If the width of the rectangle is not an exact multiple of
   1030  * 64, then the width of the last tile in each row is smaller, and if
   1031  * the height of the rectangle is not an exact multiple of 64, then the
   1032  * height of each tile in the final row is smaller.
   1033  * The tiles are encoded in exactly the same way as TRLE, except that
   1034  * subencoding may not take the values 127 or 129, i.e., palettes cannot
   1035  * be reused between tiles.
   1036  * The server flushes the zlib stream to a byte boundary at the end of
   1037  * each ZRLE-encoded rectangle.  It need not flush the stream between
   1038  * tiles within a rectangle.  Since the zlibData for a single rectangle
   1039  * can potentially be quite large, clients can incrementally decode and
   1040  * interpret the zlibData but must not assume that encoded tile data is
   1041  * byte aligned.
   1042  */
   1043 
   1044 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   1045  * XCursor encoding. This is a special encoding used to transmit X-style
   1046  * cursor shapes from server to clients. Note that for this encoding,
   1047  * coordinates in rfbFramebufferUpdateRectHeader structure hold hotspot
   1048  * position (r.x, r.y) and cursor size (r.w, r.h). If (w * h != 0), two RGB
   1049  * samples are sent after header in the rfbXCursorColors structure. They
   1050  * denote foreground and background colors of the cursor. If a client
   1051  * supports only black-and-white cursors, it should ignore these colors and
   1052  * assume that foreground is black and background is white. Next, two bitmaps
   1053  * (1 bits per pixel) follow: first one with actual data (value 0 denotes
   1054  * background color, value 1 denotes foreground color), second one with
   1055  * transparency data (bits with zero value mean that these pixels are
   1056  * transparent). Both bitmaps represent cursor data in a byte stream, from
   1057  * left to right, from top to bottom, and each row is byte-aligned. Most
   1058  * significant bits correspond to leftmost pixels. The number of bytes in
   1059  * each row can be calculated as ((w + 7) / 8). If (w * h == 0), cursor
   1060  * should be hidden (or default local cursor should be set by the client).
   1061  */
   1062 
   1063 typedef struct _rfbXCursorColors
   1064 {
   1065     CARD8 foreRed;
   1066     CARD8 foreGreen;
   1067     CARD8 foreBlue;
   1068     CARD8 backRed;
   1069     CARD8 backGreen;
   1070     CARD8 backBlue;
   1071 } rfbXCursorColors;
   1072 
   1073 #define sz_rfbXCursorColors 6
   1074 
   1075 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   1076  * RichCursor encoding. This is a special encoding used to transmit cursor
   1077  * shapes from server to clients. It is similar to the XCursor encoding but
   1078  * uses client pixel format instead of two RGB colors to represent cursor
   1079  * image. For this encoding, coordinates in rfbFramebufferUpdateRectHeader
   1080  * structure hold hotspot position (r.x, r.y) and cursor size (r.w, r.h).
   1081  * After header, two pixmaps follow: first one with cursor image in current
   1082  * client pixel format (like in raw encoding), second with transparency data
   1083  * (1 bit per pixel, exactly the same format as used for transparency bitmap
   1084  * in the XCursor encoding). If (w * h == 0), cursor should be hidden (or
   1085  * default local cursor should be set by the client).
   1086  */
   1087 
   1088 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
   1089  * ZRLE - encoding combining Zlib compression, tiling, palettisation and
   1090  * run-length encoding.
   1091  */
   1092 
   1093 typedef struct
   1094 {
   1095     CARD32 length;
   1096 } rfbZRLEHeader;
   1097 
   1098 #define sz_rfbZRLEHeader 4
   1099 
   1100 #define rfbZRLETileWidth 64
   1101 #define rfbZRLETileHeight 64
   1102 
   1103 /*-----------------------------------------------------------------------------
   1104  * SetColourMapEntries - these messages are only sent if the pixel
   1105  * format uses a "colour map" (i.e. trueColour false) and the client has not
   1106  * fixed the entire colour map using FixColourMapEntries.  In addition they
   1107  * will only start being sent after the client has sent its first
   1108  * FramebufferUpdateRequest.  So if the client always tells the server to use
   1109  * trueColour then it never needs to process this type of message.
   1110  */
   1111 
   1112 typedef struct _rfbSetColourMapEntriesMsg
   1113 {
   1114     CARD8 type; /* always rfbSetColourMapEntries */
   1115     CARD8 pad;
   1116     CARD16 firstColour;
   1117     CARD16 nColours;
   1118 
   1119     /* Followed by nColours * 3 * CARD16
   1120        r1, g1, b1, r2, g2, b2, r3, g3, b3, ..., rn, bn, gn */
   1121 
   1122 } rfbSetColourMapEntriesMsg;
   1123 
   1124 #define sz_rfbSetColourMapEntriesMsg 6
   1125 
   1126 /*-----------------------------------------------------------------------------
   1127  * Bell - ring a bell on the client if it has one.
   1128  */
   1129 
   1130 typedef struct _rfbBellMsg
   1131 {
   1132     CARD8 type; /* always rfbBell */
   1133 } rfbBellMsg;
   1134 
   1135 #define sz_rfbBellMsg 1
   1136 
   1137 /*-----------------------------------------------------------------------------
   1138  * ServerCutText - the server has new text in its cut buffer.
   1139  */
   1140 
   1141 typedef struct _rfbServerCutTextMsg
   1142 {
   1143     CARD8 type; /* always rfbServerCutText */
   1144     CARD8 pad1;
   1145     CARD16 pad2;
   1146     CARD32 length;
   1147     /* followed by char text[length] */
   1148 } rfbServerCutTextMsg;
   1149 
   1150 #define sz_rfbServerCutTextMsg 8
   1151 
   1152 /*-----------------------------------------------------------------------------
   1153  * FileListData
   1154  */
   1155 
   1156 typedef struct _rfbFileListDataMsg
   1157 {
   1158     CARD8 type;
   1159     CARD8 flags;
   1160     CARD16 numFiles;
   1161     CARD16 dataSize;
   1162     CARD16 compressedSize;
   1163     /* Followed by SizeData[numFiles] */
   1164     /* Followed by Filenames[compressedSize] */
   1165 } rfbFileListDataMsg;
   1166 
   1167 #define sz_rfbFileListDataMsg 8
   1168 
   1169 /*-----------------------------------------------------------------------------
   1170  * FileDownloadData
   1171  */
   1172 
   1173 typedef struct _rfbFileDownloadDataMsg
   1174 {
   1175     CARD8 type;
   1176     CARD8 compressLevel;
   1177     CARD16 realSize;
   1178     CARD16 compressedSize;
   1179     /* Followed by File[copressedSize],
   1180        but if (realSize = compressedSize = 0) followed by CARD32 modTime  */
   1181 } rfbFileDownloadDataMsg;
   1182 
   1183 #define sz_rfbFileDownloadDataMsg 6
   1184 
   1185 /*-----------------------------------------------------------------------------
   1186  * FileUploadCancel
   1187  */
   1188 
   1189 typedef struct _rfbFileUploadCancelMsg
   1190 {
   1191     CARD8 type;
   1192     CARD8 unused;
   1193     CARD16 reasonLen;
   1194     /* Followed by reason[reasonLen] */
   1195 } rfbFileUploadCancelMsg;
   1196 
   1197 #define sz_rfbFileUploadCancelMsg 4
   1198 
   1199 /*-----------------------------------------------------------------------------
   1200  * FileDownloadFailed
   1201  */
   1202 
   1203 typedef struct _rfbFileDownloadFailedMsg
   1204 {
   1205     CARD8 type;
   1206     CARD8 unused;
   1207     CARD16 reasonLen;
   1208     /* Followed by reason[reasonLen] */
   1209 } rfbFileDownloadFailedMsg;
   1210 
   1211 #define sz_rfbFileDownloadFailedMsg 4
   1212 
   1213 /*-----------------------------------------------------------------------------
   1214  * Fence
   1215  */
   1216 
   1217 typedef struct _rfbFenceMsg
   1218 {
   1219     CARD8 type; /* always rfbFence */
   1220     CARD8 pad[3];
   1221     CARD32 flags;
   1222     CARD8 length;
   1223     /* Followed by char data[length] */
   1224 } rfbFenceMsg;
   1225 
   1226 #define sz_rfbFenceMsg 9
   1227 
   1228 /*-----------------------------------------------------------------------------
   1229  * Union of all server->client messages.
   1230  */
   1231 
   1232 typedef union _rfbServerToClientMsg
   1233 {
   1234     CARD8 type;
   1235     rfbFramebufferUpdateMsg fu;
   1236     rfbSetColourMapEntriesMsg scme;
   1237     rfbBellMsg b;
   1238     rfbServerCutTextMsg sct;
   1239     rfbFileListDataMsg fld;
   1240     rfbFileDownloadDataMsg fdd;
   1241     rfbFileUploadCancelMsg fuc;
   1242     rfbFileDownloadFailedMsg fdf;
   1243     rfbFenceMsg f;
   1244 } rfbServerToClientMsg;
   1245 
   1246 /*****************************************************************************
   1247  *
   1248  * Message definitions (client -> server)
   1249  *
   1250  *****************************************************************************/
   1251 
   1252 /*-----------------------------------------------------------------------------
   1253  * SetPixelFormat - tell the RFB server the format in which the client wants
   1254  * pixels sent.
   1255  */
   1256 
   1257 typedef struct _rfbSetPixelFormatMsg
   1258 {
   1259     CARD8 type; /* always rfbSetPixelFormat */
   1260     CARD8 pad1;
   1261     CARD16 pad2;
   1262     rfbPixelFormat format;
   1263 } rfbSetPixelFormatMsg;
   1264 
   1265 #define sz_rfbSetPixelFormatMsg (sz_rfbPixelFormat + 4)
   1266 
   1267 /*-----------------------------------------------------------------------------
   1268  * SetDesktopSize
   1269  */
   1270 
   1271 typedef struct _rfbSetDesktopSizeMsg
   1272 {
   1273     CARD8 type; /* always rfbSetDesktopSize */
   1274     CARD8 pad1;
   1275     CARD16 width;
   1276     CARD16 height;
   1277     CARD8 numScreens;
   1278     CARD8 pad2;
   1279     CARD32 layoutId;
   1280     CARD16 layoutX;
   1281     CARD16 layoutY;
   1282     CARD16 layoutWidth;
   1283     CARD16 layoutHeight;
   1284     CARD32 layoutFlag;
   1285 } rfbSetDesktopSizeMsg;
   1286 
   1287 #define sz_rfbSetDesktopSizeMsg (24)
   1288 
   1289 /*-----------------------------------------------------------------------------
   1290  * FixColourMapEntries - when the pixel format uses a "colour map", fix
   1291  * read-only colour map entries.
   1292  *
   1293  *    ***************** NOT CURRENTLY SUPPORTED *****************
   1294  */
   1295 
   1296 typedef struct _rfbFixColourMapEntriesMsg
   1297 {
   1298     CARD8 type; /* always rfbFixColourMapEntries */
   1299     CARD8 pad;
   1300     CARD16 firstColour;
   1301     CARD16 nColours;
   1302 
   1303     /* Followed by nColours * 3 * CARD16
   1304        r1, g1, b1, r2, g2, b2, r3, g3, b3, ..., rn, bn, gn */
   1305 
   1306 } rfbFixColourMapEntriesMsg;
   1307 
   1308 #define sz_rfbFixColourMapEntriesMsg 6
   1309 
   1310 /*-----------------------------------------------------------------------------
   1311  * SetEncodings - tell the RFB server which encoding types we accept.  Put them
   1312  * in order of preference, if we have any.  We may always receive raw
   1313  * encoding, even if we don't specify it here.
   1314  */
   1315 
   1316 typedef struct _rfbSetEncodingsMsg
   1317 {
   1318     CARD8 type; /* always rfbSetEncodings */
   1319     CARD8 pad;
   1320     CARD16 nEncodings;
   1321     /* followed by nEncodings * CARD32 encoding types */
   1322 } rfbSetEncodingsMsg;
   1323 
   1324 #define sz_rfbSetEncodingsMsg 4
   1325 
   1326 /*-----------------------------------------------------------------------------
   1327  * FramebufferUpdateRequest - request for a framebuffer update.  If incremental
   1328  * is true then the client just wants the changes since the last update.  If
   1329  * false then it wants the whole of the specified rectangle.
   1330  */
   1331 
   1332 typedef struct _rfbFramebufferUpdateRequestMsg
   1333 {
   1334     CARD8 type; /* always rfbFramebufferUpdateRequest */
   1335     CARD8 incremental;
   1336     CARD16 x;
   1337     CARD16 y;
   1338     CARD16 w;
   1339     CARD16 h;
   1340 } rfbFramebufferUpdateRequestMsg;
   1341 
   1342 #define sz_rfbFramebufferUpdateRequestMsg 10
   1343 
   1344 /*-----------------------------------------------------------------------------
   1345  * KeyEvent - key press or release
   1346  *
   1347  * Keys are specified using the "keysym" values defined by the X Window System.
   1348  * For most ordinary keys, the keysym is the same as the corresponding ASCII
   1349  * value.  Other common keys are:
   1350  *
   1351  * BackSpace		0xff08
   1352  * Tab			0xff09
   1353  * Return or Enter	0xff0d
   1354  * Escape		0xff1b
   1355  * Insert		0xff63
   1356  * Delete		0xffff
   1357  * Home			0xff50
   1358  * End			0xff57
   1359  * Page Up		0xff55
   1360  * Page Down		0xff56
   1361  * Left			0xff51
   1362  * Up			0xff52
   1363  * Right		0xff53
   1364  * Down			0xff54
   1365  * F1			0xffbe
   1366  * F2			0xffbf
   1367  * ...			...
   1368  * F12			0xffc9
   1369  * Shift		0xffe1
   1370  * Control		0xffe3
   1371  * Meta			0xffe7
   1372  * Alt			0xffe9
   1373  */
   1374 
   1375 typedef struct _rfbKeyEventMsg
   1376 {
   1377     CARD8 type; /* always rfbKeyEvent */
   1378     CARD8 down; /* true if down (press), false if up */
   1379     CARD16 pad;
   1380     CARD32 key; /* key is specified as an X keysym */
   1381 } rfbKeyEventMsg;
   1382 
   1383 #define sz_rfbKeyEventMsg 8
   1384 
   1385 /*-----------------------------------------------------------------------------
   1386  * PointerEvent - mouse/pen move and/or button press.
   1387  */
   1388 
   1389 typedef struct _rfbPointerEventMsg
   1390 {
   1391     CARD8 type;       /* always rfbPointerEvent */
   1392     CARD8 buttonMask; /* bits 0-7 are buttons 1-8, 0=up, 1=down */
   1393     CARD16 x;
   1394     CARD16 y;
   1395 } rfbPointerEventMsg;
   1396 
   1397 #define rfbButton1Mask 1
   1398 #define rfbButton2Mask 2
   1399 #define rfbButton3Mask 4
   1400 #define rfbButton4Mask 8
   1401 #define rfbButton5Mask 16
   1402 
   1403 #define sz_rfbPointerEventMsg 6
   1404 
   1405 /*-----------------------------------------------------------------------------
   1406  * ClientCutText - the client has new text in its cut buffer.
   1407  */
   1408 
   1409 typedef struct _rfbClientCutTextMsg
   1410 {
   1411     CARD8 type; /* always rfbClientCutText */
   1412     CARD8 pad1;
   1413     CARD16 pad2;
   1414     CARD32 length;
   1415     /* followed by char text[length] */
   1416 } rfbClientCutTextMsg;
   1417 
   1418 #define sz_rfbClientCutTextMsg 8
   1419 
   1420 /*-----------------------------------------------------------------------------
   1421  * FileListRequest
   1422  */
   1423 
   1424 typedef struct _rfbFileListRequestMsg
   1425 {
   1426     CARD8 type;
   1427     CARD8 flags;
   1428     CARD16 dirNameSize;
   1429     /* Followed by char Dirname[dirNameSize] */
   1430 } rfbFileListRequestMsg;
   1431 
   1432 #define sz_rfbFileListRequestMsg 4
   1433 
   1434 /*-----------------------------------------------------------------------------
   1435  * FileDownloadRequest
   1436  */
   1437 
   1438 typedef struct _rfbFileDownloadRequestMsg
   1439 {
   1440     CARD8 type;
   1441     CARD8 compressedLevel;
   1442     CARD16 fNameSize;
   1443     CARD32 position;
   1444     /* Followed by char Filename[fNameSize] */
   1445 } rfbFileDownloadRequestMsg;
   1446 
   1447 #define sz_rfbFileDownloadRequestMsg 8
   1448 
   1449 /*-----------------------------------------------------------------------------
   1450  * FileUploadRequest
   1451  */
   1452 
   1453 typedef struct _rfbFileUploadRequestMsg
   1454 {
   1455     CARD8 type;
   1456     CARD8 compressedLevel;
   1457     CARD16 fNameSize;
   1458     CARD32 position;
   1459     /* Followed by char Filename[fNameSize] */
   1460 } rfbFileUploadRequestMsg;
   1461 
   1462 #define sz_rfbFileUploadRequestMsg 8
   1463 
   1464 /*-----------------------------------------------------------------------------
   1465  * FileUploadData
   1466  */
   1467 
   1468 typedef struct _rfbFileUploadDataMsg
   1469 {
   1470     CARD8 type;
   1471     CARD8 compressedLevel;
   1472     CARD16 realSize;
   1473     CARD16 compressedSize;
   1474     /* Followed by File[compressedSize],
   1475        but if (realSize = compressedSize = 0) followed by CARD32 modTime  */
   1476 } rfbFileUploadDataMsg;
   1477 
   1478 #define sz_rfbFileUploadDataMsg 6
   1479 
   1480 /*-----------------------------------------------------------------------------
   1481  * FileDownloadCancel
   1482  */
   1483 
   1484 typedef struct _rfbFileDownloadCancelMsg
   1485 {
   1486     CARD8 type;
   1487     CARD8 unused;
   1488     CARD16 reasonLen;
   1489     /* Followed by reason[reasonLen] */
   1490 } rfbFileDownloadCancelMsg;
   1491 
   1492 #define sz_rfbFileDownloadCancelMsg 4
   1493 
   1494 /*-----------------------------------------------------------------------------
   1495  * FileUploadFailed
   1496  */
   1497 
   1498 typedef struct _rfbFileUploadFailedMsg
   1499 {
   1500     CARD8 type;
   1501     CARD8 unused;
   1502     CARD16 reasonLen;
   1503     /* Followed by reason[reasonLen] */
   1504 } rfbFileUploadFailedMsg;
   1505 
   1506 #define sz_rfbFileUploadFailedMsg 4
   1507 
   1508 /*-----------------------------------------------------------------------------
   1509  * FileCreateDirRequest
   1510  */
   1511 
   1512 typedef struct _rfbFileCreateDirRequestMsg
   1513 {
   1514     CARD8 type;
   1515     CARD8 unused;
   1516     CARD16 dNameLen;
   1517     /* Followed by dName[dNameLen] */
   1518 } rfbFileCreateDirRequestMsg;
   1519 
   1520 #define sz_rfbFileCreateDirRequestMsg 4
   1521 
   1522 /*-----------------------------------------------------------------------------
   1523  * EnableContinuousUpdates
   1524  */
   1525 
   1526 typedef struct _rfbEnableContinuousUpdatesMsg
   1527 {
   1528     CARD8 type; /* always rfbEnableContinuousUpdates */
   1529     CARD8 enable;
   1530     CARD16 x;
   1531     CARD16 y;
   1532     CARD16 w;
   1533     CARD16 h;
   1534 } rfbEnableContinuousUpdatesMsg;
   1535 
   1536 #define sz_rfbEnableContinuousUpdatesMsg 10
   1537 /*-----------------------------------------------------------------------------
   1538  * Union of all client->server messages.
   1539  */
   1540 
   1541 typedef union _rfbClientToServerMsg
   1542 {
   1543     CARD8 type;
   1544     rfbSetPixelFormatMsg spf;
   1545     rfbSetDesktopSizeMsg sds;
   1546     rfbFixColourMapEntriesMsg fcme;
   1547     rfbSetEncodingsMsg se;
   1548     rfbFramebufferUpdateRequestMsg fur;
   1549     rfbKeyEventMsg ke;
   1550     rfbPointerEventMsg pe;
   1551     rfbClientCutTextMsg cct;
   1552     rfbFileListRequestMsg flr;
   1553     rfbFileDownloadRequestMsg fdr;
   1554     rfbFileUploadRequestMsg fupr;
   1555     rfbFileUploadDataMsg fud;
   1556     rfbFileDownloadCancelMsg fdc;
   1557     rfbFileUploadFailedMsg fuf;
   1558     rfbFileCreateDirRequestMsg fcdr;
   1559     rfbEnableContinuousUpdatesMsg ecu;
   1560     rfbFenceMsg f;
   1561 } rfbClientToServerMsg;