Real-time collaboration for Jupyter Notebooks, Linux Terminals, LaTeX, VS Code, R IDE, and more,
all in one place.

1
/*
2
 *  Copyright (C) 2000-2006 Constantin Kaplinsky. All Rights Reserved.
3
 *  Copyright (C) 2000 Tridia Corporation. All Rights Reserved.
4
 *  Copyright (C) 1999 AT&T Laboratories Cambridge. All Rights Reserved.
5
 *
6
 *  This is free software; you can redistribute it and/or modify
7
 *  it under the terms of the GNU General Public License as published by
8
 *  the Free Software Foundation; either version 2 of the License, or
9
 *  (at your option) any later version.
10
 *
11
 *  This software is distributed in the hope that it will be useful,
12
 *  but WITHOUT ANY WARRANTY; without even the implied warranty of
13
 *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
14
 *  GNU General Public License for more details.
15
 *
16
 *  You should have received a copy of the GNU General Public License
17
 *  along with this software; if not, write to the Free Software
18
 *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307,
19
 *  USA.
20
 */
21

22
/*
23
 * rfbproto.h - header file for the RFB protocol, versions 3.3, 3.7 and 3.7t,
24
 * 3.8 and 3.8t ("t" suffix denotes TightVNC protocol extensions enabled)
25
 *
26
 * Uses types CARD<n> for an n-bit unsigned integer, INT<n> for an n-bit signed
27
 * integer (for n = 8, 16 and 32).
28
 *
29
 * All multiple byte integers are in big endian (network) order (most
30
 * significant byte first).  Unless noted otherwise there is no special
31
 * alignment of protocol structures.
32
 *
33
 *
34
 * Once the initial handshaking is done, all messages start with a type byte,
35
 * (usually) followed by message-specific data.  The order of definitions in
36
 * this file is as follows:
37
 *
38
 *  (1) Structures used in several types of message.
39
 *  (2) Structures used in the initial handshaking.
40
 *  (3) Message types.
41
 *  (4) Encoding types.
42
 *  (5) For each message type, the form of the data following the type byte.
43
 *      Sometimes this is defined by a single structure but the more complex
44
 *      messages have to be explained by comments.
45
 */
46

47

48
/*****************************************************************************
49
 *
50
 * Structures used in several messages
51
 *
52
 *****************************************************************************/
53

54
/*-----------------------------------------------------------------------------
55
 * Structure used to specify a rectangle.  This structure is a multiple of 4
56
 * bytes so that it can be interspersed with 32-bit pixel data without
57
 * affecting alignment.
58
 */
59

60
typedef struct _rfbRectangle {
61
    CARD16 x;
62
    CARD16 y;
63
    CARD16 w;
64
    CARD16 h;
65
} rfbRectangle;
66

67
#define sz_rfbRectangle 8
68

69

70
/*-----------------------------------------------------------------------------
71
 * Structure used to specify pixel format.
72
 */
73

74
typedef struct _rfbPixelFormat {
75

76
    CARD8 bitsPerPixel;		/* 8,16,32 only */
77

78
    CARD8 depth;		/* 8 to 32 */
79

80
    CARD8 bigEndian;		/* True if multi-byte pixels are interpreted
81
				   as big endian, or if single-bit-per-pixel
82
				   has most significant bit of the byte
83
				   corresponding to first (leftmost) pixel. Of
84
				   course this is meaningless for 8 bits/pix */
85

86
    CARD8 trueColour;		/* If false then we need a "colour map" to
87
				   convert pixels to RGB.  If true, xxxMax and
88
				   xxxShift specify bits used for red, green
89
				   and blue */
90

91
    /* the following fields are only meaningful if trueColour is true */
92

93
    CARD16 redMax;		/* maximum red value (= 2^n - 1 where n is the
94
				   number of bits used for red). Note this
95
				   value is always in big endian order. */
96

97
    CARD16 greenMax;		/* similar for green */
98

99
    CARD16 blueMax;		/* and blue */
100

101
    CARD8 redShift;		/* number of shifts needed to get the red
102
				   value in a pixel to the least significant
103
				   bit. To find the red value from a given
104
				   pixel, do the following:
105
				   1) Swap pixel value according to bigEndian
106
				      (e.g. if bigEndian is false and host byte
107
				      order is big endian, then swap).
108
				   2) Shift right by redShift.
109
				   3) AND with redMax (in host byte order).
110
				   4) You now have the red value between 0 and
111
				      redMax. */
112

113
    CARD8 greenShift;		/* similar for green */
114

115
    CARD8 blueShift;		/* and blue */
116

117
    CARD8 pad1;
118
    CARD16 pad2;
119

120
} rfbPixelFormat;
121

122
#define sz_rfbPixelFormat 16
123

124

125
/*-----------------------------------------------------------------------------
126
 * Structure used to describe protocol options such as tunneling methods,
127
 * authentication schemes and message types (protocol versions 3.7t, 3.8t).
128
 */
129

130
typedef struct _rfbCapabilityInfo {
131

132
    CARD32 code;		/* numeric identifier */
133
    CARD8 vendorSignature[4];	/* vendor identification */
134
    CARD8 nameSignature[8];	/* abbreviated option name */
135

136
} rfbCapabilityInfo;
137

138
#define sz_rfbCapabilityInfoVendor 4
139
#define sz_rfbCapabilityInfoName 8
140
#define sz_rfbCapabilityInfo 16
141

142
/*
143
 * Vendors known by TightVNC: standard VNC/RealVNC, TridiaVNC, and TightVNC.
144
 */
145

146
#define rfbStandardVendor "STDV"
147
#define rfbTridiaVncVendor "TRDV"
148
#define rfbTightVncVendor "TGHT"
149

150

151
/*****************************************************************************
152
 *
153
 * Initial handshaking messages
154
 *
155
 *****************************************************************************/
156

157
/*-----------------------------------------------------------------------------
158
 * Protocol Version
159
 *
160
 * The server always sends 12 bytes to start which identifies the latest RFB
161
 * protocol version number which it supports.  These bytes are interpreted
162
 * as a string of 12 ASCII characters in the format "RFB xxx.yyy\n" where
163
 * xxx and yyy are the major and minor version numbers (e.g. for version 3.8
164
 * this is "RFB 003.008\n").
165
 *
166
 * The client then replies with a similar 12-byte message giving the version
167
 * number of the protocol which should actually be used (which may be different
168
 * to that quoted by the server).
169
 *
170
 * It is intended that both clients and servers may provide some level of
171
 * backwards compatibility by this mechanism.  Servers in particular should
172
 * attempt to provide backwards compatibility, and even forwards compatibility
173
 * to some extent.  For example if a client demands version 3.1 of the
174
 * protocol, a 3.0 server can probably assume that by ignoring requests for
175
 * encoding types it doesn't understand, everything will still work OK.  This
176
 * will probably not be the case for changes in the major version number.
177
 *
178
 * The format string below can be used in sprintf or sscanf to generate or
179
 * decode the version string respectively.
180
 */
