From 093978008b655038fb677e244bf0fc6d21a3b39f Mon Sep 17 00:00:00 2001 From: Pierre Ossman Date: Wed, 17 Sep 2014 13:55:18 +0200 Subject: [PATCH] None of these files are relevant today --- doc/TODO | 31 - doc/ft-protocol-problems.txt | 35 -- doc/realvnc-internals.txt | 389 ------------ doc/registered-codes.txt | 94 --- doc/requirements.txt | 2 - doc/rfbtight.odt | Bin 30066 -> 0 bytes doc/rfbtight.tex | 1121 ---------------------------------- 7 files changed, 1672 deletions(-) delete mode 100644 doc/TODO delete mode 100644 doc/ft-protocol-problems.txt delete mode 100644 doc/realvnc-internals.txt delete mode 100644 doc/registered-codes.txt delete mode 100644 doc/requirements.txt delete mode 100644 doc/rfbtight.odt delete mode 100644 doc/rfbtight.tex diff --git a/doc/TODO b/doc/TODO deleted file mode 100644 index 2069e694..00000000 --- a/doc/TODO +++ /dev/null @@ -1,31 +0,0 @@ - -* When running the UNIX vncviewer on a host with a different byte - order than the Xserver, the colors are incorrect. This happens when - using color depth 24 ("cutZeros"). Basically, the problem is that - the RGB24_TO_PIXEL32 macro is wrong; we need to swap endianess - in this situation. There seems to be something wrong with the local - cursor handling as well. - -* Change version strings. - -* Tight encoding support - -* Update vncviewer.man: many parameters are currently not documented. - -* When manually changing color level and running against an old server - (Xvnc from TightVNC 1.2.9, for example), the user should perhaps be - warned that vncviewer might crash. - -* Document the Tight protocol extensions in a text file. - -* All other features from the TightVNC 1.3 series: Filetransfer etc - -* Consider adding the toolbar from http://lars.werner.no/vnc/. - -* Implement support for rfbEncodingXCursor. When this is finished, it - should be safe to allow dynamic pixel format changes again, as long - as we only orders new pixel formats after recieving a framebuffer - update with real pixel data. - -* The vncviewer password dialog should probably display the server - name in the password dialog windows title. Wish from Gaetano Giunta. diff --git a/doc/ft-protocol-problems.txt b/doc/ft-protocol-problems.txt deleted file mode 100644 index b0198fbc..00000000 --- a/doc/ft-protocol-problems.txt +++ /dev/null @@ -1,35 +0,0 @@ -From: Peter Rosin -To: vnc-tight-list@lists.sourceforge.net -Date: Thu, 25 Sep 2008 10:21:07 +0200 -Message-ID: <48DB49F3.6030609@lysator.liu.se> -Subject: Problems with timestamps in file transfers. - -Hi list! - -I'm writing some VNC client software that supports the the file -transfer extensions described in the rfbtight.tex document in -the svn repo. However, when I communicate with a TightVNC server -version 1.3.9 (WinVNC.exe) I get strange data for the modification -times of the files. - -Specifically, in the FileListData message, I have understood -that directories are encoded as . For -regular files I get the expected size, but the mod-time is -always 0xffffffe7 (-25) which seem totally bogus. - -The next problem is more disturbing since you will get interop -problems if you fix it. In the last FileDownloadData message -(the one with raw-length = compressed-length = 0), the mod-time -is transmitted in little-endian byte order (at least my TightVNC -server does so). Since it's more problems fixing this than -documenting it, I think this endianness issue should be recorded -in the rfbtight.tex file. - -(However, when you use FileUploadData you should transmit - the mod-time in the expected big-endian network byte order.) - -Cheers, -Peter - -================================================================== - diff --git a/doc/realvnc-internals.txt b/doc/realvnc-internals.txt deleted file mode 100644 index 16975acd..00000000 --- a/doc/realvnc-internals.txt +++ /dev/null @@ -1,389 +0,0 @@ - -The RealVNC code base is mostly undocumented. Rather than adding -comments to the actual source files, documentation is keept in -separate files in this directory. This is done because we want to make -as few changes to the RealVNC sources as possible. - - - -Files -===== -(t) means only in TigerVNC. - -Name Server/Client/Both Windows/UNIX/Both -------------------------------------------------------------------------- -Xregion/Xregion.h -Xregion/region.h -jpeg/jchuff.h B(t) B(t) -jpeg/jconfig.h B(t) B(t) -jpeg/jdct.h B(t) B(t) -jpeg/jdhuff.h B(t) B(t) -jpeg/jerror.h B(t) B(t) -jpeg/jinclude.h B(t) B(t) -jpeg/jmemsys.h B(t) B(t) -jpeg/jmorecfg.h B(t) B(t) -jpeg/jpegint.h B(t) B(t) -jpeg/jpeglib.h B(t) B(t) -jpeg/jversion.h B(t) B(t) -logmessages/messages.h -network/Socket.h -network/TcpSocket.cxx -network/TcpSocket.h -network/msvcwarning.h - -Name Server/Client/Both Windows/UNIX/Both -------------------------------------------------------------------------- -rdr/Exception.cxx -rdr/Exception.h -rdr/FdInStream.cxx -rdr/FdInStream.h -rdr/FdOutStream.cxx -rdr/FdOutStream.h -rdr/FixedMemOutStream.h -rdr/HexInStream.cxx -rdr/HexInStream.h -rdr/HexOutStream.cxx -rdr/HexOutStream.h -rdr/InStream.cxx -rdr/InStream.h -rdr/MemInStream.h -rdr/MemOutStream.h -rdr/NullOutStream.cxx -rdr/NullOutStream.h -rdr/OutStream.h -rdr/RandomStream.cxx -rdr/RandomStream.h -rdr/SubstitutingInStream.h -rdr/ZlibInStream.cxx -rdr/ZlibInStream.h -rdr/ZlibOutStream.cxx -rdr/ZlibOutStream.h -rdr/msvcwarning.h -rdr/types.h - -Name Server/Client/Both Windows/UNIX/Both -------------------------------------------------------------------------- -rfb/win32/Threading_win32.cxx -rfb/win32/Threading_win32.h -rfb/win32/msvcwarning.h -rfb/win32/util_win32.h -rfb/Blacklist.cxx -rfb/Blacklist.h -rfb/CConnection.cxx -rfb/CConnection.h -rfb/CMsgHandler.cxx -rfb/CMsgHandler.h -rfb/CMsgReader.h -rfb/CMsgReaderV3.cxx -rfb/CMsgReaderV3.h -rfb/CMsgWriter.cxx -rfb/CMsgWriter.h -rfb/CMsgWriterV3.cxx -rfb/CMsgWriterV3.h -rfb/CSecurity.h -rfb/CSecurityNone.h -rfb/CSecurityVncAuth.cxx -rfb/CSecurityVncAuth.h -rfb/ColourCube.h -rfb/ColourMap.h -rfb/ComparingUpdateTracker.cxx -rfb/ComparingUpdateTracker.h -rfb/Configuration.cxx -rfb/Configuration.h -rfb/ConnParams.cxx B B -rfb/ConnParams.h B B -rfb/Cursor.cxx -rfb/Cursor.h -rfb/Decoder.cxx -rfb/Decoder.h -rfb/Encoder.cxx -rfb/Encoder.h -rfb/Exception.h -rfb/HTTPServer.cxx -rfb/HTTPServer.h -rfb/HextileDecoder.cxx -rfb/HextileDecoder.h -rfb/HextileEncoder.cxx -rfb/HextileEncoder.h -rfb/Hostname.h -rfb/ImageGetter.h -rfb/LogWriter.cxx -rfb/LogWriter.h -rfb/Logger.cxx -rfb/Logger.h -rfb/Logger_file.cxx -rfb/Logger_file.h -rfb/Logger_stdio.cxx -rfb/Logger_stdio.h -rfb/Pixel.h -rfb/PixelBuffer.cxx -rfb/PixelBuffer.h -rfb/PixelFormat.cxx -rfb/PixelFormat.h -rfb/RREDecoder.cxx -rfb/RREDecoder.h -rfb/RREEncoder.cxx -rfb/RREEncoder.h -rfb/RawDecoder.cxx -rfb/RawDecoder.h -rfb/RawEncoder.cxx -rfb/RawEncoder.h -rfb/Rect.h -rfb/Region.cxx -rfb/Region.h -rfb/SConnection.cxx -rfb/SConnection.h -rfb/SDesktop.h -rfb/SMsgHandler.cxx -rfb/SMsgHandler.h -rfb/SMsgReader.cxx -rfb/SMsgReader.h -rfb/SMsgReaderV3.cxx -rfb/SMsgReaderV3.h -rfb/SMsgWriter.cxx -rfb/SMsgWriter.h -rfb/SMsgWriterV3.h -rfb/SSecurity.h -rfb/SSecurityFactoryStandard.cxx -rfb/SSecurityFactoryStandard.h -rfb/SSecurityNone.h -rfb/SSecurityVncAuth.cxx -rfb/SSecurityVncAuth.h -rfb/ServerCore.cxx -rfb/ServerCore.h -rfb/Threading.h -rfb/TransImageGetter.cxx -rfb/TransImageGetter.h -rfb/TrueColourMap.h -rfb/UpdateTracker.cxx -rfb/UpdateTracker.h -rfb/UserPasswdGetter.h -rfb/VNCSConnectionST.cxx -rfb/VNCSConnectionST.h -rfb/VNCServer.h -rfb/VNCServerST.cxx -rfb/VNCServerST.h -rfb/ZRLEDecoder.cxx -rfb/ZRLEDecoder.h -rfb/ZRLEEncoder.cxx -rfb/ZRLEEncoder.h -rfb/d3des.h -rfb/encodings.cxx -rfb/encodings.h -rfb/hextileConstants.h -rfb/hextileDecode.h -rfb/hextileEncode.h -rfb/keysymdef.h -rfb/msgTypes.h -rfb/msvcwarning.h -rfb/rreDecode.h -rfb/rreEncode.h -rfb/SMsgWriterV3.cxx -rfb/transInitTempl.h -rfb/transTempl.h -rfb/util.cxx -rfb/util.h -rfb/vncAuth.cxx -rfb/vncAuth.h -rfb/zrleDecode.h -rfb/zrleEncode.h -rfb/secTypes.cxx -rfb/CMsgReader.cxx -rfb/TightDecoder.cxx -rfb/tightDecode.h -rfb/TightDecoder.h -rfb/secTypes.h - -Name Server/Client/Both Windows/UNIX/Both -------------------------------------------------------------------------- -rfb_win32/AboutDialog.cxx -rfb_win32/AboutDialog.h -rfb_win32/CKeyboard.cxx -rfb_win32/CKeyboard.h -rfb_win32/CPointer.cxx -rfb_win32/CPointer.h -rfb_win32/CleanDesktop.cxx -rfb_win32/CleanDesktop.h -rfb_win32/Clipboard.cxx -rfb_win32/Clipboard.h -rfb_win32/CurrentUser.cxx -rfb_win32/CurrentUser.h -rfb_win32/DIBSectionBuffer.cxx -rfb_win32/DIBSectionBuffer.h -rfb_win32/DeviceFrameBuffer.cxx -rfb_win32/DeviceFrameBuffer.h -rfb_win32/Dialog.cxx -rfb_win32/Dialog.h -rfb_win32/IntervalTimer.h -rfb_win32/LaunchProcess.cxx -rfb_win32/LaunchProcess.h -rfb_win32/MsgWindow.cxx -rfb_win32/MsgWindow.h -rfb_win32/OSVersion.cxx -rfb_win32/OSVersion.h -rfb_win32/RegConfig.cxx -rfb_win32/RegConfig.h -rfb_win32/Registry.cxx -rfb_win32/Registry.h -rfb_win32/SDisplay.cxx -rfb_win32/SDisplay.h -rfb_win32/SInput.cxx -rfb_win32/SInput.h -rfb_win32/Security.h -rfb_win32/Service.cxx -rfb_win32/Service.h -rfb_win32/SocketManager.cxx -rfb_win32/SocketManager.h -rfb_win32/TCharArray.cxx -rfb_win32/TCharArray.h -rfb_win32/TrayIcon.h -rfb_win32/WMCursor.cxx -rfb_win32/WMCursor.h -rfb_win32/WMHooks.cxx -rfb_win32/WMHooks.h -rfb_win32/WMNotifier.cxx -rfb_win32/WMNotifier.h -rfb_win32/WMPoller.cxx -rfb_win32/WMPoller.h -rfb_win32/WMShatter.cxx -rfb_win32/WMShatter.h -rfb_win32/WMWindowCopyRect.cxx -rfb_win32/WMWindowCopyRect.h -rfb_win32/Win32Util.cxx -rfb_win32/Win32Util.h -rfb_win32/keymap.h -rfb_win32/msvcwarning.h - -Name Server/Client/Both Windows/UNIX/Both -------------------------------------------------------------------------- -tx/TXButton.h -tx/TXCheckbox.h -tx/TXDialog.h -tx/TXEntry.h -tx/TXImage.cxx -tx/TXImage.h -tx/TXLabel.h -tx/TXMenu.cxx -tx/TXMenu.h -tx/TXMsgBox.h -tx/TXScrollbar.cxx -tx/TXScrollbar.h -tx/TXViewport.cxx -tx/TXViewport.h -tx/TXWindow.cxx -tx/TXWindow.h -tx/Timer.cxx -tx/Timer.h - -Name Server/Client/Both Windows/UNIX/Both -------------------------------------------------------------------------- -vncconfig/Authentication.h -vncconfig/Connections.h -vncconfig/Desktop.h -vncconfig/Hooking.h -vncconfig/Inputs.h -vncconfig/Legacy.cxx -vncconfig/Legacy.h -vncconfig/Sharing.h -vncconfig/resource.h -vncconfig/vncconfig.cxx -vncconfig_unix/vncExt.h -vncconfig_unix/vncconfig.cxx -vncmkdepend/def.h -vncmkdepend/ifparser.h -vncpasswd/vncpasswd.cxx - -Name Server/Client/Both Windows/UNIX/Both -------------------------------------------------------------------------- -vncviewer/CViewManager.cxx -vncviewer/CViewManager.h -vncviewer/CViewOptions.cxx C W -vncviewer/CViewOptions.h C W -vncviewer/ConnectingDialog.h -vncviewer/ConnectionDialog.cxx -vncviewer/ConnectionDialog.h -vncviewer/InfoDialog.cxx -vncviewer/InfoDialog.h -vncviewer/MRU.h -vncviewer/OptionsDialog.cxx -vncviewer/OptionsDialog.h -vncviewer/UserPasswdDialog.cxx -vncviewer/UserPasswdDialog.h -vncviewer/buildTime.cxx -vncviewer/cview.cxx C W -vncviewer/cview.h -vncviewer/msvcwarning.h -vncviewer/resource.h -vncviewer/vncviewer.cxx - -Name Server/Client/Both Windows/UNIX/Both -------------------------------------------------------------------------- -vncviewer_unix/AboutDialog.h -vncviewer_unix/CConn.cxx -vncviewer_unix/CConn.h -vncviewer_unix/DesktopWindow.cxx -vncviewer_unix/DesktopWindow.h -vncviewer_unix/InfoDialog.h -vncviewer_unix/OptionsDialog.h -vncviewer_unix/PasswdDialog.h -vncviewer_unix/ServerDialog.h -vncviewer_unix/parameters.h -vncviewer_unix/vncviewer.cxx - -Name Server/Client/Both Windows/UNIX/Both -------------------------------------------------------------------------- -winvnc/AddNewClientDialog.h -winvnc/JavaViewer.cxx -winvnc/JavaViewer.h -winvnc/QueryConnectDialog.cxx -winvnc/QueryConnectDialog.h -winvnc/STrayIcon.cxx -winvnc/STrayIcon.h -winvnc/VNCServerService.cxx -winvnc/VNCServerService.h -winvnc/VNCServerWin32.cxx -winvnc/VNCServerWin32.h -winvnc/buildTime.cxx -winvnc/msvcwarning.h -winvnc/resource.h -winvnc/winvnc.cxx -wm_hooks/msvcwarning.h -wm_hooks/resource.h -wm_hooks/wm_hooks.cxx -wm_hooks/wm_hooks.h - -Name Server/Client/Both Windows/UNIX/Both -------------------------------------------------------------------------- -x0vncserver/Image.cxx -x0vncserver/Image.h -x0vncserver/x0vncserver.cxx -xc/programs/Xserver/vnc/RegionHelper.h -xc/programs/Xserver/vnc/XserverDesktop.h -xc/programs/Xserver/vnc/vncExtInit.h -xc/programs/Xserver/vnc/vncHooks.h - -Name Server/Client/Both Windows/UNIX/Both -------------------------------------------------------------------------- -zlib/deflate.h -zlib/infblock.h -zlib/infcodes.h -zlib/inffast.h -zlib/inffixed.h -zlib/inftrees.h -zlib/infutil.h -zlib/trees.h -zlib/zconf.h -zlib/zlib.h -zlib/zutil.h - -Name Server/Client/Both Windows/UNIX/Both -------------------------------------------------------------------------- -rfbplayer/FbsInputStream.cxx -rfbplayer/FbsInputStream.h -rfbplayer/RfbProto.cxx -rfbplayer/RfbProto.h -rfbplayer/buildTime.cxx -rfbplayer/resource.h -rfbplayer/rfbplayer.cxx -rfbplayer/rfbplayer.h -rfbplayer/utils.h diff --git a/doc/registered-codes.txt b/doc/registered-codes.txt deleted file mode 100644 index ed97a064..00000000 --- a/doc/registered-codes.txt +++ /dev/null @@ -1,94 +0,0 @@ -[Vendor=TGHT] -Title: TightVNC -Web: http://www.tightvnc.com/ - -[Vendor=STDV] -Title: RealVNC -Web: http://www.realvnc.com/ - -[Vendor=TRDV] -Title: TridiaVNC -Web: http://www.tridiavnc.com/ - -[Vendor=GGI_] -Title: General Graphics Interface Project -Web: http://www.ggi-project.org/ - -[Tunneling=0] -Vendor: TGHT -Signature: NOTUNNEL -Abbrev: NoTunelling -Description: No tunneling - -[Auth=1] -Vendor: STDV -Signature: NOAUTH__ -Abbrev: AuthNone -Description: No authentication - -[Auth=2] -Vendor: STDV -Signature: VNCAUTH_ -Abbrev: AuthVNC -Description: Standard VNC Authentication - -[Auth=129] -Vendor: THGT -Signature: ULGNAUTH -Abbrev: AuthUnixLogin -Description: Unix Login Authentication -Notes: Not used in public versions - -[Auth=130] -Vendor: THGT -Signature: XTRNAUTH -Abbrev: AuthExternal -Description: External Authentication -Notes: Not used in public versions - -[ServerMessageRange=130..149] -Vendor: THGT -Description: TightVNC File Transfers - -[ServerMessage=150] -Vendor: THGT -Signature: CUS_EOCU -Abbrev: EndOfContinuousUpdates -Description: End Of Continuous Updates - -[ServerMessage=253] -Vendor: GGI_ -Signature: GII_SERV - -[ClientMessageRange=130..150] -Vendor: THGT -Description: TightVNC File Transfers - -[ClientMessage=150] -Vendor: THGT -Signature: CUC_ENCU -Abbrev: EnableContinuousUpdates -Description: Enable/Disable Continuous Updates - -[ClientMessage=151] -Vendor: THGT -Signature: VRECTSEL -Abbrev: VideoRectangleSelection -Description: Video Rectangle Selection - -[ClientMessage=253] -Vendor: GGI_ -Signature: GII_CLNT - -[EncodingRange=0xFFFFFF00..0xFFFFFFFF] -AltNotation: -256..-1 -AltNotation: 4294967040..4294967295 -Vendor: TGHT -Description: TightVNC-Specific Pseudo-Encodings - -[Encoding=0xFFFFFECF] -AltNotation: -305 -AltNotation: 4294966991 -Vendor: GGI_ -Signature: GII_____ - diff --git a/doc/requirements.txt b/doc/requirements.txt deleted file mode 100644 index 4957be3a..00000000 --- a/doc/requirements.txt +++ /dev/null @@ -1,2 +0,0 @@ - -- The UNIX version requires snprintf(). diff --git a/doc/rfbtight.odt b/doc/rfbtight.odt deleted file mode 100644 index 363048190af643bb2ffbf983eead0c6fa11c6e25..0000000000000000000000000000000000000000 GIT binary patch literal 0 HcmV?d00001 literal 30066 zcma&M1CS`q(k(i+ZQHhO+nznPZEKHh+qP}n++%Cs`Oc4f-~Z0L@hZAHvMOt3uBy(C z=(K|UCI=eU- z89LJc2M*%L*LNPTDZNktmqHBodX%G#|Frtca zh#pNi3u4;VhhfVg#uPmdXgn3h2sem9ZvdlbMllF60ujb&X%HR4Fv5s&$Qn)92V@%F zkDh zNlP{rX%|EOO5L`f^BDB7(_!j>lv^8GEzeS2IoUG5ctKYBeT%ti;{v_Eo&Ttxde&#TYw}pc(jZDeLfp4aekX z;^SS*=(s)a?HTapx}65qnCjz>m6n!*Kdu58u)5owtb_STE5nBi+B2OBTu*?1cPbxH zY3>iYiN?#=aS^$iEm73`UQ<1Nr(zb>(We!R;ZnSsY7*3swY?FT?CA!U{dBEpOCs4>_}S^Up^z5$y;Gf@ehD(2 zYJc+mJ(auTye%>!ZJ$Qgpy+<4Fjscmh6l|`9BuL;J%)V+1~+5%^KDa=DVQ)3o=u-jS? z1k`$GHnkCwHaJnP7FPXq6E4OjyU1h%4eku>3|V)8XqxnXWOpi1W`SmlWcvGH_U2#T zk5l}=w}*ahU%mX_`_F%?bONVKb>)OH%Smjkyze#nx|vsTOC!(0(@WwA&i%H&dpCQ( zU+G)_emv9jfAaxXPz5#XLsl*P@%y^d_x=2e`}_U;qpfu9)Ay{XpfQN1XGqHhmUB@^qU}d`lr%RBvToMJT?6vsS!G=kI4Y$36+l%LWKkQLuOHx_ zLG_FpP9Hk}44B5#=Yn4v2tJXvFFTDwu?{b3@a6>fP)CiATMl?(W8_>wKPKK?_|2aL z`YkEj_adi0;Op+aMGgC*Nn4le92fSb+6NCd+AV0Yhd(KuM;@90#?6C9h_4NA7C9ob zglF)9K^PiFJPG!;$vC!F%>QUW`P&$?gX~K;?wh#B>{1=seYQ!4h|jfJGc-;-<+7k6 zzse09J2nw>gD`gQd4`sjZ8a#m-o7Msr7j0wu$HV z2?ILldVhXjY7cyLuwi7t;l)BWC3XwHs>%5%z*`CHRSmCpXR|tSbhMf$_Szt*Zl1%# zd%?uRyJ32!Gm+MHC)>L5;kpRb!s^-eQe;DtdZFN7?&XTI*))r?ZGV(a$5oZ{jXqgV zKf*k&H3A#fsOGU=qGsjRrqK&7K=1H3x4&-`t~3e5?)_@=>pEW}ID4}o%yHs_dONGP+5tH(r|f?1*9J`P z&bZXqQxSXoWW%bjPw4FV1%dp{Yg^O(cJ1^nCSDEOCRmUj=-jI5D-LdURqO-IBsSld z8bj^o_8;V_A7S*lPVnqkjsYHv76W_>X8>T{?hXtXfNzvCM!db&e9I3#`6gJcd9=+z zu>3-Y0-FevL-^9j!+}rc<4EVV)esZBs$fYj-;%=Ff#va1pi#5L`+G_paW+LhXE77& zbpR+mGBiADWAt4UdF5gnA9Y23o%IxR%P|Go*S==d#dJzGM&0)ja3Qlk({0JoqGRVZ ze?C4mTzm*Ox$yP+>h>UGcfgstGjIfHa4Q0yt$tO8tTzc{g1OS$OTfW1K`trjKQ=aS z^ZN;18-yF&G}KuaO3+~2JA3ZMdIb2BrcZ$#OM!;1{5sW3IIvRS5#X%pmjIvpQVoE6 z@{`6rT~dihh<@U+w|`wTYHyFsSnHosNwVa_KFo+rA}#=xh(U30ooU&K79xFQKvS%A z5#5BW_0iq}X}sl*HEgX#45>Vrq^XTAi`^RK%|ob!icQ{&1gY*zTQI8*nF{yglB z_wB=coj#iIv&Zn^-_Yff+<4AmSTxX*Bt!EJ@14D92> z0unC&B4uqK$?HUp@p3)~30(Kv#UyCwDseqghi|Z331>zePb|Q+To_m@IjW_0%&DNT z%V}e_Tu*af?%>!qdO5XCUr+C|b+U(TUhUxg^vjnJ!D_#l;Sg4PDf6UPdo^;Q<|{GT zY-b|Ut^B-weFpB?1{d}_Nz~fuvO>DJ@B~(lL$D#z3OTzkUN_msb{ePfQ#Rgl#uA+9`V=Lp(aeuxsM{);a zdA2aALkBn2Y@pyHWL{+41tP^nvg+AtXC|r-4~;)6Np-IbU?0uJ|K{YGd!=lWe{mV+ zr|6HKu(=RpNHsxi!i0vG+kko^*_dNFA_ST{4Y+@eF#$zG@jIi4t4|&C8w2YEZQY{Z z8yuyFOv4PQ(z_Kj!2er@Sq>mi2<$6Cm?yXQWgoz z=A~h&GR)TX8%wo*y2eDKu+#L1*8KL5A#1Yj(hG&5?UTXOaTbHVS*{L*K_7Bvb|`k9 zXY}RNPH~n58+#)7IJvk*J=i{Z56&B--|PPA=*Zh!IGbrb@*afpXx!6~9@{H;a`bia z5RZZ?1m5EWt3!Lt(L93$HAB8brvj|pSG5O{enR?#jlT71K(yR^btUY7ICk8tfa7() z39%aseak<*W~?@$RxQaa)Qf=03|A(+=%849!|IbmQ1!Yv8sROW?hFmTQ4=Dg7B4wr%XO zIR>{Vg6&`y*D*a8HO$V0Mf@di9sT(om+qj)YjjLo$Kgout8qn(cC2#kgd(~tW4c+( zUcG)=5yXB})~K?O;og#M&9Yy2SWVn;YuToLIj}48Pb|_{<+4d7s2l1gZis_= z>$Dp5Jyi=26mhLtVKv&8s*OjIfL^zmw(AvY9WPk*pZN{EX+b?Jucj7pD=%xzYpu<~ zW?rpL6mFHhJaVyVjY)8%i;Jmdq59|Jc6>^SQ z{iFEN(hlnWmsRZhe_6F`;qBq6Ggzkb@b{@NiL9)=BEKqnB>f9HDLi-cw(Ee>f;CHs zJBrm=#Y$EUx8E9I!f;0qfUMl5Y9}A!F_Ln@=^NqveQ0e)!-eJWNS)Xk5~-qKen#5+ z6b^~85^l+XV>7Og5u9;71!Fp2&$BuwyRg5sj|?t+0zG((vkF#5!@L%*M7(ftj|vOw zS7laI+QPItT}jbhWRN(`B#oC_T4$_mv;gc}-nlmOg*0j6?d40x+vyN-4gj=|pz)iV zkgtw;SSHq)@`lIr;WGjrxa&c}(?+|dSPRULLmPJT@_VLmG>5zX3VZ=`>Vm4IGIN2S zl3Bq2!LXhlG|$IWdxyq!NphmB!H#E?0rJ+@N%qPrd+JRhk@dD8Jr#L7fhCp&a!jlF z2{G%$YIucqHbDZ&+#lIu@aJz@UH!5}Pe- z&!yCE+KAA?<6YWX+p0Z^jg=I+NS8%qwW#^XynoT2HxPvGIg(zJ^_LVoD)D;(GjRo+ zcorV61-m<3nb9SdGx*1Ct?}pTcuo-zW3)kCLM4DBE94$Ie1jdwhhl=QffXN*Jvy`d z^_hmTaTtH*n#rfV`9Vh`I5_yjTNgCXcpKX?9lVN@ z1kKgAajKEK<@|Q*2-1xkxIAbB!r9WD8S|uTHbo>S6=LE7oppy1#y&Y;&I`qFN?m}Q zbFY4GN4L4|e16$I#QK+x^;HCzg3KBl3%mt5I!kNJ(2yyTVC17B57DfqZIOsXoZVV$ zA}E(_QsrlRRGl#HxU>0r|G>aE7v#E1jQ5vlwEcD|7I+8`H%P8H(JXI7KyD%`;j~Bq z%irxF<}(91@H0vpVAw&XCkXP5Troi7x!zJZ;3yHt47l{Iw10T?h&&!`8Gb6g7~sM z=XS4_&{OU7vizPVZ+u0~!KX1?J##D2TVkDo8ltx-Dxjr?-Mq!;qyow9m8^oG+y~YV zSL1TK+}{rFb1_X++=d^51w1P*9cU>4n3I&1nQ#G}6$5qIO~v20?0XHk@7|I>K!0Um zu3zJdPU<)cltXox#0C_ z|NV1cSxf)-`NJ>D>4b+lw=R9w;p(+(;QjWY!~Kt=uj>i0|4D7lKHG<<864_){<+=J-=L}oq34}64phkxQ(Y~{a^|B?pedImG0>4%njjjWZl!;$)d@uxs zH<&3R}olMe=aX zkw7d+5EL((I_rSJ6miU86}2FKfdP)0#wxtNat6Yx9(Y^k)*{K%aKBdAaLR=dW1oWz zV-~CIlY|vI`-tJl7>d0T84po}p^6OQL17M)KkJHS09pW|5_e% z!ebzH8Pp&5kENR*q766(Lk8z_ngI5BTr~;`#@N_LQw=TJwLkaa!qn9Tu^Si-`dKL= z+N+^NI;-I)KTSVA!fNjpS6g)`ovQ5e0e@hZzNcj6u1BS7Z_4QVJRR_6pZ}!q*so*i z8o(OrxaXj*9XQk%gOuv>3yHGd3~p z?&6uO-wBmR4?Zx^In{g%c!`K)?F|56S-ohHedTFk%lgM;X3=Lp1Hr?P^vN4>-sVO$ z-VX80{p?qzHX?9}DX%GriorW+Yd39bVU<8SfNSu-uv9T>a2S>W@kO476gUS03NnJ_ zkFWwBc$dqG*aq7YV-99k#c+%m4*4q$upR|~Xaabbhz>?UjmhB8dP$$n**5;*+x>O^ zINkio-` z7^7*Zf4h<3g?FmK#5uPeW^Fv-s8_loUx_s#9)_L>;v~sKACP)0l82ig3wldsTQ!0d zYQR}MdI*52B8m4tHpq-jW@$kd@uW?~C{sryf!}Wlv!gDvDy@6`y30rj%kR3@Eg%t- z$OB@@PAPD`i)o4=RseM2J=D|2*U|4YZWCp|vMJDNacz~T+??*n;)XKxxaXu00Z%Bk zdO8Sdw&US4z9<3`+Zur6JV5e|*r*j#(JjPd5Mm}naU$%Bb%%H@57pD*E5K6?EqAjL zYNN{@6n`+nc{Srj)o5XUhM5|LaIw88X_6VRmeId)Rmwl0L^+EGV+I%@DLIiK7X9*< z2e9a8^Hm7#-#LtPT2eBV>%<4>K%g*!x7&z3 zK0c>w^o{8d5DHjN!9<(JRHol zP1VU18D=Y!@ovgEhF-7R^Z9Z3aMGOqucjk_iHlI zohPHGj!-mS>VrG(Kb8K@-Sqp@;uz_>4eBo9Ld~bE9tlA+uW?^srIHfxZA+B(s153E zr!tv|3gJ(xe6I~hcu#m$vOhJzBGS+wTP3Ow%TVGoyt}JS`D*EX)Q}>v0TbTY%8lYy zGMoy9_B_(7dKyAOn}P`t-5%nq-Eq2?RlrEY(PF}79CqjwSVgwrG7+#Dd@&SqG+pv} zhx3xTCORDEdu?)=xQTrGko}R!z-aPI)tW>ks#QtOgdO=(Q$c0Eku#KU{-z9l^=o-|wvA-KwC z6Mukj8iH^pU1fb*;{DV&Mkf_T+|MLOuoS)$MYseNMARYj=Z9P zA8<11MtJGhKf^fLC>L()?fI!dC!sAT!^B&<4!6FjV?K}HDl+QkcagFHGF58Xmv2_D$4+jBHeYO665)o?h-MQuppUQ}-ePShd_!2i$#Tj@r@p`u^?F zBdP&N6-uX}xpBA6SNYhy`AbVzy$mUtWW41ll$t3gvMF#Tz@D_w8Z)=g{}Md$Q7T(X zNRzwjjIrDEd4U7jeeV1ns!&O3=VJzm)$$Nkua=cmtn4dRhcP_+hDo& zc-U-b+;FP^Gg%EQ()X))w3AI-cyu@`SH7r(}NUV57;hRNF-JDMrPA(<_`UliGb#e5Bw$SDtR zr!vrorA#36s95PLul=Iw!iemt+d_3NoNJUZ+Ope-ByEO;1{Z2u;tGAqf-K=6eJJ%H z6kPo+qfuIKqPRo9*e{)dMM5(Y@X#7%YNX)1;{~fk@^S(6Z6KMJ$qf?f+ZheFXxTW^W8|vT8J?W&K z?n&O%sW1<(fxigkpL|GsU#6^V&{MJztD|bL*a7AdN1P}EQB|b`cuE@>NzW6H))qyL zYtx>Q6MWgW1qdi2=;*Gy*zXjMp9XvdGPwN2o+1oS>22%gScqwmR#)#hPC^6B%gMjO z#t}Oa3Nx|N4dI>XW>hB4R1sLnKfDQ^P!NKdhew!foO!Kbt6qhzab0rzc@`+hLHPlT zNaGAMuH0X0_$WN7;i~ykj=*7NzwsW6c>2cPz*3!HcV^k$`B(RXyo2C>8W?&nF@CH- zsH^FqIKV8Q5FcqsbCs;*B_bc$f{pb3t7vt-3XAM4I9a92@1)9X+k->;@&8utEmy?uzs_ z%j2IaU6}p!xxET9BfI0vzH%#4m%)b#uP8F>(Z>P=j33I+s)gw&QZId`KxHx%hshIH z<;m1p)3Xdszb42g>ly@m#_zAs=b^@%rPkcIvMb{2Cg5)8??NfCZp~gNp{wfZW?haxIw+1-peQ^^@g|j}9pU<;8)PD*C`#n^!bM8i&r>JQ*JO*9Ikd@U zUr5ao80hm&<~e=5Xl}`E`_g*h7mhgM$sFO2B(G3N+1jX{cM=bkhs*N{%5QTh3kht& z)BH_!H|1>YZ2_li1u*sUihW)5*bpD2oz6-ommG8F_b{)f!ngBl`s0AahFt-GcHxEDgjL1|DBYPeKhkf#Y);&I|MT*Vww5=zb z%`mh+V*nWV8JQvZWV_@R%$SbcwpsXRgE%f;^b=o88Ur^FBsN_lY>e!ulicLrK>^g4 zCt*gZ<@Zi7tcmw%P%^lkDQ%AVj?8|HygaZ2_}AqQKo)>UeyGAszVAtde&<6-)pH3H z8}UxFle={SpIDtzldz`?h4yM9tbL0gd=~6l}HB#aT>8&DCdrz#DrJncKbdj z7s&^_s7WdGBjtig51H9odyEk25Ii7hlCeo;Y9raGMCy@2-S-rgX@CQ^bdL3CF-97? zJy>pAvOs&XU*&@Im{$GmiVC2cz``kC{WI}(*nO}WwK)Fm+zt9c&S^)_R=dR?kRAs{ z9#nCX^3~pZ`ZrhvFCF6q$F)=V&6(ruIE@E>*eB*i`!AV*bih z&(UDawTpahkziuOB-N^pW3Jt8g4v-ll zj19`+gDyHjPu2uzS;qTly@D))VU(3czd*^*h-nQ7S93h_IL$B{t$g|NiT5!OBITcj{S%#nk+`r_LU5W{ecwYB8q5k&)%q)kAS z1~mfo#SQ>_bT(@VS!V@3fonu2!Mln!%m$-Pp-D3eNlk^PmPPd^LNITxq~R4*W~9X* z?X(uGVAZ}YuE&3tvZQn*Qa3HZ7;=#`N%@`lh@7ai9w~Oo7}=;YA-C49=cW{N3&*d| zYk_W`BPA^gf(+9WHnrk*4k`?VNII@|Qji=R;7RC|hfqysO>6-NhJ^=&4=!>kg6e(s*x30)yjP_Rnk!3%HYd=(1gS9&oZCyv6`ZjC5 zU8;;D4lRxBH(<;vR5{o(MjVE+jAsK zrbf-OU}AhaI~)SG)#VXt#OQkUP-x$i4bGSUk{o3@+SHc5a9xX)RBG=fj_tf`q zJ6}>>cM6{m>2Bh~+`ou_+x}+8eo~ho@`v;$9ToP8y1tp@V%r0GdPN5X13Xe??L(Ql zKfQJi;oMdo(a4Ji@8@!Pzg``lu*ts4WN{2M2J22Eg<(d>?sth$I{s3L+L(pX;_qZ& zTm$fD^Ls9LER^r2Yy|)aM8IKV4k;zTE}<@qgDfovC$w_5iQ5T{Gf6%G96oBqE~rmN zRRp#;m5-Rcc7s<9yoU}S_HEtd=Q&UYX(uvsM{PLUs-O&2)xq6@DZ~{d1VL*n)0im(SVD{g;E-7i8dSO z5UR)<+U5qs>|A;_%~3UzS3b()0v{uqg_FVoyHv}@w2$e5|sZ!utNUYM22_CMNW)6sC4V#y);9f???E)6hycmL) z0Hg&n4|8B?zl=AjjA*KwScEgH^l5!S7fU%Boy`D2Wagt88`pYJG@K}&0=wmc!;8Fd zZv{QChhWOZLVbM?0sUw(77iT=@PuS084JJ#F*R3<9Qh{K+}NEj3)m_WFd@uUjzVSB zA%DK7ll(Gdbq(&wRhTm`vG&7g<~9O@uflgqF!Cxm6MQgfq3*B^Uo_Gg**zbmMm3x4 zLuiU7aYnzfLCHqoY)d#QW)1iAHv9V)AePhSnhtt6LemOd;ZQ$#cIZXkg=_D(|5A0(sNS`n%Nd7IdvOOOg|| z+@%1C+{U0;5^sgXfF-*MMH{9uv%;qeEN3Y=8lMlmhF_=oSe_PD%+9MygLY_yPh}0b zegi8X85)w7Tq|OiKm^@lfo~`kN(>W)=?*$mlucQ~Scc)NxP&ffqib?!NU)+`UOR*p z#YN&xWHC$P^yxLBLisY-3+95p2Che*nyQOJ?=YO@Wi8pBd2(v<{W%U=#vt2nv(xDz z_xJp?u4*>9YISBd_X{ZH<6zh3q4^>DJgt95s*$1?!k20MpI!3>-_14Z-r|TfObpQ*)X1{$14RjQs1+SZxh} zp2tuMFf?j>CR%jSRpkS3`)bYiiS%&ahfhd|E0_w@yr8<*nRYECBFistpCK_7-{ z&M`$xzCrCSj~IN1d&44v_qtojG&cqck;#k;vUwO9(trzF4u+UAS)WEo_j5bm?dOkP z>H)I9@2h~hrtk2pf!-rByb)?!zhsl)gWq^i@j-&i zsd-(`kgW-u@qv7*6FKW~shkmA*aFRH1}?22H&OKn-dPQE01VYJ@3U~0o|;*So9f2+ ztRhi%x%j!bSL`sdV|aPykmP_dO4en+g#?Z)0HCm=hOh`1Qnbon-H5OeNM7IgRsdvM z%nhaj-O%O$WZ*;P8dn_A+v8;X(uNl;B1y zf(jtnNr!0fGPxF%c)1|lc%%}PlZ-2K=KML_IuGaq2n7oY-`J*<%v$7mDX*cv6Sm=h zk3~(;BB`>_IqAqtaInYvclyCj1+$^(P6U9mp`i@5U&Br4T*t>5o=9U&su^n256P~9 zcXX|kWATnrZaWeeQKHfeWNip7Fn^f54O!!+HagzSb9-NO@OOQ1$3zQKCSTo+tzHcT zVNp4HgwhGIV5Yot7{p#(@YxUA6d8nw8%K+)7FE->N@uq%VVAaH=qyh1>#bLcjiZS;pe9rnCJv$VB|5& zz4kKF_N8znp<2^DuO2tTZxI)v522)E`Vf&Jc5OqWbjPB9(0R;f&m4o}By6`}WP$fg-6cpYY)VIv3!l>ZL?C*?OnbO3D-S%Q7M@E}}OF;0hk zo(ZXqVu}R-4F=z1wZDpXyOc`q{)V!uo$qiu5ZSi`A&V{tnw*>kLNnQ2(wzXNWHtaN z+h&F(eFvZ4-FBrpe9>qdGLqveoNg_^fV@+M-SRFS8g7c6vy0bv;WR@57sUl1GNTi7#0P7TE#vz2d)A;rHFlv&0cE<6;-pT=n z9-4pYgdXnt96S?Fihe^(&OL;mP>?@Vv`dkFtcOS6s{m6zurE|m#uYefw;HO*O+{@{ z+Sdbwtrs?&kA234Q9A+~o%kz~Q8V*+hJg#%HFK2UghOgknC~73bQtfP&Mc$Y5{5$7 zDKmZGw3EjNW@Q-7U!Bk;k&|Arm$=&z(o_ZhS!(G)>X4Os& zA-q*k>(I`vznsOOhrbd&nZRd^@in8Mif~d5`&=3P;91^bv{k9vdini<1pS30v3S;p zYg}fTip)5zEwFK0dtDn>db(7ZGdM)=Lc-kF(TMqUkv#XCsvOkNc-H-8Epn;iG}Zh@ zU$5)UgLtXJ^Y9NJdXdA9Ldmcz_Z6I(vh_xNejd-Xx>?37IX-Q=jL#xWy{M(>}r4VwI(j(j6GBOe59Y9aHVC@z#BR0N;t|F z2G%Di+;42!Ee@Uf#mb5qtj}l6MCV^`uM4osb2eo1l6-6Gd*r|*2cJ!QdW-~E%5O?@ zT66dV>d5)R9Wp*sHUhF8E2#ax2kQdIxY`ALchPdFwEgGWK0?QO8J=%&Y*}(J4+3ZYsPhKoo<_pL!w!!t-dVh?_WFj6jNQQblAl0d|6y(mkybKl$|~+W z%%&PO0=PYQ0?9#;J5WIGM@zhr&6qD*++u$JJ#>>{Ka1DtekJEfqH0j*d;<1pt1Up# ziTq_57#+GWt@o?RK8|P(vC?c*SDQ0%)4dU$EgFbkFYPS^?&N4||3mUF^JXWzSN$T$ zt=8spLahV|PxCZ8*A!!Ya4dFyGUv^lO93B8q=ZW%+ftb?Gdeb=bY+W$M${_9sW4>{ zp<;)uUfFm_OHX;{$Zk@4XhtewAl)UbV2u*Vz^oFsmL z4!qa)@1`LCM|9V`#VA%B?g84P14-Y^!4U*shrV8Hak0w1ROSj~!w}@cJAZ~!_^BOGzJah6q^ zO&a0Dy!yOoq~NTaAW`wAI75Ln($$TsScbL9p_YfDMGa;nrIHx$0VZPhL+9#)GkD$g zL-&&@x=8{dia9IfKh5L|&@s}-&jq*lMu5aH6E<~1#4JJW1Ltej{r)XX@Xi1m1&lkw zA-}$FIGJqLpMZR=024+Mm%j?ktGYW12OL^mqHzDlOHJWmz9(g+^`;bt!0$J(7;X+q zce&-tD48FGG4>kA{aF!7?>~16{DZi#?u{vTqrjB*n&oj{Z=<#W5?rM0;9)pZ#6m4z zI9>G>ePK|MD{0<`o#;ibt68--D_<-JUaKD~z(-dkn$uNj`hIEd4yY?LV3rS`3BnG$ ze{>`AULD>$8yYbvLkHi>6tYzC{&vc#eV zQTst`QCRDylj<83baOB&U|wODQ3|{$4<@FD1H-z2&)y*5c~dfsfkS?--q&I zQ1&UVJg?KOg^UoJ?HPtFg7wR|#bi{qQ+NShPtlTiw}(t zVr%WvOAqos@S`uzP;Bof*Ho zD@y#DgI=w_RVQH7*ydh(7BieojZEynNyFi^K9-;s&!7`ep&Vqqa}?{=lXvN~h^P{G ziAXy&m*3rTKtxWUh`@y_f}*EC3a7+gTMhS(C(nq}1sD(tt3K19dVTF2POO!{Znv`laE} z!qc-avCoZm?uZsEU6QP4P}xUYwYjEOW#PHvU}L-Asc+&L5sN#?FKgB}A|c4~;F9=! zKb_b<{{FGQs&Nvhr#y`JXb-V&qq>t$-%Z0>iypsOO0abV2c-|(?-m@Hm zRyl6FZI+%?oaj|aqZztFSw%}*FAoI>G}XvKFqxVtY6s0nRn$hSE09ti6o*yD%okDg zKo*Zuu9Bi5PB7R=Pu>P`Dq@Ezrm94~f>bL6n|!Yi)tgvQF>?KAlUT8_!$)(ak)@q= zq2`X}@z)hx%rZkheh<(xL&!rbQ|Rr&mojPok8Y`g<>Mc<{HhD6E$3JvDlgA z#mZz6lnD4izUx<{Oh>f^!cfT(NPtYzBG*`+)GwZ4Ju-qmBdoL1FB0E0f^kYWr{KIP zP@^XlMj^@S(IVu_Wa^iR4F#7jCQ}UWXKR3dq}0xLIi~ASGse$V3Y{W%Go*QOi?)k* z*517HuDuY&(z2gn(R(Y}Dy|8U9dUOFz_6!z1U<>-1mmo-TVBee05XNdmJP_l>&b~9 zItC4pF&|u%U2#U}d0BW|3R7hEW4t07I8M+2S@wG#`&A~_(q z2QSLKFob1kgurII3Ya8suUq`=TzzwPls9mEH>M|-x?kDWzW9IlK0e=D>%XTPdH#|J z*h-X-^Fq~E3a-)uQD|_SnW8W1e*eh)-AMwir@uJW|1*9Q$i~bDA7lcrWU&ulLe=ne1)38 zhLV1>FiJ0@5h*h3*(vGr)gnkC{(@`IsYEMv1j57l%GaFp>75+b$L*ifpc%YGW!IO;I6k)OR$ zuA>ap0!cpX@xzuwSf5}BcT0jPig6`#&0`Wjr&g{J@LW1e917X+l+aomLGo9gm?xS z+wf6M`TFbdM{6y%lG3+wajTe@Nr_7A>^3Be7AKz`Xd7#}`q?xq3&t){cRMX`mS`GF zGt4d1s?8wO#OhKoa(3%WLEfjMB+}+>1L<*l3kD@+uC?$2TJkKd$+aYPom$2grNsc0 zCL0x;hH@@70_n@wOm^GmvR-Etx`?jFLk-3}?Y!S$2234qNn=g;#c!3&D}y@6N~IjC z3Z!k+;4%5;pZ&(`+vNRin+(n4bcyKO)qP2Dr+{+chU6(~l7}xFY%miE=5H>IMWk|4 zbAeWcE~2!hx)acoDowW3)N~BGMt)f!|(u6Y>}7>Zr&+iF0}g zyT~vSQ5qFChOV^EhweEjwa7Jk``Feq+j6lupQiX^if z+Dr5_67ABG)FA3YUFeB<$bHn11*7TGv&-m;p3R?SRw+Ln68=Ju4I!9jMxyqTYaH~O zS-tL_OWip-a)Yl|BeiCk)fO1?j7dAOOVp4CmRZn&7$w73_$QP0PDE}4(CYyUixTr0OK3^)KAz_Di?H!W<3 z!EGKWNl~KT20PbXPN)MH#PrD@g84Svnd2K|xmJBI= z3i}EkxpNb5{MKK4a0x!KGlf&H?L7_H zNa%R;#vY#H7l%TPTIgu5O#@LNfdqCz+v1;C4WZ#nSxX({tdE`r(dk|Iiatx!@e)SL zq7W!C;QZd0Fe2{cO zS<5J8YED{d0Ob>JMP)fpusypD6qCQV$305Iaru01IGnzHtX0{~u6cx28#m28btsv( zzu{q)jFJ}B6fjyC12!Um=%PgN7rk;Hf(xK4(RM3tm8*%w)GP)%feT~o z&><5wSdLV0BgnxBb&eygqV7yIh|nryRA6M(@Nurgx&Y@w8|_ z(^D30YJ+bqD<5RQtEZRYcAC&@_;dC<=a|#ZJmYut-9Gn!p8ebVf1UlK3;3p(!SoA( z!@#Tuwt6TzdAI9~j^21B>_9G2$@c=&%@Q#{eh;IklOO-zFavN z8FeJa&BlpQAd(kalE~vF`g|}Y_6W9zF$_I*taA)e_PeyZ9z8b1Vk1Me^tM%kE3O8- zML}lO~QjmW+~>c zP>fiX7rWn;0bT1jRVT=BY#-ef;0H7}DJ zGNcTu)z<@Qso)FZ`xL766u=%x(?1ErXS65_yQJ=)i_|(OAomC$hNt~c$$WdSz!Oxt znDn7~J|#RUOx3lulq@A9PJ)zQB%-4mI)+;U!{24eiQdY_Rh%0h&PqtbQgDPEHJXm* zehW*$Iq60f2Q`s6%t{&w%~94%p2FE!8T@WXSBwzJ5X>Qd1;l^mASeLm&5_9b&ot5QxL{W0>H)tVlH zyX!nGV2at-m zo^z%QqdxtCFzN#TXr%3&(_pTmc*TUl=^!=p6`1KI6ket+2>rB_74=#*FK@N%hnbF~ z+NOQ?rK`q(3pdSa2X2bfHr!-LO&Du%P1rQNt~!uWcmAc6z?RCHr#raN>L648<-Tj^ zk8ako5^QMNtQq!3*@J{O;+nuQeXM+k)6N zsR#)dpKc|2aom)7tZqdLR;zPg6U0}V00MDmt6(coZk|9bQD(e z^&{Cz&1zxA?$*!s#@)E^qgc|%Z5c5Yny}dGm#v6PgZgxO(Tk~LwYpgQfYAa-h)jXWInlXB3wH~ z$rj~T`;z~BIXMUZOl`%PyhQ^TH6*s-mL9BpEKWo#3x}iRD{Q-P^<-A)X1A-SnJH>4BuHRx0T zq9RXzp@DJYbp4L#(fk>m$rcgPD*OWP{)P8eu7c*%=qpv}E4G7o4MUi?YUQw*z4Bh+;(%$9QCBgAf zsMVc)h$f&2C<^%X!+U-t%Ld)!4UnKg7~?OAv{+dbRtp8KtPVTyu|M5r&jtY5z0_pKT=;f5-4vFn>it^xp7u^MeN;r@JH)0TsX8)Wb}g3@FuMWDDW`yq5Kb;N{4>pa!~g z7Pm&QB}+^6Fh=$s9-J8PWOyZ3UoI$x#G2NE+di*~M{iYovPO@q{5@7(%eibqPpj4s<;R0T8 zI>mPJrMzW}y4l$o1JiRepaJTH+s2Irv%YmdxEA6m?~!hR=bVQaQmlc)RVXz0k)w?Q zL}x=8eZRlD6q<*5vnW}J&C%Lur4pgX&hl6_vr`}^DH39B8^+~9!(BCrnDH}*(wHgK z{9217$k71T(7){!C-ws@w7W(Tk#CwCK@5ikZ6v!xS@)b1P#nx4+1g>baVdka@&)H1 zMFO?3M-Af$HOYQqB4P+-bkyYt38gS(0Ut}=-G|{a_ohY-NZFBs978nJQN}|}uzvzk z4>rzKojMWgbMr6hi`Yhp6GJ;u|JPvEpwRXz#G4H@-QxT4yXh@ zB7Y&sp4uMn_DWW{3?36oh;oy9ikMLOge?T@X4~#J^tnyIokhZwz`&PP-+P1F4V_l| zPVNRe@C@(RMOdXIVfmFRu~gX!f6)L1^~^RxP|Ji;weiPPiqThb52wv(rT-ph_f>fTIlU zcox6~Imo%D_;AWI2ZZuvr2)BS$lN(a{_mh?aT;X6%$JcGi>(=-qTA8$r1(T-yMheP zsp%G8DG&(TO*a#sr;j(2WcxmHagoEMLx?tBPk z<~gyWqKWLnU$ctXYr@(@W%Szrlu`q`@em3^xSuK1OSd)CMRb52JctXmgY!z*cG)oB zp~ZQWkvy>w;I+sF<6e%E)0%EBNp@9~T3QM*M)t@IY=k1`S}8w3AU3of(Mv~<#5&to z9KD>28M2?zh?UV^lueHAAYBiOEZrKJ2DBMLljVR#?6jY5TfsG0gAVfjsRWb8tzDzq zAK`Gn8op#%uTDeIt1-tC^&5cEa1$CN5f>?4B*AoFsEm*pyrmC z=`_2n%9_$rR^*_YmB!*>@iNE7{BFeUG<#N>UVKoRF1w((IG)w!ZIRXXVZ_aB{xG*! z>Si(1tGM4E>?|yNUz4LLFF)H(XWBYGVb7aZ&ykXI@l0}riOsX<$){Z()(t~H>VB{J zItEl&p!#_4C3x|;{E4SEY5rP%NPEI0(~H$$MTdLzeKMiVP0{pPZhWB zN=cWF4yw`InBgoVe!|n83)%GWtwR3mdxJ1=@R=mG#M^tzlsh_hySm;v*)?Zr-g#7mRSMlkIINKarlJONS7iNs5#YPL99kpN>2E zrfBJCPnzt15-5f(LoM-h9p0>ZJJZUfP)%J3pu1wzlY0`Lz+OJcJP{^5)FI>8iFOcKHm8*-j_DFU+2-1YKdag;82~g^ zk;?;L0w^=6r{t` zdwQR1UB=CbZ&KeHw2f9~AdD5VK5zl#!F;sWXa0^$XO%!eW)K^+^K5o%UTyMM%FwLh zBW1KMTp6hC7UF8A_uZV>I;=lfut6h7tVbb#KpRgK!#orRp1wLhrJ+M<-)ryk zY*xOW72cF43l!kySuz_KUfRnZ#&-c5m4YMf-_%*)r69 z(LHNTdPF5v;tb%M@UmkwnX^2#s~y2(c2jwL$0EAE()b{^o*Jx>1PzeFO$Em}Kp3xb zioPn-Op$6LW2NJ>C5{nG_CXO!>jWX|M&FM=c3n0^w;c?P3XThg!)I*Gh;{n z-;>X%gz@NfdX%6?H)x}Av`7N+TChkZW##sgA_YY!b%qC6yU#3j(ts{6SWuxE>13Y6 zcAqZikGBPuUVM5L3*|3JgXBPijj?64Q;)OX=>;eEZBkBe)$R2JZo9zt`_QydpVW+( ztx!u?!;eQL#+2s$jiVXY{WJuYl1&r~)!i%$UbJ%}9B}(xF@nv+h^#H7$O~QV(Uq=} zPTgmv61On0FsRg|2>sEW&#tD6M4VUS7u;!>b{u9ETZy9|U3v1iIDQ;_KvKH&+G`qW z_`uvy_`pI-?Ke>9dXA<@kCJ=65GbdCHV;is9O?Gp@|f63W^X*!AreT>SV@Il+DE5t zNh!feY#O4)6H6V1A)w(eeWdOVYP|vzWa>H$|GWXW0vIo5xV-pu9C-=z+B`Eq+j4jk zhR_i|JEOOMwRHT}8wfI?;0H-+tR?2hQ(g}T*#{p#(r@%a-?|xp`nh>RRxfjp@v>|Y zT%gKh|1C?Asl2Z8L^-ND&l|Vdx!M`~D|c01sfD6b%3$s#n&p%T^@-n%@Buo0Unc(H z$+@A#f#%5dc)Ml{Yj)Ec#P1^hl+2v04Q%wytsLka|9MDj zYh!v2P?p1niTy4}F+-RuthpA^j_i*r;Rk}Rv8El~p45aw(ICgvVi}9#5{^P~K>-Sn z#>KBN?8W+MOUKIUaM?`PUVrQH#QW~z!Xon+#j(7581w6X07F#sJ|E-KKtOoDsaKoO z9H{LxWhh+4gLed0k;cRMSulVs1+n9UPho zDpTbZSu>Cr@QxQ|hfir+b@YE`3rDjv(D_IrlNfm<%!*ktT(!fEr2ZgzSy1H?)Hn^3 zzI)I1Zt;f8lCWr}{E z#Nx)e-Xh=4`{7Qa_9`h52-wMb9dkrYA1aa1n1Ovc=OUg#7i@Pbwpl^%S;&$DViHBS zr4&+VT`Ipph6u}ibmIXI^a6v_C;E}JqTDGO=P{SfG1&qEB%TXvBkg1Qv^iQ3djQ_* z4!{jjs*6pz&HZYiPSL*GM)%}W>gnYY{*s7IE$WsO0sH1ookc%>T+iC&D&p03oSEQ40AX0Ma9aQkFa*x{$c zn@^SU5kGogDj>KtRvB(autFFU`TMhy$@JV@cL-)3M(4LF6meD&InIMvoOR=^eUkHO zqDT8X^Ml=7KsUzLg{GPD*ml;@W6kx!EXwYKaLQs|!eK0ly!4sJI?)9@e4LyEtqwaE zef{XP`n6aolnJv`4r^ZX~5PH-HtZ-D+b7V&%cn2I!T=c%lm6{Z^bqxPu+EHdYI%%}R zrpmO+H*p2fmrx5hq9_SM>Q0+1)RIS(M+4Z;$CL#$y@_;JjugLZ#jR(Y2$103)<9+(jk?#;1xoQs`M(9CrzV zZ_@=kO;h{TMfO^@s#(pn)v8BQ+CIs^wIM_%CAuzj^~RgrSMIyye8GSOv3r%XCP@VP}o~n+R74B0f zKciYYOE7M~XZA$>s%{si-QhK--SH0J+>%8P)|8ze)k$@CZRgok-6x{igaa4+ClVZ{ z&wZEq;|W7e=2TjNFLB;!Fe1JN+&e4!+RL-r3+-2z{_kRWHQoMNdp#>wH7xjuydyZ>$zE76WA0|@n--$Vq%dlYG z#A|^tYSCfEwI2@=gFLR}k+EEWK+ARiWHb?IbgPk;rPhN`3f{Z1_XB%lZJ%|20Pq-xQNE zOSzav?(X27LRLu)+nP2~EC`XzC(=H&Z^hlG4U+V69iB-j=P;PIyUCTUvc&<9=y$1+Q?f} z3iT9i@wB&rw^v;(|moVfNLKGWN*RFglYM?N^ zIO-25r(OJtKDR(7^piX6faUT;AL-NE1j!h+09@~ZVcJ!Pi+puK7l5U^uFjFW@e}B)>ml~B@ zIT!uiQyJ~=TN{%xWR9J)d>UH(vWYnM797js=Z9fV^+zJ*hH+!a9j<7K(LJStGAFX# z9N|L72eF{LLDD!QL=3v}>8VlZfdbb-SH!1P0XN1Qm((cn9x4)E%`T5+aO>SD#E10Q z)lmg1pf0DA78gFa(``XF*IpJ(m~CWwdFaD9yORa%5{tW74r|-;H;UbG1qx}3N4(|4 zC9v)#ic(TCV_PJJyxJVp320q0*+aPz5=zk_6y#&=qP(5)Nx6RS8;;S3Kfkm$zJ@ok zeS2%I&a_$RH`+KON^c5;7sB%ZcHK+pq2}Bk>uS<17RW83kw-v;Ne7wnwa7|> zY;vo_k#WqOq!N848HLEp{Xsp;q2pI_knErUk!Z0q$(u$U!!O)e0X#=h?U6u`k84x?(;Z}oV#=Ye|J zEyg{}iK4WmMv<6%eZPk4EonmI7005k4nxvw7EWZpxuUN196T57j&od!r=vZZh=a!J z9t~l+2(_=!Bsd;@#+0kw=Q58?i#CE8L474DAE8BPX3`i+nr6hZ7YPB5Q8a%Y3xm4SYYuyQrp6CGZSx zb?ao#D$jK{399-aJ9&afl`fJcH0bDpE=sj71Qh*5hGHM9b9abs zMqp;qIDj#a79C;($kCE^*E|K=2e`VHh;$cJT$kPdy-7ikbcb8-YeGE1F8Ob-9%mqk`GfJKli4-?!P^K<9K+&lr}4o~c*v(2r42 z1lKA#@A{dvj3$#feIA&grRh578?$q(0bTsnVQR#NQ{~9a+fJT1EezvTN`hLJrW@lI z7fNjPGdlsVN3!uBBr^-tG$j#Ks+f|##p}6v9 z3U=W8v1{3r0?U2$JhH7ZI|!MAOxxvw+e8VuUa*4aIZEFHIWe`Wo(2c}4AptDh}hj; zv8=d9;t#aH||hi3*-$?$T|Bx^rDw=q0i$ z=Q;JgT~#fDx=nF3p$7YwU#!UG-Qh771M<@e>NXOaZTk^2AqV)(&hQ3Xi))Lcd3~ty z6NYoeg@o2A!s+v|?Nz`?G?~krC$3VQ2$9tF@wke~(u=T1Q4}Pv*7~)r!jd?Z+8a8F zg9m74@3_$!3Z<>5rSW9p4^t}y2ZYe}0>Gb{XkdjhdPlYK80dyQY~+F+S| zwb!)JMRdk>&1Yx4+&m(D{_xromNM+wLmpVV-3&j4q*t;hGO=qHieQ6bHDe45}N$(d6a(|Ee`; zOwcOptmhcxfj-Y(7VT;)y~p>!LeqLY)yN5`<=YuZvWikn1)ziD+jAS**kjI53RMc` zaGiOCjxICQo7|G4z z#}Rg}f-S;NmpXjDPj;lhTJSK2Nc^7gb}sXqSr$?}2sdve9ZSX6TirG@mf!O{=*w<~ zT36|G zJK6KZ8v`)Z+)EI6DXbAgr}I4(MY{tgf$rTPInT=P4D@;%wgnV%df+;6u3pW zyW<;FcDVGUiyfQ;zeR6*GI`Q(wta|PD8Q}Z^C^LL7weQX)rFMkj?Fvn>jz$ zinOH^U8yQ|D$tpJQFq>F>gGXv1Uef0d8F2Sn%*TkYA0EKXyC@{no=$VESh2aiB@Q5 zbcxk^+5+9@`Nt+3d(1K_zgUf57Rwz(tLhSs5G#RzB^2aVM4)+dtvJvFJh;!$txQZaeyhnb?t zr*e`-zNiBcWB1J54>g6AsBs5_=Nu>(636&kPtJ@(DuBl~gP}d!Bq5{uDQr7`d*mPc z6begSdfR|IQg4N{kLfMEYOHCbHOjgQBS3bpfx!Fhj=HRC_BYe`#u3xpn|6ur z=m!TZ){SrB28P0<(P*-uu7LnYE^QTYAo~jWL!b)g_~RbGh*zkwd=XqtT?DyzttJiT z7{?1`_*nb7NG7?qtbrlRr!RB_Y$!)obWeSHO%ja8(IWkaKpMr?oaVM>=p1OPnWfCm z6Slz!KVE&GO;uU88bsNvQ;Yl^B|$iSkS`539$vV&Di^=Y;TNWqLmgianxDlb+Fytj z)ukh#qg=Tq%>RgIFMBSxm(Zm4G9`mjc5H<|?;_nr3mYs+Y>}Z;6(%!7aaHoNP^T%; zw`l6D>8n-Hw(Z?g+CG_|lFUAHGfG#LS|O_b+(?AB#f>_4h>(6r`5531CU?%Lre?dbQ}Z;hUbxX$UcVwnp|7Nut&R&A+5=4o90i!^q*;Q?0LM4_It>zvw4-8eO zQSi=Y0IMQ(>@($DZKHIJbhor$-bH%prn|}deEO&Dzyk8!m-r=l6P^#lCoS)1S|k*Y z@VE!SCj8inb*!7p%HhdWO~I%sR<(e~y-{h2a~~njQUjZ!b{UYHdbqt753|*0Id={c zvt%S&24fK~?>aA8!mueE@8t(4VVYy5YUJzTpm$r#eN;<6{VNIl#IzP@I%6a?BI^_2 z7}>pvMYQ2m{{-__#LY_qwbjY+=nN&YQugT zfLuX%Zw$g^SVn8Y4OY56M5r`=5pyM`g6bf=9_lp?iB*thP?sUMomCL6;=4!=Z+sP@ zQ@d?0bWjZ&*94@sNzHFv{asPGLOzvI5I?z)t&u2&Lp+f3S!ryH?@d|^B2vd` z@$J#bKGQVkZoW~J`J}5YCv}1I2CBO{o+W@*(wC8{VM)TC7PS+^;T2QstjXX()9JBx zKup7HdJG9`9j#iV@~}!x25)+5>y=it)nFRzpdvMnv2uDcq>IIBcBKR} zIWvN%)peU^u<2GobVd$T)Rq0l4KF-TWCb78-ArQ9`9Kgb65IN``Q)3f78i+F-n)sU zw=Op9>D;dOYwx?Em&_VZn%8Ssi9C&TCZ1xSS*;9v=W;$-VKIw31ZLiVI=x6Pc)0SC zC7&f~Oh!C(thIGI@9H~jYY)CzqTU82)cpPN67ge_sX?<&Y)T)oN1;tNAuA3##qxu7 zdotDZW6#)R*Ir|wt|)7LtY!_{k`;On!b=srJ|Q@r`=+LZW^Rfe69MiF{^Zzt6>Xr_ z`+?pR-~jW@cmBC1Axp$(GAJCEuNm(0YKeD>LvqsE@Oh1#LoWQ8UeZEPlK|wc8>|xH z!_a4>@@GEAK<1^<=ss`zV3@p2-{K6F;{iNm19OfmO3H_R zM5>61J15_6N9|P}-oEQ`;)hujjx>cEdBxsZuDT(Gk;Wu!0@|}h8{SzF%qKk!NZzyW zg+{Z34P*uPCi!5T=WZ<#qF>|n=x37<(oc(8T;Los#YVC6X2o0ooED;{q#7HW zf*fx(CW5)uez$?dV$T|c^l@35mc}wp>cbjYe4|W%@><)#-aazBO*%%FcfQ=+gO1LI z17g`RB-{2KsTrd3#7{LVBsAyZ-(JO+CDVl^Td*V>QrL|+ale|aiH9o}8|$v6wW&Y? z8Zz3)qn&G6Fsz&EQ=-S`m)8xt-dz76HBmmLg`)Bz=p^8?dbzIgIM)x|JsGQt+;phxWfo-?cLQWoeC2-T&2ea) zN4>D1RS2lBfJk9?UFOZVrcmg$EC8+%I%J@hM%NMW+Y{7GS2pw ztv%IJMeGj$iKc2Q+?G=Vq5G^5Sq{bax9g_%YqjBk0f#gAw}C`XF&FrxMlXmQEMB`y zy53}{go#O3ge6e>Y{IoD=S(}dXt<YOfz__>Z8q5(ou4d#RZA+Ddch&uq?!_6{Ms zdS8r7m*wu+PE?Y=llu%1qQH2aGnLI6DAIOS6u9J5kNyC%C1>qr{G!kxR?qAS&et8C zor1*nd0bbLhxqwkyIgq0!qscDrtag>s&k}#-Qdk1laeP4k4Dh9mo#fe9b{e9b#(AX zryf;Y3G#Fc*lWlsWn!cT$nX8R0%AU(B7gs6DCPk=4`{07?T&y#A z`m31i?mVPNl@y_Jh*?!X$Q*)j$t9lcf}gJrCqMmuLVU1p!H7~#>tFA2?yB~5=U(4L zQ7SFJy!-rv&$FAHPGN!#1k{cD-`47WV}%@y9UaYWO#k5rY*g2FSm8kMnyl7)lYxXv z0VmBh6gw^?@B^Otah_g-eic=5FJ|xSvzcU_nplk#nI&dquBwsEZK~S!+6L*ijavXM zx5l|YMpX>dC&-I1>v3p2N4vqHi;a%%!Uh1voAbKcK?tO!oJu<=0jWeU%i`&BF`zgZ zR?0c?56U@NDK`W)Xsr0KbLPHIj;40~vT>0KSdi~jN}D`PxlNZ$oK2z}pNYMqJq zy34!eu)04IMr{XvP z{l$c+vkguX!)T#x=Wzmp*Tk2?PqjvAp!fA(k6yg9#aRpjQ}hS81gSj)@{BVA!d?f| z-GM|N^%JHh1|K@ru*Hw#(LZ#7)>J3$*udSk%540OZi|6`mGS8b>BQHh|`WS@9E)}3fiweKtDu#oAunges%B9rucwFMrrn4 z6##mEZTbQUIn?g>)lxYaTiEkCkB^6b{H(<+y|2$%0dAS|O{!YVJ#SDxv)W_b`7U!e z^*ZD%_2EKj}R|fREwJ1+XY8t{tE& zT@vXe>n+C?Z%VOJhI3y z9utv%4)6p%uoWs30EYWpvsZS6v_bJWS}SbaNm&mByMK^(67>lbG$a4KN?2LW_jhV& zSw7AC3Kgdju#oW~VW(w`g#lwa3nlHqSQHE&^SH_UQT%i}Rd{ApKWC5@o)u`{xXyZ# zz^_0j#6J+VD+?)BN=B^m8&y*tB#@MajJu`rHz}O!KP@NLmu%x4hT)&+YD&5G&>Syi zD+oln4F`7TQ^?XHIw-Y3VR#QnKqM53Q{7`7Eh8f{>`FtOjXP5!k0TMP2>WqQnQB>9 zDg9t&Qq-;`8A?~v(mt9DrH?>Dxmh}+qMKdq>K&;fESfUfSXDBhe$Y8v?lJa;Wet+H zSGA}#Mo*VS1KkucB6{A_uZ7UC$fLjyUOlsY{HVj<7NTrVATLF=Gfn8nx9tIrlK7B6ft%|i>2tkrA<^2>oQ`asFQi_ zh~Hle=^j7O6W4@rv&B!rlv+e9hANmEo!XYVo+Lbl2@wg{+IT*iB|~7`4mka!(3PGg zF$r#ZD8-WBf8hUKRBtiGyP>e8aGzI$!hg%r=~FnR-6Zx>f3AU_ALt#$Vwq@aHCuzvumF)A|Rm^ZzE^OZ`HQ{;&J)?^%CN82@$TmSq03q3iD|e-_q% teNBND|2ozDd*+`7;CJEuEAqbmhcYZD2?qZAGK60r@?X`Q$?o^r{{f8rNx}dC diff --git a/doc/rfbtight.tex b/doc/rfbtight.tex deleted file mode 100644 index 088ab60e..00000000 --- a/doc/rfbtight.tex +++ /dev/null @@ -1,1121 +0,0 @@ -\documentclass[a4paper]{article} -\usepackage{geometry} -\geometry{verbose,a4paper,tmargin=20mm,bmargin=20mm,lmargin=30mm,rmargin=30mm} -\setlength{\parindent}{0pt} -\setlength{\parskip}{1ex plus 0.5ex minus 0.2ex} - -\newcommand{\typestr}[1]{\textit{#1}} -\newcommand{\literal}[1]{\textit{\textbf{#1}}} - -\begin{document} - -\title{TightVNC Extensions to the RFB~Protocol - \thanks{This document refers to RFB protocol versions 3.3, 3.7}} -\author{Constantin Kaplinsky\\ - TightVNC Group} -\date{Revision 1 --- July, 2006} -\maketitle - -\tableofcontents - -\newpage -\section{Overview} -This document describes various extensions to the RFB protocol used in -the TightVNC distribution and in other software compatible with -TightVNC. Only differences from the stardard RFB protocol are -discussed. The original RFB protocol specification (protocol versions -3.3, 3.7, 3.8) can be obtained here: -\begin{center} -\texttt{http://www.realvnc.com/docs/rfbproto.pdf} -\end{center} - -At the moment of writing this document, TightVNC supports RFB protocol -version 3.3 (all TightVNC versions) and 3.7 (TightVNC 1.3.x). It does -not use the version 3.8 of the protocol, and it's not safe to assume -that the TightVNC-specific changes to the protocol 3.7 initialization -procedure can be used with the protocol 3.8. However, all encodings, -pseudo-encodings and protocol messages described in this document can -be safely used with the protocol 3.8. -% (pseudo-)encodings: 3.3+, messages: 3.7+ with sec-type == Tight - -TightVNC introduces the following protocol changes: -\begin{itemize} -\item extended protocol initialization procedure, -\item new encodings, -\item new pseudo-encodings, -\item new protocol messages. -\end{itemize} - -\newpage -\section{Protocol initialization} - -\subsection{Protocol version 3.3} -\subsection{Protocol version 3.7} - -\newpage -\section{Encodings} -\subsection{Tight} -\begin{verbatim} -Encoding type: 7 -Name signature: "TIGHT___" -Vendor signature: "TGHT" -\end{verbatim} -Tight encoding provides efficient compression for pixel data. - -The first byte of each Tight-encoded rectangle is a -\typestr{compression-control} byte: - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & & \typestr{compression-control} \\ \hline -\end{tabular} - -\begin{quote} -The least significant four bits of \typestr{compression-control} byte -inform the client which zlib compression streams should be reset -before decoding the rectangle. Each bit is independent and corresponds -to a separate zlib stream that should be reset: - -\begin{tabular}{l|l} -\hline -Bit & Description \\ -\hline -0 & if 1: reset stream 0 \\ -1 & if 1: reset stream 1 \\ -2 & if 1: reset stream 2 \\ -3 & if 1: reset stream 4 \\ -\hline -\end{tabular} - -One of three possible compression methods are supported in Tight -encoding. These are \literal{BasicCompression}, -\literal{FillCompression} and \literal{JpegCompression}. If the bit 7 (the -most significant bit) of \typestr{compression-control} byte is 0, then -the compression type is \literal{BasicCompression}. In that case, bits -7-4 (the most significant four bits) of \typestr{compression-control} -should be interpreted as follows: - -\begin{tabular}{l|c|l} -\hline -Bits & Binary value & Description \\ -\hline -5-4 & 00 & \literal{UseStream0} \\ - & 01 & \literal{UseStream1} \\ - & 10 & \literal{UseStream2} \\ - & 11 & \literal{UseStream3} \\ -\hline -6 & 0 & --- \\ - & 1 & \literal{ReadFilterId} \\ -\hline -7 & 0 & \literal{BasicCompression} \\ -\hline -\end{tabular} - -Otherwise, if the bit 7 of \typestr{compression-control} is set to 1, -then the compression method is either \literal{FillCompression} or -\literal{JpegCompression}, depending on other bits of the same byte: - -\begin{tabular}{l|c|l} -\hline -Bits & Binary value & Description \\ -\hline -7-4 & 1000 & \literal{FillCompression} \\ - & 1001 & \literal{JpegCompression} \\ - & any other & invalid \\ -\hline -\end{tabular} - -Note: \literal{JpegCompression} may only be used when -\typestr{bits-per-pixel} is either 16 or 32. - -\end{quote} - -The data following the \typestr{compression-control} byte depends on -the compression method. - -\subsubsection*{\literal{FillCompression}} - --- If the compression type is "fill", then the only pixel value follows, in - client pixel format (see NOTE 1). This value applies to all pixels of the - rectangle. - -\subsubsection*{\literal{JpegCompression}} - --- If the compression type is "jpeg", the following data stream looks like - this: - - 1..3 bytes: data size (N) in compact representation; - N bytes: JPEG image. - - Data size is compactly represented in one, two or three bytes, according - to the following scheme: - - 0xxxxxxx (for values 0..127) - 1xxxxxxx 0yyyyyyy (for values 128..16383) - 1xxxxxxx 1yyyyyyy zzzzzzzz (for values 16384..4194303) - - Here each character denotes one bit, xxxxxxx are the least significant 7 - bits of the value (bits 0-6), yyyyyyy are bits 7-13, and zzzzzzzz are the - most significant 8 bits (bits 14-21). For example, decimal value 10000 - should be represented as two bytes: binary 10010000 01001110, or - hexadecimal 90 4E. - -\subsubsection*{\literal{BasicCompression}} - --- If the compression type is "basic" and bit 6 of the compression control - byte was set to 1, then the next (second) byte specifies "filter id" which - tells the decoder what filter type was used by the encoder to pre-process - pixel data before the compression. The "filter id" byte can be one of the - following: - - 0: no filter ("copy" filter); - 1: "palette" filter; - 2: "gradient" filter. - --- If bit 6 of the compression control byte is set to 0 (no "filter id" - byte), or if the filter id is 0, then raw pixel values in the client - format (see NOTE 1) will be compressed. See below details on the - compression. - --- The "gradient" filter pre-processes pixel data with a simple algorithm - which converts each color component to a difference between a "predicted" - intensity and the actual intensity. Such a technique does not affect - uncompressed data size, but helps to compress photo-like images better. - Pseudo-code for converting intensities to differences is the following: - - P[i,j] := V[i-1,j] + V[i,j-1] - V[i-1,j-1]; - if (P[i,j] < 0) then P[i,j] := 0; - if (P[i,j] > MAX) then P[i,j] := MAX; - D[i,j] := V[i,j] - P[i,j]; - - Here V[i,j] is the intensity of a color component for a pixel at - coordinates (i,j). MAX is the maximum value of intensity for a color - component. - --- The "palette" filter converts true-color pixel data to indexed colors - and a palette which can consist of 2..256 colors. If the number of colors - is 2, then each pixel is encoded in 1 bit, otherwise 8 bits is used to - encode one pixel. 1-bit encoding is performed such way that the most - significant bits correspond to the leftmost pixels, and each raw of pixels - is aligned to the byte boundary. When "palette" filter is used, the - palette is sent before the pixel data. The palette begins with an unsigned - byte which value is the number of colors in the palette minus 1 (i.e. 1 - means 2 colors, 255 means 256 colors in the palette). Then follows the - palette itself which consist of pixel values in client pixel format (see - NOTE 1). - --- The pixel data is compressed using the zlib library. But if the data - size after applying the filter but before the compression is less then 12, - then the data is sent as is, uncompressed. Four separate zlib streams - (0..3) can be used and the decoder should read the actual stream id from - the compression control byte (see NOTE 2). - - If the compression is not used, then the pixel data is sent as is, - otherwise the data stream looks like this: - - 1..3 bytes: data size (N) in compact representation; - N bytes: zlib-compressed data. - - Data size is compactly represented in one, two or three bytes, just like - in the "jpeg" compression method (see above). - --- NOTE 1. If the color depth is 24, and all three color components are - 8-bit wide, then one pixel in Tight encoding is always represented by - three bytes, where the first byte is red component, the second byte is - green component, and the third byte is blue component of the pixel color - value. This applies to colors in palettes as well. - --- NOTE 2. The decoder must reset compression streams' states before - decoding the rectangle, if some of bits 0,1,2,3 in the compression control - byte are set to 1. Note that the decoder must reset zlib streams even if - the compression type is "fill" or "jpeg". - --- NOTE 3. The "gradient" filter and "jpeg" compression may be used only - when bits-per-pixel value is either 16 or 32, not 8. - --- NOTE 4. The width of any Tight-encoded rectangle cannot exceed 2048 - pixels. If a rectangle is wider, it must be split into several rectangles - and each one should be encoded separately. - -\newpage -\section{Pseudo-encodings} -\subsection{NewFBSize} -\begin{verbatim} -Encoding type: 0xFFFFFF21 -Name signature: "NEWFBSIZ" -Vendor signature: "TGHT" -\end{verbatim} - -The NewFBSize pseudo-encoding is used to transmit information about -framebuffer size changes from server to client. - -This pseudo-encoding was introduced in TightVNC, and was adopted for -use in RealVNC 4 (see the DesktopSize pseudo-encoding in the RFB 3.7+ -specification). However, there is known incompatibility between -TightVNC and RealVNC in the way the server sends information about new -framebuffer size. TightVNC implementation requires that a NewFBSize -``rectangle'' must be the last one in a framebuffer update, while -RealVNC does not make such a requirement. As a result, TightVNC -viewers may incorrectly interpret the data stream received from -RealVNC 4 servers. - -Hopefully, this incompatibility will be fixed in future versions of -TightVNC. Ideally, the server should send NewFBSize ``rectangles'' -according to the TightVNC rules (with valid rectangle counter in the -FramebufferUpdate header), while the client should interpet it in -accordance to the DesktopSize pseudo-encoding description from -RealVNC's official RFB specification. - -Below is the complete specification of the NewFBSize pseudo-encoding, -as it was introduced in TightVNC: - -\subsubsection*{ -\begin{center} - Handling framebuffer size changes in the RFB protocol v.3\\ - Technical Specification, revision 3 -\end{center} -} - -\begin{quote} -The following pseudo-encoding is used to transmit information about -framebuffer size changes from server to client: - -\begin{center} -\texttt{\#define rfbEncodingNewFBSize 0xFFFFFF21} -\end{center} - -A client supporting variable framebuffer size should send this -pseudo-encoding number in the encodings list within the SetEncodings -RFB message. - -After a client informed the server about this capability, the server -may send a special rectangle within the FramebufferUpdate RFB message, -where the header contains encoding-type field set to the -rfbEncodingNewFBSize value. Fields width and height in this rectangle -header should be interpreted as new framebuffer size, fields -x-position and y-position are currently not used and should be set to -zero values by the server. Unlike true rectangle in framebuffer -updates, this one should not include any pixel data. This rectangle -must always be the last one in a FramebufferUpdate message, and a -client should treat it similarly to the LastRect marker, that is, it -should not expect more rectangles in this update, even if the -number-of-rectangles field in the FramebufferUpdate message header -exceeds current number of rectangles. - -Immediately after receiving such a special rectangle, a client should -change its framebuffer size accordingly, and should interpret all -following framebuffer updates in context of the new framebuffer size. - -Changing framebuffer size invalidates framebuffer contents, so the -server should mark all the framebuffer contents as changed. - -FIXME: Allow zero-size framebuffer? -\end{quote} - -\subsection{RichCursor} -\subsection{XCursor} -\subsection{PointerPos} -\subsection{CompressLevel} -\subsection{QualityLevel} - -\subsection{LastRect} -\begin{verbatim} -Encoding type: 0xFFFFFF20 -Name signature: "LASTRECT" -Vendor signature: "TGHT" -\end{verbatim} - -\typestr{LastRect} enables \typestr{FramebufferUpdate} messages that -include less rectangles than was specified in the message header. For -example, VNC server can send a big conter like 0xFFFF as -\typestr{number-of-rectangles}, then arbitrary number of rectangles and -pseudo-rectangles (less than 0xFFFF). Finally, it sends -\typestr{LastRect} pseudo-rectangle which marks the end of current -\typestr{FramebufferUpdate} message. - -The fields -\typestr{x-position}, \typestr{y-position}, \typestr{width} and -\typestr{height} are not used and should be filled with zero values. - -To enable this pseudo-encoding, the client specifies -\typestr{LastRect} in the \typestr{SetEncodings} message. From that -moment, the server may use \typestr{LastRect} pseudo-encoding in some -of the framebuffer updates it will send. - -% For each message, describe its place in the message sequence. - -\newpage -\section{Protocol messages, file transfers (client to server)} - -\subsection{FileListRequest} -\begin{verbatim} -Message type: 130 -Name signature: "FTC_LSRQ" -Vendor signature: "TGHT" -\end{verbatim} - -The client sends \typestr{FileListRequest} message to obtain the list -of files in a particular directory. The server is expected to respond -with exactly one \typestr{FileListData} message. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 130 & \typestr{message-type} \\ -1 & U8 & & \typestr{flags} \\ -2 & U16 & & \typestr{dirname-length} \\ -\typestr{dirname-length} & U8 array & & \typestr{dirname-string} \\ -\hline\end{tabular} - -The \typestr{flags} byte has the following format: - -\begin{tabular}{l|l|l} -\hline -Bits & Binary value & Description \\ \hline -3-0 & 0000 & do not compress file list data \\ - & 0001..1001 & use compression level 1..9 \\ - & 1010 or greater & invalid \\ -\hline -4 & 0 & list of files and directories requested \\ - & 1 & list of directories only requested \\ -\hline -\end{tabular} - -The client can request compression only if enabled via the server's -\typestr{FileEnableCompression} message. Otherwise, bits 3-0 of -\typestr{flags} must be all zeroes (for no compression). See more -details in the specification for the \typestr{FileEnableCompression} -message. - -% Add a note that specifying compression levels is not fatal here. - -The \typestr{dirname-string} should be an absolute path represented in -Unix-style format: it should start with a forward slash -(``\verb|/|''), path components should be separated also with forward -slashes. There should be no trailing slash at the end of the path, -except for the root (highest level) directory which is denoted with a -single slash. Note that Windows-style path like -``\verb|c:\Program Files\TightVNC|'' should be sent as -``\verb|/c:/Program Files/TightVNC|''. - -\newpage -\subsection{FileDownloadRequest} -\begin{verbatim} -Message type: 131 -Name signature: "FTC_DNRQ" -Vendor signature: "TGHT" -\end{verbatim} - -The client sends \typestr{FileDownloadRequest} message to start -downloading (receiving) a particular file from the server. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 131 & \typestr{message-type} \\ -1 & U8 & & \typestr{flags} \\ -2 & U16 & & \typestr{filename-length} \\ -4 & U32 & & \typestr{initial-offset} \\ -\typestr{filename-length} & U8 array & & \typestr{filename-string} \\ -\hline\end{tabular} - -The \typestr{flags} byte has the following format: - -\begin{tabular}{l|l|l} -\hline -Bits & Binary value & Description \\ \hline -3-0 & 0000 & do not compress file data \\ - & 0001..1001 & use compression level 1..9 \\ - & 1010 or greater & invalid \\ -\hline -\end{tabular} - -% \typestr{initial-offset} -% do not use compression when not enabled by the server - -After the client sends \typestr{FileDownloadRequest}, the server is -expected to respond with one of the following: - -\begin{itemize} - -\item \typestr{FileLastRequestFailed} message, if there was an error -opening file on the server side. - -\item Arbitrary number (including zero) of \typestr{FileDownloadData} -messages with file data, and then one more \typestr{FileDownloadData} -message with \typestr{raw-length} and \typestr{compressed-length} -fields set to zero. This is the normal scenario when there was no -error and download was not interrupted. - -\item Arbitrary number (including zero) of \typestr{FileDownloadData} -messages with file data, and then one \typestr{FileDownloadFailed} -message. This happens when the server cannot complete file download -for some reason. - -\item \dots - -\end{itemize} - -% Can FileDownloadFailed go first? -- probably yes. -% How zero-size files are transmitted? -% How to detect the beginning of the next file, when previous -% download was cancelled with FileDownloadCancel? - -The \typestr{filename-string} should be a file name with complete -absolute path represented in Unix-style format: it should start with a -forward slash (``\verb|/|''), path components should be separated also -with forward slashes. For example, Windows-style file name -``\verb|c:\Temp\Report.doc|'' should be sent as -``\verb|/c:/Temp/Report.doc|''. - -\newpage -\subsection{FileUploadRequest} -\begin{verbatim} -Message type: 132 -Name signature: "FTC_UPRQ" -Vendor signature: "TGHT" -\end{verbatim} - -The client sends \typestr{FileUploadRequest} message to start -uploading (sending) a particular file to the server. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 132 & \typestr{message-type} \\ -1 & U8 & & \typestr{flags} \\ -2 & U16 & & \typestr{filename-length} \\ -4 & U32 & & \typestr{initial-offset} \\ -\typestr{filename-length} & U8 array & & \typestr{filename-string} \\ -\hline\end{tabular} - -The \typestr{flags} byte has the following format: - -\begin{tabular}{l|l|l} -\hline -Bits & Binary value & Description \\ \hline -3-0 & 0000 & file data is expected to be uncompressed \\ - & 0001..1001 & expected compression level (1..9) \\ - & 1010 or greater & invalid \\ -\hline -\end{tabular} - -% \typestr{initial-offset} -% do not use compression when not enabled by the server - -Normally, the server does not respond to this message, so the client -can start sending \typestr{FileUploadData} messages immediately. -However, the server may send \typestr{FileUploadCancel} to make the -client cancel current upload. The client can cancel current upload by -sending \typestr{FileUploadFailed} message. - -The \typestr{filename-string} should be a file name with complete -absolute path represented in Unix-style format: it should start with a -forward slash (``\verb|/|''), path components should be separated also -with forward slashes. For example, Windows-style file name -``\verb|c:\Temp\Report.doc|'' should be sent as -``\verb|/c:/Temp/Report.doc|''. - -\newpage -\subsection{FileUploadData} -\begin{verbatim} -Message type: 133 -Name signature: "FTC_UPDT" -Vendor signature: "TGHT" -\end{verbatim} - -The client uses \typestr{FileUploadData} message to send each -successive portion of file data, as a part of file upload procedure. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 133 & \typestr{message-type} \\ -1 & U8 & & \typestr{flags} \\ -2 & U16 & & \typestr{raw-length} \\ -2 & U16 & & \typestr{compressed-length} \\ -\typestr{compressed-length} & U8 array & & \typestr{file-data} \\ -\hline\end{tabular} - -The \typestr{flags} byte has the following format: - -\begin{tabular}{l|l|l} -\hline -Bits & Binary value & Description \\ \hline -3-0 & 0000 & file data is not compressed \\ - & 0001..1001 & compression level used (1..9) \\ - & 1010 or greater & invalid \\ -\hline -\end{tabular} - -Last message per file (both \typestr{raw-length} and -\typestr{compressed-length} are set to zeroes): - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 133 & \typestr{message-type} \\ -1 & & & \typestr{padding} \\ -2 & U16 & 0 & \typestr{raw-length} \\ -2 & U16 & 0 & \typestr{compressed-length} \\ -4 & U32 & & \typestr{modification-time} \\ -\hline\end{tabular} - -% do not use compression when not enabled by the server -% data is compressed with zlib -% format of the modification-time - -\newpage -\subsection{FileDownloadCancel} -\begin{verbatim} -Message type: 134 -Name signature: "FTC_DNCN" -Vendor signature: "TGHT" -\end{verbatim} - -The client sends \typestr{FileDownloadCancel} message to make the -server break current download operation. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 134 & \typestr{message-type} \\ -1 & & & \typestr{padding} \\ -2 & U16 & & \typestr{reason-length} \\ -\typestr{reason-length} & U8 array & & \typestr{reason-string} \\ -\hline\end{tabular} - -% reason-string may be empty - -\newpage -\subsection{FileUploadFailed} -\begin{verbatim} -Message type: 135 -Name signature: "FTC_UPFL" -Vendor signature: "TGHT" -\end{verbatim} - -The client sends \typestr{FileUploadFailed} message to notify the -server that current upload operation will not be completed. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 135 & \typestr{message-type} \\ -1 & & & \typestr{padding} \\ -2 & U16 & & \typestr{reason-length} \\ -\typestr{reason-length} & U8 array & & \typestr{reason-string} \\ -\hline\end{tabular} - -% reason-string may be empty - -\newpage -\subsection{FileCreateDirRequest} -\begin{verbatim} -Message type: 136 -Name signature: "FTC_FCDR" -Vendor signature: "TGHT" -\end{verbatim} - -\typestr{FileCreateDirRequest} message requests the server to create a -new directory. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 136 & \typestr{message-type} \\ -1 & & & \typestr{padding} \\ -2 & U16 & & \typestr{dirname-length} \\ -\typestr{dirname-length} & U8 array & & \typestr{dirname-string} \\ -\hline\end{tabular} - -The \typestr{dirname-string} should be an absolute path represented in -Unix-style format: it should start with a forward slash -(``\verb|/|''), path components should be separated also with forward -slashes. There should be no trailing slash at the end of the path. -Note that Windows-style path like -``\verb|c:\Temp\MyNewDir|'' should be sent as -``\verb|/c:/Temp/MyNewDir|''. - -% All components of the path except the last one should exist in the -% server's file system? - -\newpage -\subsection{FileDirSizeRequest} -\begin{verbatim} -Message type: 137 -Name signature: "FTC_DSRQ" -Vendor signature: "TGHT" -\end{verbatim} - -The client can send \typestr{FileDirSizeRequest} message to inquire -about the total size of all files within a particular directory on the -server (including files in sub-directories). - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 137 & \typestr{message-type} \\ -1 & & & \typestr{padding} \\ -2 & U16 & & \typestr{dirname-length} \\ -\typestr{dirname-length} & U8 array & & \typestr{dirname-string} \\ -\hline\end{tabular} - -The \typestr{dirname-string} should be an absolute path represented in -Unix-style format: it should start with a forward slash -(``\verb|/|''), path components should be separated also with forward -slashes. There should be no trailing slash at the end of the path, -except for the root (highest level) directory which is denoted with a -single slash. Note that Windows-style path like -``\verb|c:\Program Files\TightVNC|'' should be sent as -``\verb|/c:/Program Files/TightVNC|''. - -\newpage -\subsection{FileRenameRequest} -\begin{verbatim} -Message type: 138 -Name signature: "FTC_RNRQ" -Vendor signature: "TGHT" -\end{verbatim} - -\typestr{FileRenameRequest} message requests the server to rename the -specified file or directory. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 138 & \typestr{message-type} \\ -1 & & & \typestr{padding} \\ -2 & U16 & & \typestr{old-name-length} \\ -2 & U16 & & \typestr{new-name-length} \\ -\typestr{old-name-length} & U8 array & & \typestr{old-name-string} \\ -\typestr{new-name-length} & U8 array & & \typestr{new-name-string} \\ -\hline\end{tabular} - -Both \typestr{old-name-string} and \typestr{new-name-string} should be -file names with complete absolute paths and should be represented in -Unix-style format: the strings should start with forward slashes -(``\verb|/|''), path components should be separated also with forward -slashes. For example, Windows-style file name -``\verb|c:\Temp\Report.doc|'' should be sent as -``\verb|/c:/Temp/Report.doc|''. - -% All components of two paths except the last one should be the same? - -\newpage -\subsection{FileDeleteRequest} -\begin{verbatim} -Message type: 139 -Name signature: "FTC_RMRQ" -Vendor signature: "TGHT" -\end{verbatim} - -\typestr{FileDeleteRequest} message requests the server to delete the -specified file or directory. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 139 & \typestr{message-type} \\ -1 & & & \typestr{padding} \\ -2 & U16 & & \typestr{filename-length} \\ -\typestr{filename-length} & U8 array & & \typestr{filename-string} \\ -\hline\end{tabular} - -The \typestr{filename-string} should be a file name with complete -absolute path represented in Unix-style format: it should start with a -forward slash (``\verb|/|''), path components should be separated also -with forward slashes. For example, Windows-style file name -``\verb|c:\Temp\Report.doc|'' should be sent as -``\verb|/c:/Temp/Report.doc|''. - -\newpage -\section{Protocol messages, file transfers (server to client)} - -\subsection{FileListData} -\begin{verbatim} -Message type: 130 -Name signature: "FTS_LSDT" -Vendor signature: "TGHT" -\end{verbatim} - -The server sends \typestr{FileListData} message in response to -\typestr{FileListRequest} client message. \typestr{FileListData} -message lists files and sub-directories in a particular directory, and -includes information about file sizes and last modification times. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 130 & \typestr{message-type} \\ -1 & U8 & & \typestr{flags} \\ -2 & U16 & & \typestr{number-of-files} \\ -2 & U16 & & \typestr{raw-length} \\ -2 & U16 & & \typestr{compressed-length} \\ -8 $\times$ \typestr{number-of-files} & U32 array & & \typestr{file-properties-data} \\ -\typestr{compressed-length} & U8 array & & \typestr{file-names-data} \\ -\hline\end{tabular} - -The \typestr{flags} byte has the following format: - -\begin{tabular}{l|l|l} -\hline -Bits & Binary value & Description \\ \hline -3-0 & 0000 & file list data is not compressed \\ - & 0001..1001 & compression level used (1..9) \\ - & 1010 or greater & invalid \\ -\hline -4 & 0 & list of files and directories requested \\ - & 1 & list of directories only requested \\ -\hline -5 & 0 & success \\ - & 1 & non-existent or inaccessible directory requested \\ -\hline -\end{tabular} - -In the \typestr{flags} byte: - -\begin{itemize} -\item bit 4 duplicates the same bit from the corresponding - \typestr{FileListRequest} message; -\item if bit 5 is set to 1, then \typestr{number-of-files}, - \typestr{raw-length} and \typestr{compressed-length} all should be - set to zero values. In that case, \typestr{file-properties-data} and - \typestr{file-names-data} should be empty; -\item compression bits (bits 3-0) should be set only if compression - was requested by the client in the corresponding - \typestr{FileListRequest} message. -\end{itemize} - -\typestr{File-properties-data} array is sent as -\typestr{number-of-files} repetitions of the following structure: - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -4 & U32 & & \typestr{file-size} \\ -4 & U32 & & \typestr{modification-time} \\ -\hline\end{tabular} - -In that structure, \typestr{file-size} is specified in bytes, -\typestr{modification-time} is an offset is seconds since the Epoch -(00:00:00 UTC, January 1, 1970). - -\typestr{File-names-data} is a sequence of file and directory names -found in the requested directory. Names do not include paths. -Each individual record is terminated with a zero byte. The -\typestr{file-names-data} list should include -\typestr{number-of-files} individual records. If compression is -enabled (bits 3-0 of \typestr{flags} designate a valid compression -level), then \typestr{file-names-data} is compressed using zlib -library. - -% the number-of-files may be 0; in that case ... -% how directories should be ditinguished -% what about symbolic links etc. -% describe raw-length and compressed-length - -\newpage -\subsection{FileDownloadData} -\begin{verbatim} -Message type: 131 -Name signature: "FTS_DNDT" -Vendor signature: "TGHT" -\end{verbatim} - -The server uses \typestr{FileDownloadData} message to send each -successive portion of file data, as a part of file download procedure. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 131 & \typestr{message-type} \\ -1 & U8 & & \typestr{flags} \\ -2 & U16 & & \typestr{raw-length} \\ -2 & U16 & & \typestr{compressed-length} \\ -\typestr{compressed-length} & U8 array & & \typestr{file-data} \\ -\hline\end{tabular} - -Last message per file (both \typestr{raw-length} and -\typestr{compressed-length} are set to zeroes): - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 131 & \typestr{message-type} \\ -1 & & & \typestr{padding} \\ -2 & U16 & 0 & \typestr{raw-length} \\ -2 & U16 & 0 & \typestr{compressed-length} \\ -4 & U32 & & \typestr{modification-time} \\ -\hline\end{tabular} - -The \typestr{flags} byte has the following format: - -\begin{tabular}{l|l|l} -\hline -Bits & Binary value & Description \\ \hline -3-0 & 0000 & file data is not compressed \\ - & 0001..1001 & compression level used (1..9) \\ - & 1010 or greater & invalid \\ -\hline -\end{tabular} - -Compression should be used only if it was requested by the client in -corresponding \typestr{FileListRequest} message. - -% data is compressed with zlib -% format of the modification-time - -\newpage -\subsection{FileUploadCancel} -\begin{verbatim} -Message type: 132 -Name signature: "FTS_UPCN" -Vendor signature: "TGHT" -\end{verbatim} - -The server sends \typestr{FileUploadCancel} message to make the client -break current upload operation. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 132 & \typestr{message-type} \\ -1 & & & \typestr{padding} \\ -2 & U16 & & \typestr{reason-length} \\ -\typestr{reason-length} & U8 array & & \typestr{reason-string} \\ -\hline\end{tabular} - -% reason-string may be empty - -\newpage -\subsection{FileDownloadFailed} -\begin{verbatim} -Message type: 133 -Name signature: "FTS_DNFL" -Vendor signature: "TGHT" -\end{verbatim} - -The server sends \typestr{FileDownloadFailed} message to notify the -client that current download operation will not be completed. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 133 & \typestr{message-type} \\ -1 & & & \typestr{padding} \\ -2 & U16 & & \typestr{reason-length} \\ -\typestr{reason-length} & U8 array & & \typestr{reason-string} \\ -\hline\end{tabular} - -% reason-string may be empty - -\newpage -\subsection{FileDirSizeData} -\begin{verbatim} -Message type: 134 -Name signature: "FTS_DSDT" -Vendor signature: "TGHT" -\end{verbatim} - -The server sends \typestr{FileDirSizeData} message in response to -\typestr{FileDirSizeRequest} client message. \typestr{FileDirSizeData} -message returns total size of all files within the requested directory -on the server (including files in sub-directories). The size in bytes -is returned as an unsigned 48-bit value. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 134 & \typestr{message-type} \\ -1 & & & \typestr{padding} \\ -2 & U16 & & \typestr{dir-size-high-bits} \\ -4 & U32 & & \typestr{dir-size-low-bits} \\ -\hline\end{tabular} - -\newpage -\subsection{FileLastRequestFailed} -\begin{verbatim} -Message type: 135 -Name signature: "FTS_RQFL" -Vendor signature: "TGHT" -\end{verbatim} - -The server sends \typestr{FileLastRequestFailed} message if it cannot -execute an operation requested by the client. It can be sent in -response to the following client messages: -\typestr{FileDownloadRequest}, \typestr{FileCreateDirRequest}, -\typestr{FileRenameRequest}, \typestr{FileDeleteRequest}. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 135 & \typestr{message-type} \\ -1 & U8 & & \typestr{message-type-of-request} \\ -2 & U16 & & \typestr{reason-length} \\ -\typestr{reason-length} & U8 array & & \typestr{reason-string} \\ -\hline\end{tabular} - -% reason-string may be empty - -\newpage -\subsection{FileEnableCompression} -\begin{verbatim} -Message type: 137 -Name signature: "FTS_CMPR" -Vendor signature: "TGHT" -\end{verbatim} - -This message controls compression in file transfer operations. -\typestr{Enable-flag} is non-zero (true) if the client should be -allowed to request and use compression for file transfers, or zero -(false) otherwise. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 137 & \typestr{message-type} \\ -1 & U8 & & \typestr{enable-flag} \\ -\hline\end{tabular} - -\typestr{FileEnableCompression} message controls how clients send the -following messages: - -\begin{itemize} -\item \typestr{FileListRequest} -\item \typestr{FileDownloadRequest} -\item \typestr{FileUploadRequest} -\item \typestr{FileUploadData} -\end{itemize} - -If the client did not receive a \typestr{FileEnableCompression} -message from the server, or the most recent -\typestr{FileEnableCompression} message included \typestr{enable-flag} -set to false, then it must specify zero as compression level in the -messages listed above and, most importantly, may not compress file -data on uploading files. - -Otherwise, if the most recent \typestr{FileEnableCompression} message -included non-zero \typestr{enable-flag}, then the client is allowed to -request non-zero compression level and may send compressed data in -\typestr{FileUploadData} messages. - -This message should not have effect on file transfers that are already -in progress. - -\begin{quote} -Note: this message was introduced to preserve compatibility with -servers that do not support compression in file transfers. Old servers -expect uncompressed data in \typestr{FileUploadData} messages but new -clients might send it compressed. Using -\typestr{FileEnableCompression} message makes sure the client will -never compress upload data unless enabled explicitly by the server. -\end{quote} - -\newpage -\section{Protocol messages (client to server)} - -\subsection{EnableContinuousUpdates} -\begin{verbatim} -Message type: 150 -Name signature: "CUC_ENCU" -Vendor signature: "TGHT" -\end{verbatim} - -This message either enables continuous updates for the specified -pixels, or disables continuous updates completely. - -If \typestr{enable-flag} is set to true (non-zero), continuous updates -are enabled for the framebuffer area specified by -\typestr{x-position}, \typestr{y-position}, \typestr{width} and -\typestr{height}. - -If \typestr{enable-flag} is set to false (zero), continuous updates -are to be completely disabled. In this case, the values of -\typestr{x-position}, \typestr{y-position}, \typestr{width} and -\typestr{height} are not used. - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 150 & \typestr{message-type} \\ -1 & U8 & & \typestr{enable-flag} \\ -2 & U16 & & \typestr{x-position} \\ -2 & U16 & & \typestr{y-position} \\ -2 & U16 & & \typestr{width} \\ -2 & U16 & & \typestr{height} \\ -\hline\end{tabular} - -Normally, the server would send \typestr{FramebufferUpdate} messages -only in response to corresponding \typestr{FramebufferUpdateRequest} -messages received from the client. In contrast, when continuous -updates are in effect, the server is allowed to send a -\typestr{FramebufferUpdate} message at any time, not waiting for -client requests. - -Initially, contunuous updates are disabled since they violate the -original RFB protocol. To enable this mode, the client sends an -\typestr{EnableContinuousUpdates} message with non-zero -\typestr{enable-flag}. On receiving such a message, the server -immediately enables continuous updates for the area specified by -\typestr{x-position}, \typestr{y-position}, \typestr{width} and -\typestr{height}. The server will not send updates for pixels outside -of this area. - -If continuous updates are already in effect, the client may always -change the coordinates of currently updated area by sending another -\typestr{EnableContinuousUpdates} message with non-zero -\typestr{enable-flag}. On receiving each next message, the server -discards old coordinates and re-enables continuous updates for the -newly specified area. - -If \typestr{enable-flag} is set to zero, the server should disable -continuous updates completely and respond with an -\typestr{EndOfContinuousUpdates} message. After the client has -received an \typestr{EndOfContinuousUpdates}, it can be sure that -there will be no more updates without prior update requests. - -The client may send a message with zero \typestr{enable-flag} even if -continuous updates were disabled already. In response, the server -should send an \typestr{EndOfContinuousUpdates} each time it is asked -to disable continuous updates. This behavior may be useful for -protocol synchronization purposes. - -While continuous updates are in effect, the server completely ignores -incremental update requests (\typestr{FramebufferUpdateRequest} with -\typestr{incremental} flag set to non-zero). Such requests are ignored -regardless of the coordinates specified within the request. Thus, it's -not possible to request an incremental update for pixels outside of -current continuously updated area. - -Non-incremental update requests (\typestr{FramebufferUpdateRequest} -with \typestr{incremental} flag set to zero) should work as usual. -That is, in response to such requests, the server should send the -entire contents of the specified area as soon as possible. - -FIXME: Respect incremental update requests? - -FIXME: Decide how to handle framebuffer size changes. - -FIXME: Decide how to change pixel format while continuously updating. - -See also: -\begin{itemize} -\item \typestr{EndOfContinuousUpdates} server-to-client message. -\end{itemize} - -\newpage -\section{Protocol messages (server to client)} - -\subsection{EndOfContinuousUpdates} -\begin{verbatim} -Message type: 150 -Name signature: "CUS_EOCU" -Vendor signature: "TGHT" -\end{verbatim} - -The server sends \typestr{EndOfContinuousUpdates} message in response -to each \typestr{EnableContinuousUpdates} message if and only if its -\typestr{enable-flag} was set to false (zero). - -\begin{tabular}{l|lc|l} \hline -No.\ of bytes & Type & [Value] & Description \\ \hline -1 & U8 & 150 & \typestr{message-type} \\ -\hline\end{tabular} - -The message informs the client that it should not expect unsolicited -framebuffer updates any more. In other words, after this message, -there will be no framebuffer updates with no corresponding update -requests received from the client. - -Note that this message should be sent each time the client is asking -to disable continuous updates, even if continuous updates were not -previously enabled. - -FIXME: Allow unsolicited EndOfContinuousUpdates messages? - -See also: -\begin{itemize} -\item \typestr{EnableContinuousUpdates} client-to-server message. -\end{itemize} - -\end{document} -- 2.39.5