rfbproto.h

   1 #ifndef _RFBPROTO_H
   2 #define _RFBPROTO_H
   3
   4 #include <sys/types.h>
   5
   6 #define CARD8 u_int8_t
   7 #define INT8    int8_t
   8 #define CARD16 u_int16_t
   9 #define INT16    int16_t
  10 #define CARD32 u_int32_t
  11 #define INT32    int32_t
  12 /*
  13  *  Copyright (C) 1997, 1998 Olivetti & Oracle Research Laboratory
  14  *
  15  *  This is free software; you can redistribute it and/or modify
  16  *  it under the terms of the GNU General Public License as published by
  17  *  the Free Software Foundation; either version 2 of the License, or
  18  *  (at your option) any later version.
  19  *
  20  *  This software is distributed in the hope that it will be useful,
  21  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
  22  *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  23  *  GNU General Public License for more details.
  24  *
  25  *  You should have received a copy of the GNU General Public License
  26  *  along with this software; if not, write to the Free Software
  27  *  Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307,
  28  *  USA.
  29  */
  30
  31 /*
  32  * rfbproto.h - header file for the RFB protocol version 3.3
  33  *
  34  * Uses types CARD<n> for an n-bit unsigned integer, INT<n> for an n-bit signed
  35  * integer (for n = 8, 16 and 32).
  36  *
  37  * All multiple byte integers are in big endian (network) order (most
  38  * significant byte first).  Unless noted otherwise there is no special
  39  * alignment of protocol structures.
  40  *
  41  *
  42  * Once the initial handshaking is done, all messages start with a type byte,
  43  * (usually) followed by message-specific data.  The order of definitions in
  44  * this file is as follows:
  45  *
  46  *  (1) Structures used in several types of message.
  47  *  (2) Structures used in the initial handshaking.
  48  *  (3) Message types.
  49  *  (4) Encoding types.
  50  *  (5) For each message type, the form of the data following the type byte.
  51  *      Sometimes this is defined by a single structure but the more complex
  52  *      messages have to be explained by comments.
  53  */
  54
  55
  56 /*****************************************************************************
  57  *
  58  * Structures used in several messages
  59  *
  60  *****************************************************************************/
  61
  62 /*-----------------------------------------------------------------------------
  63  * Structure used to specify a rectangle.  This structure is a multiple of 4
  64  * bytes so that it can be interspersed with 32-bit pixel data without
  65  * affecting alignment.
  66  */
  67
  68 typedef struct {
  69     CARD16 x;
  70     CARD16 y;
  71     CARD16 w;
  72     CARD16 h;
  73 } rfbRectangle;
  74
  75 #define sz_rfbRectangle 8
  76
  77
  78 /*-----------------------------------------------------------------------------
  79  * Structure used to specify pixel format.
  80  */
  81
  82 typedef struct {
  83
  84     CARD8 bitsPerPixel;     /* 8,16,32 only */
  85
  86     CARD8 depth;        /* 8 to 32 */
  87
  88     CARD8 bigEndian;        /* True if multi-byte pixels are interpreted
  89                    as big endian, or if single-bit-per-pixel
  90                    has most significant bit of the byte
  91                    corresponding to first (leftmost) pixel. Of
  92                    course this is meaningless for 8 bits/pix */
  93
  94     CARD8 trueColour;       /* If false then we need a 'colour map' to
  95                    convert pixels to RGB.  If true, xxxMax and
  96                    xxxShift specify bits used for red, green
  97                    and blue */
  98
  99     /* the following fields are only meaningful if trueColour is true */
 100
 101     CARD16 redMax;      /* maximum red value (= 2^n - 1 where n is the
 102                    number of bits used for red). Note this
 103                    value is always in big endian order. */
 104
 105     CARD16 greenMax;        /* similar for green */
 106
 107     CARD16 blueMax;     /* and blue */
 108
 109     CARD8 redShift;     /* number of shifts needed to get the red
 110                    value in a pixel to the least significant
 111                    bit. To find the red value from a given
 112                    pixel, do the following:
 113                    1) Swap pixel value according to bigEndian
 114                       (e.g. if bigEndian is false and host byte
 115                       order is big endian, then swap).
 116                    2) Shift right by redShift.
 117                    3) AND with redMax (in host byte order).
 118                    4) You now have the red value between 0 and
 119                       redMax. */
 120
 121     CARD8 greenShift;       /* similar for green */
 122
 123     CARD8 blueShift;        /* and blue */
 124
 125     CARD8 pad1;
 126     CARD16 pad2;
 127
 128 } rfbPixelFormat;
 129
 130 #define sz_rfbPixelFormat 16
 131
 132
 133
 134 /*****************************************************************************
 135  *
 136  * Initial handshaking messages
 137  *
 138  *****************************************************************************/
 139
 140 /*-----------------------------------------------------------------------------
 141  * Protocol Version
 142  *
 143  * The server always sends 12 bytes to start which identifies the latest RFB
 144  * protocol version number which it supports.  These bytes are interpreted
 145  * as a string of 12 ASCII characters in the format 'RFB xxx.yyy\n' where
 146  * xxx and yyy are the major and minor version numbers (for version 3.3
 147  * this is 'RFB 003.003\n').
 148  *
 149  * The client then replies with a similar 12-byte message giving the version
 150  * number of the protocol which should actually be used (which may be different
 151  * to that quoted by the server).
 152  *
 153  * It is intended that both clients and servers may provide some level of
 154  * backwards compatibility by this mechanism.  Servers in particular should
 155  * attempt to provide backwards compatibility, and even forwards compatibility
 156  * to some extent.  For example if a client demands version 3.1 of the
 157  * protocol, a 3.0 server can probably assume that by ignoring requests for
 158  * encoding types it doesn't understand, everything will still work OK.  This
 159  * will probably not be the case for changes in the major version number.
 160  *
 161  * The format string below can be used in sprintf or sscanf to generate or
 162  * decode the version string respectively.
 163  */
 164
 165 #define rfbProtocolVersionFormat "RFB %03d.%03d\n"
 166 #define rfbProtocolMajorVersion 3
 167 #define rfbProtocolMinorVersion 3
 168
 169 typedef char rfbProtocolVersionMsg[13]; /* allow extra byte for null */
 170
 171 #define sz_rfbProtocolVersionMsg 12
 172
 173
 174 /*-----------------------------------------------------------------------------
 175  * Authentication
 176  *
 177  * Once the protocol version has been decided, the server then sends a 32-bit
 178  * word indicating whether any authentication is needed on the connection.
 179  * The value of this word determines the authentication scheme in use.  For
 180  * version 3.0 of the protocol this may have one of the following values:
 181  */
 182
 183 #define rfbConnFailed 0
 184 #define rfbNoAuth 1
 185 #define rfbVncAuth 2
 186
 187 /*
 188  * rfbConnFailed:   For some reason the connection failed (e.g. the server
 189  *          cannot support the desired protocol version).  This is
 190  *          followed by a string describing the reason (where a
 191  *          string is specified as a 32-bit length followed by that
 192  *          many ASCII characters).
 193  *
 194  * rfbNoAuth:       No authentication is needed.
 195  *
 196  * rfbVncAuth:      The VNC authentication scheme is to be used.  A 16-byte
 197  *          challenge follows, which the client encrypts as
 198  *          appropriate using the password and sends the resulting
 199  *          16-byte response.  If the response is correct, the
 200  *          server sends the 32-bit word rfbVncAuthOK.  If a simple
 201  *          failure happens, the server sends rfbVncAuthFailed and
 202  *          closes the connection. If the server decides that too
 203  *          many failures have occurred, it sends rfbVncAuthTooMany
 204  *          and closes the connection.  In the latter case, the
 205  *          server should not allow an immediate reconnection by
 206  *          the client.
 207  */
 208
 209 #define rfbVncAuthOK 0
 210 #define rfbVncAuthFailed 1
 211 #define rfbVncAuthTooMany 2
 212
 213
 214 /*-----------------------------------------------------------------------------
 215  * Client Initialisation Message
 216  *
 217  * Once the client and server are sure that they're happy to talk to one
 218  * another, the client sends an initialisation message.  At present this
 219  * message only consists of a boolean indicating whether the server should try
 220  * to share the desktop by leaving other clients connected, or give exclusive
 221  * access to this client by disconnecting all other clients.
 222  */
 223
 224 typedef struct {
 225     CARD8 shared;
 226 } rfbClientInitMsg;
 227
 228 #define sz_rfbClientInitMsg 1
 229
 230
 231 /*-----------------------------------------------------------------------------
 232  * Server Initialisation Message
 233  *
 234  * After the client initialisation message, the server sends one of its own.
 235  * This tells the client the width and height of the server's framebuffer,
 236  * its pixel format and the name associated with the desktop.
 237  */
 238
 239 typedef struct {
 240     CARD16 framebufferWidth;
 241     CARD16 framebufferHeight;
 242     rfbPixelFormat format;  /* the server's preferred pixel format */
 243     CARD32 nameLength;
 244     /* followed by char name[nameLength] */
 245 } rfbServerInitMsg;
 246
 247 #define sz_rfbServerInitMsg (8 + sz_rfbPixelFormat)
 248
 249
 250 /*
 251  * Following the server initialisation message it's up to the client to send
 252  * whichever protocol messages it wants.  Typically it will send a
 253  * SetPixelFormat message and a SetEncodings message, followed by a
 254  * FramebufferUpdateRequest.  From then on the server will send
 255  * FramebufferUpdate messages in response to the client's
 256  * FramebufferUpdateRequest messages.  The client should send
 257  * FramebufferUpdateRequest messages with incremental set to true when it has
 258  * finished processing one FramebufferUpdate and is ready to process another.
 259  * With a fast client, the rate at which FramebufferUpdateRequests are sent
 260  * should be regulated to avoid hogging the network.
 261  */
 262
 263
 264
 265 /*****************************************************************************
 266  *
 267  * Message types
 268  *
 269  *****************************************************************************/
 270
 271 /* server -> client */
 272
 273 #define rfbFramebufferUpdate 0
 274 #define rfbSetColourMapEntries 1
 275 #define rfbBell 2
 276 #define rfbServerCutText 3
 277
 278
 279 /* client -> server */
 280
 281 #define rfbSetPixelFormat 0
 282 #define rfbFixColourMapEntries 1    /* not currently supported */
 283 #define rfbSetEncodings 2
 284 #define rfbFramebufferUpdateRequest 3
 285 #define rfbKeyEvent 4
 286 #define rfbPointerEvent 5
 287 #define rfbClientCutText 6
 288
 289
 290
 291
 292 /*****************************************************************************
 293  *
 294  * Encoding types
 295  *
 296  *****************************************************************************/
 297
 298 #define rfbEncodingRaw 0
 299 #define rfbEncodingCopyRect 1
 300 #define rfbEncodingRRE 2
 301 #define rfbEncodingCoRRE 4
 302 #define rfbEncodingHextile 5
 303
 304
 305
 306 /*****************************************************************************
 307  *
 308  * Server -> client message definitions
 309  *
 310  *****************************************************************************/
 311
 312
 313 /*-----------------------------------------------------------------------------
 314  * FramebufferUpdate - a block of rectangles to be copied to the framebuffer.
 315  *
 316  * This message consists of a header giving the number of rectangles of pixel
 317  * data followed by the rectangles themselves.  The header is padded so that
 318  * together with the type byte it is an exact multiple of 4 bytes (to help
 319  * with alignment of 32-bit pixels):
 320  */
 321
 322 typedef struct {
 323     CARD8 type;         /* always rfbFramebufferUpdate */
 324     CARD8 pad;
 325     CARD16 nRects;
 326     /* followed by nRects rectangles */
 327 } rfbFramebufferUpdateMsg;
 328
 329 #define sz_rfbFramebufferUpdateMsg 4
 330
 331 /*
 332  * Each rectangle of pixel data consists of a header describing the position
 333  * and size of the rectangle and a type word describing the encoding of the
 334  * pixel data, followed finally by the pixel data.  Note that if the client has
 335  * not sent a SetEncodings message then it will only receive raw pixel data.
 336  * Also note again that this structure is a multiple of 4 bytes.
 337  */
 338
 339 typedef struct {
 340     rfbRectangle r;
 341     CARD32 encoding;    /* one of the encoding types rfbEncoding... */
 342 } rfbFramebufferUpdateRectHeader;
 343
 344 #define sz_rfbFramebufferUpdateRectHeader (sz_rfbRectangle + 4)
 345
 346
 347 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 348  * Raw Encoding.  Pixels are sent in top-to-bottom scanline order,
 349  * left-to-right within a scanline with no padding in between.
 350  */
 351
 352
 353 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 354  * CopyRect Encoding.  The pixels are specified simply by the x and y position
 355  * of the source rectangle.
 356  */
 357
 358 typedef struct {
 359     CARD16 srcX;
 360     CARD16 srcY;
 361 } rfbCopyRect;
 362
 363 #define sz_rfbCopyRect 4
 364
 365
 366 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 367  * RRE - Rise-and-Run-length Encoding.  We have an rfbRREHeader structure
 368  * giving the number of subrectangles following.  Finally the data follows in
 369  * the form [<bgpixel><subrect><subrect>...] where each <subrect> is
 370  * [<pixel><rfbRectangle>].
 371  */
 372
 373 typedef struct {
 374     CARD32 nSubrects;
 375 } rfbRREHeader;
 376
 377 #define sz_rfbRREHeader 4
 378
 379
 380 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 381  * CoRRE - Compact RRE Encoding.  We have an rfbRREHeader structure giving
 382  * the number of subrectangles following.  Finally the data follows in the form
 383  * [<bgpixel><subrect><subrect>...] where each <subrect> is
 384  * [<pixel><rfbCoRRERectangle>].  This means that
 385  * the whole rectangle must be at most 255x255 pixels.
 386  */
 387
 388 typedef struct {
 389     CARD8 x;
 390     CARD8 y;
 391     CARD8 w;
 392     CARD8 h;
 393 } rfbCoRRERectangle;
 394
 395 #define sz_rfbCoRRERectangle 4
 396
 397
 398 /*- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
 399  * Hextile Encoding.  The rectangle is divided up into 'tiles' of 16x16 pixels,
 400  * starting at the top left going in left-to-right, top-to-bottom order.  If
 401  * the width of the rectangle is not an exact multiple of 16 then the width of
 402  * the last tile in each row will be correspondingly smaller.  Similarly if the
 403  * height is not an exact multiple of 16 then the height of each tile in the
 404  * final row will also be smaller.  Each tile begins with a 'subencoding' type
 405  * byte, which is a mask made up of a number of bits.  If the Raw bit is set
 406  * then the other bits are irrelevant; w*h pixel values follow (where w and h
 407  * are the width and height of the tile).  Otherwise the tile is encoded in a
 408  * similar way to RRE, except that the position and size of each subrectangle
 409  * can be specified in just two bytes.  The other bits in the mask are as
 410  * follows:
 411  *
 412  * BackgroundSpecified - if set, a pixel value follows which specifies
 413  *    the background colour for this tile.  The first non-raw tile in a
 414  *    rectangle must have this bit set.  If this bit isn't set then the
 415  *    background is the same as the last tile.
 416  *
 417  * ForegroundSpecified - if set, a pixel value follows which specifies
 418  *    the foreground colour to be used for all subrectangles in this tile.
 419  *    If this bit is set then the SubrectsColoured bit must be zero.
 420  *
 421  * AnySubrects - if set, a single byte follows giving the number of
 422  *    subrectangles following.  If not set, there are no subrectangles (i.e.
 423  *    the whole tile is just solid background colour).
 424  *
 425  * SubrectsColoured - if set then each subrectangle is preceded by a pixel
 426  *    value giving the colour of that subrectangle.  If not set, all
 427  *    subrectangles are the same colour, the foreground colour;  if the
 428  *    ForegroundSpecified bit wasn't set then the foreground is the same as
 429  *    the last tile.
 430  *
 431  * The position and size of each subrectangle is specified in two bytes.  The
 432  * Pack macros below can be used to generate the two bytes from x, y, w, h,
 433  * and the Extract macros can be used to extract the x, y, w, h values from
 434  * the two bytes.
 435  */
 436
 437 #define rfbHextileRaw           (1 << 0)
 438 #define rfbHextileBackgroundSpecified   (1 << 1)
 439 #define rfbHextileForegroundSpecified   (1 << 2)
 440 #define rfbHextileAnySubrects       (1 << 3)
 441 #define rfbHextileSubrectsColoured  (1 << 4)
 442
 443 #define rfbHextilePackXY(x,y) (((x) << 4) | (y))
 444 #define rfbHextilePackWH(w,h) ((((w)-1) << 4) | ((h)-1))
 445 #define rfbHextileExtractX(byte) ((byte) >> 4)
 446 #define rfbHextileExtractY(byte) ((byte) & 0xf)
 447 #define rfbHextileExtractW(byte) (((byte) >> 4) + 1)
 448 #define rfbHextileExtractH(byte) (((byte) & 0xf) + 1)
 449
 450
 451 /*-----------------------------------------------------------------------------
 452  * SetColourMapEntries - these messages are only sent if the pixel
 453  * format uses a 'colour map' (i.e. trueColour false) and the client has not
 454  * fixed the entire colour map using FixColourMapEntries.  In addition they
 455  * will only start being sent after the client has sent its first
 456  * FramebufferUpdateRequest.  So if the client always tells the server to use
 457  * trueColour then it never needs to process this type of message.
 458  */
 459
 460 typedef struct {
 461     CARD8 type;         /* always rfbSetColourMapEntries */
 462     CARD8 pad;
 463     CARD16 firstColour;
 464     CARD16 nColours;
 465
 466     /* Followed by nColours * 3 * CARD16
 467        r1, g1, b1, r2, g2, b2, r3, g3, b3, ..., rn, bn, gn */
 468
 469 } rfbSetColourMapEntriesMsg;
 470
 471 #define sz_rfbSetColourMapEntriesMsg 6
 472
 473
 474
 475 /*-----------------------------------------------------------------------------
 476  * Bell - ring a bell on the client if it has one.
 477  */
 478
 479 typedef struct {
 480     CARD8 type;         /* always rfbBell */
 481 } rfbBellMsg;
 482
 483 #define sz_rfbBellMsg 1
 484
 485
 486
 487 /*-----------------------------------------------------------------------------
 488  * ServerCutText - the server has new text in its cut buffer.
 489  */
 490
 491 typedef struct {
 492     CARD8 type;         /* always rfbServerCutText */
 493     CARD8 pad1;
 494     CARD16 pad2;
 495     CARD32 length;
 496     /* followed by char text[length] */
 497 } rfbServerCutTextMsg;
 498
 499 #define sz_rfbServerCutTextMsg 8
 500
 501
 502 /*-----------------------------------------------------------------------------
 503  * Union of all server->client messages.
 504  */
 505
 506 typedef union {
 507     CARD8 type;
 508     rfbFramebufferUpdateMsg fu;
 509     rfbSetColourMapEntriesMsg scme;
 510     rfbBellMsg b;
 511     rfbServerCutTextMsg sct;
 512 } rfbServerToClientMsg;
 513
 514
 515
 516 /*****************************************************************************
 517  *
 518  * Message definitions (client -> server)
 519  *
 520  *****************************************************************************/
 521
 522
 523 /*-----------------------------------------------------------------------------
 524  * SetPixelFormat - tell the RFB server the format in which the client wants
 525  * pixels sent.
 526  */
 527
 528 typedef struct {
 529     CARD8 type;         /* always rfbSetPixelFormat */
 530     CARD8 pad1;
 531     CARD16 pad2;
 532     rfbPixelFormat format;
 533 } rfbSetPixelFormatMsg;
 534
 535 #define sz_rfbSetPixelFormatMsg (sz_rfbPixelFormat + 4)
 536
 537
 538 /*-----------------------------------------------------------------------------
 539  * FixColourMapEntries - when the pixel format uses a 'colour map', fix
 540  * read-only colour map entries.
 541  *
 542  *    ***************** NOT CURRENTLY SUPPORTED *****************
 543  */
 544
 545 typedef struct {
 546     CARD8 type;         /* always rfbFixColourMapEntries */
 547     CARD8 pad;
 548     CARD16 firstColour;
 549     CARD16 nColours;
 550
 551     /* Followed by nColours * 3 * CARD16
 552        r1, g1, b1, r2, g2, b2, r3, g3, b3, ..., rn, bn, gn */
 553
 554 } rfbFixColourMapEntriesMsg;
 555
 556 #define sz_rfbFixColourMapEntriesMsg 6
 557
 558
 559 /*-----------------------------------------------------------------------------
 560  * SetEncodings - tell the RFB server which encoding types we accept.  Put them
 561  * in order of preference, if we have any.  We may always receive raw
 562  * encoding, even if we don't specify it here.
 563  */
 564
 565 typedef struct {
 566     CARD8 type;         /* always rfbSetEncodings */
 567     CARD8 pad;
 568     CARD16 nEncodings;
 569     /* followed by nEncodings * CARD32 encoding types */
 570 } rfbSetEncodingsMsg;
 571
 572 #define sz_rfbSetEncodingsMsg 4
 573
 574
 575 /*-----------------------------------------------------------------------------
 576  * FramebufferUpdateRequest - request for a framebuffer update.  If incremental
 577  * is true then the client just wants the changes since the last update.  If
 578  * false then it wants the whole of the specified rectangle.
 579  */
 580
 581 typedef struct {
 582     CARD8 type;         /* always rfbFramebufferUpdateRequest */
 583     CARD8 incremental;
 584     CARD16 x;
 585     CARD16 y;
 586     CARD16 w;
 587     CARD16 h;
 588 } rfbFramebufferUpdateRequestMsg;
 589
 590 #define sz_rfbFramebufferUpdateRequestMsg 10
 591
 592
 593 /*-----------------------------------------------------------------------------
 594  * KeyEvent - key press or release
 595  *
 596  * Keys are specified using the 'keysym' values defined by the X Window System.
 597  * For most ordinary keys, the keysym is the same as the corresponding ASCII
 598  * value.  Other common keys are:
 599  *
 600  * BackSpace        0xff08
 601  * Tab          0xff09
 602  * Return or Enter  0xff0d
 603  * Escape       0xff1b
 604  * Insert       0xff63
 605  * Delete       0xffff
 606  * Home         0xff50
 607  * End          0xff57
 608  * Page Up      0xff55
 609  * Page Down        0xff56
 610  * Left         0xff51
 611  * Up           0xff52
 612  * Right        0xff53
 613  * Down         0xff54
 614  * F1           0xffbe
 615  * F2           0xffbf
 616  * ...          ...
 617  * F12          0xffc9
 618  * Shift        0xffe1
 619  * Control      0xffe3
 620  * Meta         0xffe7
 621  * Alt          0xffe9
 622  */
 623
 624 typedef struct {
 625     CARD8 type;         /* always rfbKeyEvent */
 626     CARD8 down;         /* true if down (press), false if up */
 627     CARD16 pad;
 628     CARD32 key;         /* key is specified as an X keysym */
 629 } rfbKeyEventMsg;
 630
 631 #define sz_rfbKeyEventMsg 8
 632
 633
 634 /*-----------------------------------------------------------------------------
 635  * PointerEvent - mouse/pen move and/or button press.
 636  */
 637
 638 typedef struct {
 639     CARD8 type;         /* always rfbPointerEvent */
 640     CARD8 buttonMask;       /* bits 0-7 are buttons 1-8, 0=up, 1=down */
 641     CARD16 x;
 642     CARD16 y;
 643 } rfbPointerEventMsg;
 644
 645 #define rfbButton1Mask 1
 646 #define rfbButton2Mask 2
 647 #define rfbButton3Mask 4
 648
 649 #define sz_rfbPointerEventMsg 6
 650
 651
 652
 653 /*-----------------------------------------------------------------------------
 654  * ClientCutText - the client has new text in its cut buffer.
 655  */
 656
 657 typedef struct {
 658     CARD8 type;         /* always rfbClientCutText */
 659     CARD8 pad1;
 660     CARD16 pad2;
 661     CARD32 length;
 662     /* followed by char text[length] */
 663 } rfbClientCutTextMsg;
 664
 665 #define sz_rfbClientCutTextMsg 8
 666
 667
 668
 669 /*-----------------------------------------------------------------------------
 670  * Union of all client->server messages.
 671  */
 672
 673 typedef union {
 674     CARD8 type;
 675     rfbSetPixelFormatMsg spf;
 676     rfbFixColourMapEntriesMsg fcme;
 677     rfbSetEncodingsMsg se;
 678     rfbFramebufferUpdateRequestMsg fur;
 679     rfbKeyEventMsg ke;
 680     rfbPointerEventMsg pe;
 681     rfbClientCutTextMsg cct;
 682 } rfbClientToServerMsg;
 683
 684 #endif