181

182
#define rfbProtocolVersionFormat "RFB %03d.%03d\n"
183

184
typedef char rfbProtocolVersionMsg[13];	/* allow extra byte for null */
185

186
#define sz_rfbProtocolVersionMsg 12
187

188

189
/*
190
 * Negotiation of the security type (protocol versions 3.7, 3.8)
191
 *
192
 * Once the protocol version has been decided, the server either sends a list
193
 * of supported security types, or informs the client about an error (when the
194
 * number of security types is 0).  Security type rfbSecTypeTight is used to
195
 * enable TightVNC-specific protocol extensions.  The value rfbSecTypeVncAuth
196
 * stands for classic VNC authentication.
197
 *
198
 * The client selects a particular security type from the list provided by the
199
 * server.
200
 */
201

202
#define rfbSecTypeInvalid 0
203
#define rfbSecTypeNone 1
204
#define rfbSecTypeVncAuth 2
205
#define rfbSecTypeTight 16
206

207

208
/*-----------------------------------------------------------------------------
209
 * Negotiation of Tunneling Capabilities (protocol versions 3.7t, 3.8t)
210
 *
211
 * If the chosen security type is rfbSecTypeTight, the server sends a list of
212
 * supported tunneling methods ("tunneling" refers to any additional layer of
213
 * data transformation, such as encryption or external compression.)
214
 *
215
 * nTunnelTypes specifies the number of following rfbCapabilityInfo structures
216
 * that list all supported tunneling methods in the order of preference.
217
 *
218
 * NOTE: If nTunnelTypes is 0, that tells the client that no tunneling can be
219
 * used, and the client should not send a response requesting a tunneling
220
 * method.
221
 */
222

223
typedef struct _rfbTunnelingCapsMsg {
224
    CARD32 nTunnelTypes;
225
    /* followed by nTunnelTypes * rfbCapabilityInfo structures */
226
} rfbTunnelingCapsMsg;
227

228
#define sz_rfbTunnelingCapsMsg 4
229

230
/*-----------------------------------------------------------------------------
231
 * Tunneling Method Request (protocol versions 3.7t, 3.8t)
232
 *
233
 * If the list of tunneling capabilities sent by the server was not empty, the
234
 * client should reply with a 32-bit code specifying a particular tunneling
235
 * method.  The following code should be used for no tunneling.
236
 */
237

238
#define rfbNoTunneling 0
239
#define sig_rfbNoTunneling "NOTUNNEL"
240

241

242
/*-----------------------------------------------------------------------------
243
 * Negotiation of Authentication Capabilities (protocol versions 3.7t, 3.8t)
244
 *
245
 * After setting up tunneling, the server sends a list of supported
246
 * authentication schemes.
247
 *
248
 * nAuthTypes specifies the number of following rfbCapabilityInfo structures
249
 * that list all supported authentication schemes in the order of preference.
250
 *
251
 * NOTE: If nAuthTypes is 0, that tells the client that no authentication is
252
 * necessary, and the client should not send a response requesting an
253
 * authentication scheme.
254
 */
255

256
typedef struct _rfbAuthenticationCapsMsg {
257
    CARD32 nAuthTypes;
258
    /* followed by nAuthTypes * rfbCapabilityInfo structures */
259
} rfbAuthenticationCapsMsg;
260

261
#define sz_rfbAuthenticationCapsMsg 4
262

263
/*-----------------------------------------------------------------------------
264
 * Authentication Scheme Request (protocol versions 3.7t, 3.8t)
265
 *
266
 * If the list of authentication capabilities sent by the server was not empty,
267
 * the client should reply with a 32-bit code specifying a particular
268
 * authentication scheme.  The following codes are supported.
269
 */
270

271
/* Standard authentication methods. */
272
#define rfbAuthNone 1
273
#define rfbAuthVNC 2
274

275
#define sig_rfbAuthNone "NOAUTH__"
276
#define sig_rfbAuthVNC "VNCAUTH_"
277

278
/* These two are not used in the mainstream version. */
279
#define rfbAuthUnixLogin 129
280
#define rfbAuthExternal 130
281

282
#define sig_rfbAuthUnixLogin "ULGNAUTH"
283
#define sig_rfbAuthExternal "XTRNAUTH"
284

285

286
/*-----------------------------------------------------------------------------
287
 * Authentication result codes (all protocol versions, but rfbAuthTooMany is
288
 * not used in protocol versions above 3.3)
289
 *
290
 * In the protocol version 3.8 and above, rfbAuthFailed is followed by a text
291
 * string describing the reason of failure. The text string is preceded with a
292
 * 32-bit counter of bytes in the string.
293
 */
294

295
#define rfbAuthOK 0
296
#define rfbAuthFailed 1
297
#define rfbAuthTooMany 2
298

299

300
/*-----------------------------------------------------------------------------
301
 * Client Initialisation Message
302
 *
303
 * Once the client and server are sure that they're happy to talk to one
304
 * another, the client sends an initialisation message.  At present this
305
 * message only consists of a boolean indicating whether the server should try
306
 * to share the desktop by leaving other clients connected, or give exclusive
307
 * access to this client by disconnecting all other clients.
308
 */
309

310
typedef struct _rfbClientInitMsg {
311
    CARD8 shared;
312
} rfbClientInitMsg;
313

314
#define sz_rfbClientInitMsg 1
315

316

317
/*-----------------------------------------------------------------------------
318
 * Server Initialisation Message
319
 *
320
 * After the client initialisation message, the server sends one of its own.
321
 * This tells the client the width and height of the server's framebuffer,
322
 * its pixel format and the name associated with the desktop.
323
 */
324

325
typedef struct _rfbServerInitMsg {
326
    CARD16 framebufferWidth;
327
    CARD16 framebufferHeight;
328
    rfbPixelFormat format;	/* the server's preferred pixel format */
329
    CARD32 nameLength;
330
    /* followed by char name[nameLength] */
331
} rfbServerInitMsg;
332

