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