source: trunk/src/testing/app/vnc/rfbproto.h @ 4

Revision 4, 25.8 KB checked in by ajaworski, 13 years ago (diff)

Added modified SAGE sources

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