333
#define sz_rfbServerInitMsg (8 + sz_rfbPixelFormat)
334

335

336
/*-----------------------------------------------------------------------------
337
 * Server Interaction Capabilities Message (protocol versions 3.7t, 3.8t)
338
 *
339
 * If TightVNC protocol extensions are enabled, the server informs the client
340
 * what message types it supports in addition to ones defined in the standard
341
 * RFB protocol.
342
 * Also, the server sends the list of all supported encodings (note that it's
343
 * not necessary to advertise the "raw" encoding sinse it MUST be supported in
344
 * RFB 3.x protocols).
345
 *
346
 * This data immediately follows the server initialisation message.
347
 */
348

349
typedef struct _rfbInteractionCapsMsg {
350
    CARD16 nServerMessageTypes;
351
    CARD16 nClientMessageTypes;
352
    CARD16 nEncodingTypes;
353
    CARD16 pad;			/* reserved, must be 0 */
354
    /* followed by nServerMessageTypes * rfbCapabilityInfo structures */
355
    /* followed by nClientMessageTypes * rfbCapabilityInfo structures */
356
} rfbInteractionCapsMsg;
357

358
#define sz_rfbInteractionCapsMsg 8
359

360

361
/*
362
 * Following the server initialisation message it's up to the client to send
363
 * whichever protocol messages it wants.  Typically it will send a
364
 * SetPixelFormat message and a SetEncodings message, followed by a
365
 * FramebufferUpdateRequest.  From then on the server will send
366
 * FramebufferUpdate messages in response to the client's
367
 * FramebufferUpdateRequest messages.  The client should send
368
 * FramebufferUpdateRequest messages with incremental set to true when it has
369
 * finished processing one FramebufferUpdate and is ready to process another.
370
 * With a fast client, the rate at which FramebufferUpdateRequests are sent
371
 * should be regulated to avoid hogging the network.
372
 */
373

374

375

376
/*****************************************************************************
377
 *
378
 * Message types
379
 *
380
 *****************************************************************************/
381

382
/* server -> client */
383

384
#define rfbFramebufferUpdate 0
385
#define rfbSetColourMapEntries 1
386
#define rfbBell 2
387
#define rfbServerCutText 3
388

389
#define rfbFileListData 130
390
#define rfbFileDownloadData 131
391
#define rfbFileUploadCancel 132
392
#define rfbFileDownloadFailed 133
393

394
/* signatures for non-standard messages */
395
#define sig_rfbFileListData "FTS_LSDT"
396
#define sig_rfbFileDownloadData "FTS_DNDT"
397
#define sig_rfbFileUploadCancel "FTS_UPCN"
398
#define sig_rfbFileDownloadFailed "FTS_DNFL"
399

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
/* signatures for non-standard messages */
420
#define sig_rfbFileListRequest "FTC_LSRQ"
421
#define sig_rfbFileDownloadRequest "FTC_DNRQ"
422
#define sig_rfbFileUploadRequest "FTC_UPRQ"
423
#define sig_rfbFileUploadData "FTC_UPDT"
424
#define sig_rfbFileDownloadCancel "FTC_DNCN"
425
#define sig_rfbFileUploadFailed "FTC_UPFL"
426
#define sig_rfbFileCreateDirRequest "FTC_FCDR"
427

428
/*****************************************************************************
429
 *
430
 * Encoding types
431
 *
432
 *****************************************************************************/
433

434
#define rfbEncodingRaw       0
435
#define rfbEncodingCopyRect  1
436
#define rfbEncodingRRE       2
437
#define rfbEncodingCoRRE     4
438
#define rfbEncodingHextile   5
439
#define rfbEncodingZlib      6
440
#define rfbEncodingTight     7
441
#define rfbEncodingZlibHex   8
442
#define rfbEncodingZRLE     16
443

444
/* signatures for basic encoding types */
445
#define sig_rfbEncodingRaw       "RAW_____"
446
#define sig_rfbEncodingCopyRect  "COPYRECT"
447
#define sig_rfbEncodingRRE       "RRE_____"
448
#define sig_rfbEncodingCoRRE     "CORRE___"
449
#define sig_rfbEncodingHextile   "HEXTILE_"
450
#define sig_rfbEncodingZlib      "ZLIB____"
451
#define sig_rfbEncodingTight     "TIGHT___"
452
#define sig_rfbEncodingZlibHex   "ZLIBHEX_"
453
#define sig_rfbEncodingZRLE      "ZRLE____"
454

455
/*
456
 * Special encoding numbers:
457
 *   0xFFFFFF00 .. 0xFFFFFF0F -- encoding-specific compression levels;
458
 *   0xFFFFFF10 .. 0xFFFFFF1F -- mouse cursor shape data;
459
 *   0xFFFFFF20 .. 0xFFFFFF2F -- various protocol extensions;
460
 *   0xFFFFFF30 .. 0xFFFFFFDF -- not allocated yet;
461
 *   0xFFFFFFE0 .. 0xFFFFFFEF -- quality level for JPEG compressor;
462
 *   0xFFFFFFF0 .. 0xFFFFFFFF -- not allocated yet.
463
 */
464

465
#define rfbEncodingCompressLevel0  0xFFFFFF00
466
#define rfbEncodingCompressLevel1  0xFFFFFF01
467
#define rfbEncodingCompressLevel2  0xFFFFFF02
468
#define rfbEncodingCompressLevel3  0xFFFFFF03
469
#define rfbEncodingCompressLevel4  0xFFFFFF04
470
#define rfbEncodingCompressLevel5  0xFFFFFF05
471
#define rfbEncodingCompressLevel6  0xFFFFFF06
472
#define rfbEncodingCompressLevel7  0xFFFFFF07
473
#define rfbEncodingCompressLevel8  0xFFFFFF08
474
#define rfbEncodingCompressLevel9  0xFFFFFF09
475

476
#define rfbEncodingXCursor         0xFFFFFF10
477
#define rfbEncodingRichCursor      0xFFFFFF11
478
#define rfbEncodingPointerPos      0xFFFFFF18
479

480
#define rfbEncodingLastRect        0xFFFFFF20
481
#define rfbEncodingNewFBSize       0xFFFFFF21
482

