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 | |
---|
59 | typedef 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 | |
---|
73 | typedef 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 | |
---|
160 | typedef 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 | |
---|
215 | typedef 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 | |
---|
230 | typedef 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 | |
---|
353 | typedef 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 | |
---|
370 | typedef 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 | |
---|
389 | typedef 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 | |
---|
404 | typedef 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 | |
---|
419 | typedef 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 | |
---|
487 | typedef 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 | |
---|
526 | typedef 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 | |
---|
560 | typedef 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 | |
---|
579 | typedef 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 | |
---|
591 | typedef 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 | |
---|
606 | typedef 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 | |
---|
628 | typedef 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 | |
---|
645 | typedef 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 | |
---|
665 | typedef 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 | |
---|
681 | typedef 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 | |
---|
724 | typedef 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 | |
---|
738 | typedef 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 | |
---|
757 | typedef 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 | |
---|
773 | typedef 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 | |
---|