483
#define rfbEncodingQualityLevel0   0xFFFFFFE0
484
#define rfbEncodingQualityLevel1   0xFFFFFFE1
485
#define rfbEncodingQualityLevel2   0xFFFFFFE2
486
#define rfbEncodingQualityLevel3   0xFFFFFFE3
487
#define rfbEncodingQualityLevel4   0xFFFFFFE4
488
#define rfbEncodingQualityLevel5   0xFFFFFFE5
489
#define rfbEncodingQualityLevel6   0xFFFFFFE6
490
#define rfbEncodingQualityLevel7   0xFFFFFFE7
491
#define rfbEncodingQualityLevel8   0xFFFFFFE8
492
#define rfbEncodingQualityLevel9   0xFFFFFFE9
493

494
/* signatures for "fake" encoding types */
495
#define sig_rfbEncodingCompressLevel0  "COMPRLVL"
496
#define sig_rfbEncodingXCursor         "X11CURSR"
497
#define sig_rfbEncodingRichCursor      "RCHCURSR"
498
#define sig_rfbEncodingPointerPos      "POINTPOS"
499
#define sig_rfbEncodingLastRect        "LASTRECT"
500
#define sig_rfbEncodingNewFBSize       "NEWFBSIZ"
501
#define sig_rfbEncodingQualityLevel0   "JPEGQLVL"
502

503

504
/*****************************************************************************
505
 *
506
 * Server -> client message definitions
507
 *
508
 *****************************************************************************/
509

510

511
/*-----------------------------------------------------------------------------
512
 * FramebufferUpdate - a block of rectangles to be copied to the framebuffer.
513
 *
514
 * This message consists of a header giving the number of rectangles of pixel
515
 * data followed by the rectangles themselves.  The header is padded so that
516
 * together with the type byte it is an exact multiple of 4 bytes (to help
517
 * with alignment of 32-bit pixels):
518
 */
519

520
typedef struct _rfbFramebufferUpdateMsg {
521
    CARD8 type;			/* always rfbFramebufferUpdate */
522
    CARD8 pad;
523
    CARD16 nRects;
524
    /* followed by nRects rectangles */
525
} rfbFramebufferUpdateMsg;
526

527
#define sz_rfbFramebufferUpdateMsg 4
528

529
/*
530
 * Each rectangle of pixel data consists of a header describing the position
531
 * and size of the rectangle and a type word describing the encoding of the
532
 * pixel data, followed finally by the pixel data.  Note that if the client has
533
 * not sent a SetEncodings message then it will only receive raw pixel data.
534
 * Also note again that this structure is a multiple of 4 bytes.
535
 */
536

537
typedef struct _rfbFramebufferUpdateRectHeader {
538
    rfbRectangle r;
539
    CARD32 encoding;		/* one of the encoding types rfbEncoding... */
540
} rfbFramebufferUpdateRectHeader;
541

542
#define sz_rfbFramebufferUpdateRectHeader (sz_rfbRectangle + 4)
543

544

545
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
546
 * Raw Encoding.  Pixels are sent in top-to-bottom scanline order,
547
 * left-to-right within a scanline with no padding in between.
548
 */
549

550

551
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
552
 * CopyRect Encoding.  The pixels are specified simply by the x and y position
553
 * of the source rectangle.
554
 */
555

556
typedef struct _rfbCopyRect {
557
    CARD16 srcX;
558
    CARD16 srcY;
559
} rfbCopyRect;
560

561
#define sz_rfbCopyRect 4
562

563

564
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
565
 * RRE - Rise-and-Run-length Encoding.  We have an rfbRREHeader structure
566
 * giving the number of subrectangles following.  Finally the data follows in
567
 * the form [<bgpixel><subrect><subrect>...] where each <subrect> is
568
 * [<pixel><rfbRectangle>].
569
 */
570

571
typedef struct _rfbRREHeader {
572
    CARD32 nSubrects;
573
} rfbRREHeader;
574

575
#define sz_rfbRREHeader 4
576

577

578
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
579
 * CoRRE - Compact RRE Encoding.  We have an rfbRREHeader structure giving
580
 * the number of subrectangles following.  Finally the data follows in the form
581
 * [<bgpixel><subrect><subrect>...] where each <subrect> is
582
 * [<pixel><rfbCoRRERectangle>].  This means that
583
 * the whole rectangle must be at most 255x255 pixels.
584
 */
585

586
typedef struct _rfbCoRRERectangle {
587
    CARD8 x;
588
    CARD8 y;
589
    CARD8 w;
590
    CARD8 h;
591
} rfbCoRRERectangle;
592

593
#define sz_rfbCoRRERectangle 4
594

595

596
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
597
 * Hextile Encoding.  The rectangle is divided up into "tiles" of 16x16 pixels,
598
 * starting at the top left going in left-to-right, top-to-bottom order.  If
599
 * the width of the rectangle is not an exact multiple of 16 then the width of
600
 * the last tile in each row will be correspondingly smaller.  Similarly if the
601
 * height is not an exact multiple of 16 then the height of each tile in the
602
 * final row will also be smaller.  Each tile begins with a "subencoding" type
603
 * byte, which is a mask made up of a number of bits.  If the Raw bit is set
604
 * then the other bits are irrelevant; w*h pixel values follow (where w and h
605
 * are the width and height of the tile).  Otherwise the tile is encoded in a
606
 * similar way to RRE, except that the position and size of each subrectangle
607
 * can be specified in just two bytes.  The other bits in the mask are as
608
 * follows:
609
 *
610
 * BackgroundSpecified - if set, a pixel value follows which specifies
611
 *    the background colour for this tile.  The first non-raw tile in a
612
 *    rectangle must have this bit set.  If this bit isn't set then the
613
 *    background is the same as the last tile.
614
 *
615
 * ForegroundSpecified - if set, a pixel value follows which specifies
616
 *    the foreground colour to be used for all subrectangles in this tile.
617
 *    If this bit is set then the SubrectsColoured bit must be zero.
618
 *
619
 * AnySubrects - if set, a single byte follows giving the number of
620
 *    subrectangles following.  If not set, there are no subrectangles (i.e.
621
 *    the whole tile is just solid background colour).
622
 *
623
 * SubrectsColoured - if set then each subrectangle is preceded by a pixel
624
 *    value giving the colour of that subrectangle.  If not set, all
625
 *    subrectangles are the same colour, the foreground colour;  if the
626
 *    ForegroundSpecified bit wasn't set then the foreground is the same as
627
 *    the last tile.
628
 *
629
 * The position and size of each subrectangle is specified in two bytes.  The
630
 * Pack macros below can be used to generate the two bytes from x, y, w, h,
631
 * and the Extract macros can be used to extract the x, y, w, h values from
632
 * the two bytes.
633
 */
634

635
#define rfbHextileRaw			(1 << 0)
636
#define rfbHextileBackgroundSpecified	(1 << 1)
637
#define rfbHextileForegroundSpecified	(1 << 2)
638
#define rfbHextileAnySubrects		(1 << 3)
639
#define rfbHextileSubrectsColoured	(1 << 4)
640

641
#define rfbHextilePackXY(x,y) (((x) << 4) | (y))
642
#define rfbHextilePackWH(w,h) ((((w)-1) << 4) | ((h)-1))
643
#define rfbHextileExtractX(byte) ((byte) >> 4)
644
#define rfbHextileExtractY(byte) ((byte) & 0xf)
645
#define rfbHextileExtractW(byte) (((byte) >> 4) + 1)
646
#define rfbHextileExtractH(byte) (((byte) & 0xf) + 1)
647

648
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
649
 * ZLIB - zlib compression Encoding.  We have an rfbZlibHeader structure
650
 * giving the number of bytes to follow.  Finally the data follows in
651
 * zlib compressed format.
652
 */
653

654
typedef struct _rfbZlibHeader {
655
    CARD32 nBytes;
656
} rfbZlibHeader;
657

658
#define sz_rfbZlibHeader 4
659

660

661
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
662
 * Tight Encoding.
663
 *
664
 *-- The first byte of each Tight-encoded rectangle is a "compression control
665
 *   byte". Its format is as follows (bit 0 is the least significant one):
666
 *
667
 *   bit 0:    if 1, then compression stream 0 should be reset;
668
 *   bit 1:    if 1, then compression stream 1 should be reset;
669
 *   bit 2:    if 1, then compression stream 2 should be reset;
670
 *   bit 3:    if 1, then compression stream 3 should be reset;
671
 *   bits 7-4: if 1000 (0x08), then the compression type is "fill",
672
 *             if 1001 (0x09), then the compression type is "jpeg",
673
 *             if 0xxx, then the compression type is "basic",
674
 *             values greater than 1001 are not valid.
675
 *
676
 * If the compression type is "basic", then bits 6..4 of the
677
 * compression control byte (those xxx in 0xxx) specify the following:
678
 *
679
 *   bits 5-4:  decimal representation is the index of a particular zlib
680
 *              stream which should be used for decompressing the data;
681
 *   bit 6:     if 1, then a "filter id" byte is following this byte.
682
 *
683
 *-- The data that follows after the compression control byte described
684
 * above depends on the compression type ("fill", "jpeg" or "basic").
685
 *
686
 *-- If the compression type is "fill", then the only pixel value follows, in
687
 * client pixel format (see NOTE 1). This value applies to all pixels of the
688
 * rectangle.
689
 *
690
 *-- If the compression type is "jpeg", the following data stream looks like
691
 * this:
692
 *
693
 *   1..3 bytes:  data size (N) in compact representation;
694
 *   N bytes:     JPEG image.
695
 *
696
 * Data size is compactly represented in one, two or three bytes, according
697
 * to the following scheme:
698
 *
699
 *  0xxxxxxx                    (for values 0..127)
700
 *  1xxxxxxx 0yyyyyyy           (for values 128..16383)
701
 *  1xxxxxxx 1yyyyyyy zzzzzzzz  (for values 16384..4194303)
702
 *
703
 * Here each character denotes one bit, xxxxxxx are the least significant 7
704
 * bits of the value (bits 0-6), yyyyyyy are bits 7-13, and zzzzzzzz are the
705
 * most significant 8 bits (bits 14-21). For example, decimal value 10000
706
 * should be represented as two bytes: binary 10010000 01001110, or
707
 * hexadecimal 90 4E.
708
 *
709
 *-- If the compression type is "basic" and bit 6 of the compression control
710
 * byte was set to 1, then the next (second) byte specifies "filter id" which
711
 * tells the decoder what filter type was used by the encoder to pre-process
712
 * pixel data before the compression. The "filter id" byte can be one of the
713
 * following:
714
 *
715
 *   0:  no filter ("copy" filter);
716
 *   1:  "palette" filter;
717
 *   2:  "gradient" filter.
718
 *
719
 *-- If bit 6 of the compression control byte is set to 0 (no "filter id"
720
 * byte), or if the filter id is 0, then raw pixel values in the client
721
 * format (see NOTE 1) will be compressed. See below details on the
722
 * compression.
723
 *
724
 *-- The "gradient" filter pre-processes pixel data with a simple algorithm
725
 * which converts each color component to a difference between a "predicted"
726
 * intensity and the actual intensity. Such a technique does not affect
727
 * uncompressed data size, but helps to compress photo-like images better. 
728
 * Pseudo-code for converting intensities to differences is the following:
729
 *
730
 *   P[i,j] := V[i-1,j] + V[i,j-1] - V[i-1,j-1];
731
 *   if (P[i,j] < 0) then P[i,j] := 0;
732
 *   if (P[i,j] > MAX) then P[i,j] := MAX;
733
 *   D[i,j] := V[i,j] - P[i,j];
734
 *
735
 * Here V[i,j] is the intensity of a color component for a pixel at
736
 * coordinates (i,j). MAX is the maximum value of intensity for a color
737
 * component.
738
 *
739
 *-- The "palette" filter converts true-color pixel data to indexed colors
740
 * and a palette which can consist of 2..256 colors. If the number of colors
741
 * is 2, then each pixel is encoded in 1 bit, otherwise 8 bits is used to
742
 * encode one pixel. 1-bit encoding is performed such way that the most
743
 * significant bits correspond to the leftmost pixels, and each raw of pixels
744
 * is aligned to the byte boundary. When "palette" filter is used, the
745
 * palette is sent before the pixel data. The palette begins with an unsigned
746
 * byte which value is the number of colors in the palette minus 1 (i.e. 1
747
 * means 2 colors, 255 means 256 colors in the palette). Then follows the
748
 * palette itself which consist of pixel values in client pixel format (see
749
 * NOTE 1).
750
 *
751
 *-- The pixel data is compressed using the zlib library. But if the data
752
 * size after applying the filter but before the compression is less then 12,
753
 * then the data is sent as is, uncompressed. Four separate zlib streams
754
 * (0..3) can be used and the decoder should read the actual stream id from
755
 * the compression control byte (see NOTE 2).
756
 *
757
 * If the compression is not used, then the pixel data is sent as is,
758
 * otherwise the data stream looks like this:
759
 *
760
 *   1..3 bytes:  data size (N) in compact representation;
761
 *   N bytes:     zlib-compressed data.
762
 *
763
 * Data size is compactly represented in one, two or three bytes, just like
764
 * in the "jpeg" compression method (see above).
765
 *
766
 *-- NOTE 1. If the color depth is 24, and all three color components are
767
 * 8-bit wide, then one pixel in Tight encoding is always represented by
768
 * three bytes, where the first byte is red component, the second byte is
769
 * green component, and the third byte is blue component of the pixel color
770
 * value. This applies to colors in palettes as well.
771
 *
772
 *-- NOTE 2. The decoder must reset compression streams' states before
773
 * decoding the rectangle, if some of bits 0,1,2,3 in the compression control
774
 * byte are set to 1. Note that the decoder must reset zlib streams even if
775
 * the compression type is "fill" or "jpeg".
776
 *
777
 *-- NOTE 3. The "gradient" filter and "jpeg" compression may be used only
778
 * when bits-per-pixel value is either 16 or 32, not 8.
779
 *
780
 *-- NOTE 4. The width of any Tight-encoded rectangle cannot exceed 2048
781
 * pixels. If a rectangle is wider, it must be split into several rectangles
782
 * and each one should be encoded separately.
783
 *
784
 */
785

786
#define rfbTightExplicitFilter         0x04
787
#define rfbTightFill                   0x08
788
#define rfbTightJpeg                   0x09
789
#define rfbTightMaxSubencoding         0x09
790

791
/* Filters to improve compression efficiency */
792
#define rfbTightFilterCopy             0x00
793
#define rfbTightFilterPalette          0x01
794
#define rfbTightFilterGradient         0x02
795

796

797
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
798
 * ZLIBHEX - zlib compressed Hextile Encoding.  Essentially, this is the
799
 * hextile encoding with zlib compression on the tiles that can not be
800
 * efficiently encoded with one of the other hextile subencodings.  The
801
 * new zlib subencoding uses two bytes to specify the length of the
802
 * compressed tile and then the compressed data follows.  As with the
803
 * raw sub-encoding, the zlib subencoding invalidates the other
804
 * values, if they are also set.
805
 */
806

807
#define rfbHextileZlibRaw		(1 << 5)
808
#define rfbHextileZlibHex		(1 << 6)
809

810

811
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
812
 * XCursor encoding. This is a special encoding used to transmit X-style
813
 * cursor shapes from server to clients. Note that for this encoding,
814
 * coordinates in rfbFramebufferUpdateRectHeader structure hold hotspot
815
 * position (r.x, r.y) and cursor size (r.w, r.h). If (w * h != 0), two RGB
816
 * samples are sent after header in the rfbXCursorColors structure. They
817
 * denote foreground and background colors of the cursor. If a client
818
 * supports only black-and-white cursors, it should ignore these colors and
819
 * assume that foreground is black and background is white. Next, two bitmaps
820
 * (1 bits per pixel) follow: first one with actual data (value 0 denotes
821
 * background color, value 1 denotes foreground color), second one with
822
 * transparency data (bits with zero value mean that these pixels are
823
 * transparent). Both bitmaps represent cursor data in a byte stream, from
824
 * left to right, from top to bottom, and each row is byte-aligned. Most
825
 * significant bits correspond to leftmost pixels. The number of bytes in
826
 * each row can be calculated as ((w + 7) / 8). If (w * h == 0), cursor
827
 * should be hidden (or default local cursor should be set by the client).
828
 */
829

830
typedef struct _rfbXCursorColors {
831
    CARD8 foreRed;
832
    CARD8 foreGreen;
833
    CARD8 foreBlue;
834
    CARD8 backRed;
835
    CARD8 backGreen;
836
    CARD8 backBlue;
837
} rfbXCursorColors;
838

839
#define sz_rfbXCursorColors 6
840

841

842
/*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
843
 * RichCursor encoding. This is a special encoding used to transmit cursor
844
 * shapes from server to clients. It is similar to the XCursor encoding but
845
 * uses client pixel format instead of two RGB colors to represent cursor
846
 * image. For this encoding, coordinates in rfbFramebufferUpdateRectHeader
847
 * structure hold hotspot position (r.x, r.y) and cursor size (r.w, r.h).
848
 * After header, two pixmaps follow: first one with cursor image in current
849
 * client pixel format (like in raw encoding), second with transparency data
850
 * (1 bit per pixel, exactly the same format as used for transparency bitmap
851
 * in the XCursor encoding). If (w * h == 0), cursor should be hidden (or
852
 * default local cursor should be set by the client).
853
 */
854

855

856
/*-----------------------------------------------------------------------------
857
 * SetColourMapEntries - these messages are only sent if the pixel
858
 * format uses a "colour map" (i.e. trueColour false) and the client has not
859
 * fixed the entire colour map using FixColourMapEntries.  In addition they
860
 * will only start being sent after the client has sent its first
861
 * FramebufferUpdateRequest.  So if the client always tells the server to use
862
 * trueColour then it never needs to process this type of message.
863
 */
864

865
typedef struct _rfbSetColourMapEntriesMsg {
866
    CARD8 type;			/* always rfbSetColourMapEntries */
867
    CARD8 pad;
868
    CARD16 firstColour;
869
    CARD16 nColours;
870

871
    /* Followed by nColours * 3 * CARD16
872
       r1, g1, b1, r2, g2, b2, r3, g3, b3, ..., rn, bn, gn */
873

874
} rfbSetColourMapEntriesMsg;
875

876
#define sz_rfbSetColourMapEntriesMsg 6
877

878

879

880
/*-----------------------------------------------------------------------------
881
 * Bell - ring a bell on the client if it has one.
882
 */
883

884
typedef struct _rfbBellMsg {
885
    CARD8 type;			/* always rfbBell */
886
} rfbBellMsg;
887

888
#define sz_rfbBellMsg 1
889

890

891

892
/*-----------------------------------------------------------------------------
893
 * ServerCutText - the server has new text in its cut buffer.
894
 */
895

896
typedef struct _rfbServerCutTextMsg {
897
    CARD8 type;			/* always rfbServerCutText */
898
    CARD8 pad1;
899
    CARD16 pad2;
900
    CARD32 length;
901
    /* followed by char text[length] */
902
} rfbServerCutTextMsg;
903

904
#define sz_rfbServerCutTextMsg 8
905

906
/*-----------------------------------------------------------------------------
907
 * FileListData
908
 */
909

910
typedef struct _rfbFileListDataMsg {
911
    CARD8 type;
912
    CARD8 flags;
913
    CARD16 numFiles;
914
    CARD16 dataSize;
915
    CARD16 compressedSize;
916
    /* Followed by SizeData[numFiles] */
917
    /* Followed by Filenames[compressedSize] */
918
} rfbFileListDataMsg;
919

920
#define sz_rfbFileListDataMsg 8
921

922
/*-----------------------------------------------------------------------------
923
 * FileDownloadData
924
 */
925

926
typedef struct _rfbFileDownloadDataMsg {
927
    CARD8 type;
928
    CARD8 compressLevel;
929
    CARD16 realSize;
930
    CARD16 compressedSize;
931
    /* Followed by File[copressedSize], 
932
       but if (realSize = compressedSize = 0) followed by CARD32 modTime  */
933
} rfbFileDownloadDataMsg;
934

935
#define sz_rfbFileDownloadDataMsg 6
936

937

938
/*-----------------------------------------------------------------------------
939
 * FileUploadCancel
940
 */
941

942
typedef struct _rfbFileUploadCancelMsg {
943
    CARD8 type;
944
    CARD8 unused;
945
    CARD16 reasonLen;
946
    /* Followed by reason[reasonLen] */
947
} rfbFileUploadCancelMsg;
948

949
#define sz_rfbFileUploadCancelMsg 4
950

951
/*-----------------------------------------------------------------------------
952
 * FileDownloadFailed
953
 */
954

955
typedef struct _rfbFileDownloadFailedMsg {
956
    CARD8 type;
957
    CARD8 unused;
958
    CARD16 reasonLen;
959
    /* Followed by reason[reasonLen] */
960
} rfbFileDownloadFailedMsg;
961

962
#define sz_rfbFileDownloadFailedMsg 4
963

964
/*-----------------------------------------------------------------------------
965
 * Union of all server->client messages.
966
 */
967

968
typedef union _rfbServerToClientMsg {
969
    CARD8 type;
970
    rfbFramebufferUpdateMsg fu;
971
    rfbSetColourMapEntriesMsg scme;
972
    rfbBellMsg b;
973
    rfbServerCutTextMsg sct;
974
    rfbFileListDataMsg fld;
975
    rfbFileDownloadDataMsg fdd;
976
    rfbFileUploadCancelMsg fuc;
977
    rfbFileDownloadFailedMsg fdf;
978
} rfbServerToClientMsg;
979

980

981

982
/*****************************************************************************
983
 *
984
 * Message definitions (client -> server)
985
 *
986
 *****************************************************************************/
987

988

989
/*-----------------------------------------------------------------------------
990
 * SetPixelFormat - tell the RFB server the format in which the client wants
991
 * pixels sent.
992
 */
993

994
typedef struct _rfbSetPixelFormatMsg {
995
    CARD8 type;			/* always rfbSetPixelFormat */
996
    CARD8 pad1;
997
    CARD16 pad2;
998
    rfbPixelFormat format;
999
} rfbSetPixelFormatMsg;
1000

1001
#define sz_rfbSetPixelFormatMsg (sz_rfbPixelFormat + 4)
1002

1003

1004
/*-----------------------------------------------------------------------------
1005
 * FixColourMapEntries - when the pixel format uses a "colour map", fix
1006
 * read-only colour map entries.
1007
 *
1008
 *    ***************** NOT CURRENTLY SUPPORTED *****************
1009
 */
1010

1011
typedef struct _rfbFixColourMapEntriesMsg {
1012
    CARD8 type;			/* always rfbFixColourMapEntries */
1013
    CARD8 pad;
1014
    CARD16 firstColour;
1015
    CARD16 nColours;
1016

1017
    /* Followed by nColours * 3 * CARD16
1018
       r1, g1, b1, r2, g2, b2, r3, g3, b3, ..., rn, bn, gn */
1019

1020
} rfbFixColourMapEntriesMsg;
1021

1022
#define sz_rfbFixColourMapEntriesMsg 6
1023

1024

1025
/*-----------------------------------------------------------------------------
1026
 * SetEncodings - tell the RFB server which encoding types we accept.  Put them
1027
 * in order of preference, if we have any.  We may always receive raw
1028
 * encoding, even if we don't specify it here.
1029
 */
1030

1031
typedef struct _rfbSetEncodingsMsg {
1032
    CARD8 type;			/* always rfbSetEncodings */
1033
    CARD8 pad;
1034
    CARD16 nEncodings;
1035
    /* followed by nEncodings * CARD32 encoding types */
1036
} rfbSetEncodingsMsg;
1037

1038
#define sz_rfbSetEncodingsMsg 4
1039

1040

1041
/*-----------------------------------------------------------------------------
1042
 * FramebufferUpdateRequest - request for a framebuffer update.  If incremental
1043
 * is true then the client just wants the changes since the last update.  If
1044
 * false then it wants the whole of the specified rectangle.
1045
 */
1046

1047
typedef struct _rfbFramebufferUpdateRequestMsg {
1048
    CARD8 type;			/* always rfbFramebufferUpdateRequest */
1049
    CARD8 incremental;
1050
    CARD16 x;
1051
    CARD16 y;
1052
    CARD16 w;
1053
    CARD16 h;
1054
} rfbFramebufferUpdateRequestMsg;
1055

1056
#define sz_rfbFramebufferUpdateRequestMsg 10
1057

1058

1059
/*-----------------------------------------------------------------------------
1060
 * KeyEvent - key press or release
1061
 *
1062
 * Keys are specified using the "keysym" values defined by the X Window System.
1063
 * For most ordinary keys, the keysym is the same as the corresponding ASCII
1064
 * value.  Other common keys are:
1065
 *
1066
 * BackSpace		0xff08
1067
 * Tab			0xff09
1068
 * Return or Enter	0xff0d
1069
 * Escape		0xff1b
1070
 * Insert		0xff63
1071
 * Delete		0xffff
1072
 * Home			0xff50
1073
 * End			0xff57
1074
 * Page Up		0xff55
1075
 * Page Down		0xff56
1076
 * Left			0xff51
1077
 * Up			0xff52
1078
 * Right		0xff53
1079
 * Down			0xff54
1080
 * F1			0xffbe
1081
 * F2			0xffbf
1082
 * ...			...
1083
 * F12			0xffc9
1084
 * Shift		0xffe1
1085
 * Control		0xffe3
1086
 * Meta			0xffe7
1087
 * Alt			0xffe9
1088
 */
1089

1090
typedef struct _rfbKeyEventMsg {
1091
    CARD8 type;			/* always rfbKeyEvent */
1092
    CARD8 down;			/* true if down (press), false if up */
1093
    CARD16 pad;
1094
    CARD32 key;			/* key is specified as an X keysym */
1095
} rfbKeyEventMsg;
1096

1097
#define sz_rfbKeyEventMsg 8
1098

1099

1100
/*-----------------------------------------------------------------------------
1101
 * PointerEvent - mouse/pen move and/or button press.
1102
 */
1103

1104
typedef struct _rfbPointerEventMsg {
1105
    CARD8 type;			/* always rfbPointerEvent */
1106
    CARD8 buttonMask;		/* bits 0-7 are buttons 1-8, 0=up, 1=down */
1107
    CARD16 x;
1108
    CARD16 y;
1109
} rfbPointerEventMsg;
1110

1111
#define rfbButton1Mask 1
1112
#define rfbButton2Mask 2
1113
#define rfbButton3Mask 4
1114
#define rfbButton4Mask 8
1115
#define rfbButton5Mask 16
1116

1117
#define sz_rfbPointerEventMsg 6
1118

1119

1120

1121
/*-----------------------------------------------------------------------------
1122
 * ClientCutText - the client has new text in its cut buffer.
1123
 */
1124

1125
typedef struct _rfbClientCutTextMsg {
1126
    CARD8 type;			/* always rfbClientCutText */
1127
    CARD8 pad1;
1128
    CARD16 pad2;
1129
    CARD32 length;
1130
    /* followed by char text[length] */
1131
} rfbClientCutTextMsg;
1132

1133
#define sz_rfbClientCutTextMsg 8
1134

1135
/*-----------------------------------------------------------------------------
1136
 * FileListRequest
1137
 */
1138

1139
typedef struct _rfbFileListRequestMsg {
1140
    CARD8 type;
1141
    CARD8 flags;
1142
    CARD16 dirNameSize;
1143
    /* Followed by char Dirname[dirNameSize] */
1144
} rfbFileListRequestMsg;
1145

1146
#define sz_rfbFileListRequestMsg 4
1147

1148
/*-----------------------------------------------------------------------------
1149
 * FileDownloadRequest
1150
 */
1151

1152
typedef struct _rfbFileDownloadRequestMsg {
1153
    CARD8 type;
1154
    CARD8 compressedLevel;
1155
    CARD16 fNameSize;
1156
    CARD32 position;
1157
    /* Followed by char Filename[fNameSize] */
1158
} rfbFileDownloadRequestMsg;
1159

1160
#define sz_rfbFileDownloadRequestMsg 8
1161

1162
/*-----------------------------------------------------------------------------
1163
 * FileUploadRequest
1164
 */
1165

1166
typedef struct _rfbFileUploadRequestMsg {
1167
    CARD8 type;
1168
    CARD8 compressedLevel;
1169
    CARD16 fNameSize;
1170
    CARD32 position;
1171
    /* Followed by char Filename[fNameSize] */
1172
} rfbFileUploadRequestMsg;
1173

1174
#define sz_rfbFileUploadRequestMsg 8
1175

1176

1177
/*-----------------------------------------------------------------------------
1178
 * FileUploadData
1179
 */
1180

1181
typedef struct _rfbFileUploadDataMsg {
1182
    CARD8 type;
1183
    CARD8 compressedLevel;
1184
    CARD16 realSize;
1185
    CARD16 compressedSize;
1186
    /* Followed by File[compressedSize], 
1187
       but if (realSize = compressedSize = 0) followed by CARD32 modTime  */
1188
} rfbFileUploadDataMsg;
1189

1190
#define sz_rfbFileUploadDataMsg 6
1191

1192
/*-----------------------------------------------------------------------------
1193
 * FileDownloadCancel
1194
 */
1195

1196
typedef struct _rfbFileDownloadCancelMsg {
1197
    CARD8 type;
1198
    CARD8 unused;
1199
    CARD16 reasonLen;
1200
    /* Followed by reason[reasonLen] */
1201
} rfbFileDownloadCancelMsg;
1202

1203
#define sz_rfbFileDownloadCancelMsg 4
1204

1205
/*-----------------------------------------------------------------------------
1206
 * FileUploadFailed
1207
 */
1208

1209
typedef struct _rfbFileUploadFailedMsg {
1210
    CARD8 type;
1211
    CARD8 unused;
1212
    CARD16 reasonLen;
1213
    /* Followed by reason[reasonLen] */
1214
} rfbFileUploadFailedMsg;
1215

1216
#define sz_rfbFileUploadFailedMsg 4
1217

1218
/*-----------------------------------------------------------------------------
1219
 * FileCreateDirRequest
1220
 */
1221

1222
typedef struct _rfbFileCreateDirRequestMsg {
1223
    CARD8 type;
1224
    CARD8 unused;
1225
    CARD16 dNameLen;
1226
    /* Followed by dName[dNameLen] */
1227
} rfbFileCreateDirRequestMsg;
1228

1229
#define sz_rfbFileCreateDirRequestMsg 4
1230

1231
/*-----------------------------------------------------------------------------
1232
 * Union of all client->server messages.
1233
 */
1234

1235
typedef union _rfbClientToServerMsg {
1236
    CARD8 type;
1237
    rfbSetPixelFormatMsg spf;
1238
    rfbFixColourMapEntriesMsg fcme;
1239
    rfbSetEncodingsMsg se;
1240
    rfbFramebufferUpdateRequestMsg fur;
1241
    rfbKeyEventMsg ke;
1242
    rfbPointerEventMsg pe;
1243
    rfbClientCutTextMsg cct;
1244
    rfbFileListRequestMsg flr;
1245
    rfbFileDownloadRequestMsg fdr;
1246
    rfbFileUploadRequestMsg fupr;
1247
    rfbFileUploadDataMsg fud;
1248
    rfbFileDownloadCancelMsg fdc;
1249
    rfbFileUploadFailedMsg fuf;
1250
    rfbFileCreateDirRequestMsg fcdr;
1251
} rfbClientToServerMsg;
1252

1253