Originally developed in the TightVNC project and currently tied into their extension handshake mechanism. Should be possible to extend and use more generally though.
Signed-off-by: Pierre Ossman <oss...@cendio.se> --- Index: rfbproto.rst =================================================================== --- rfbproto.rst (revision 4741) +++ rfbproto.rst (working copy) @@ -828,8 +828,11 @@ 252 tight 251 `SetDesktopSize`_ 250 `xvp Client Message`_ +150 [#]_ `EnableContinuousUpdates`_ =========== =========================================================== +.. [#] **Warning:** Not officially allocated + Note that before sending a message with an optional message type a client must have determined that the server supports the relevant extension by receiving some extension-specific confirmation from the @@ -1621,7 +1624,46 @@ The *nchannels* field must be either ``1`` (mono) or ``2`` (stereo). +EnableContinuousUpdates +----------------------- +This message informs the server to switch between only sending +`FramebufferUpdate`_ messages as a result of a +`FramebufferUpdateRequest`_ message, or sending ``FramebufferUpdate`` +messages continuously. + +Note that there is currently no way to determine if the server supports +this message except for using the `Tight Security Type`_ authentication. + +=============== ==================== ========== ======================= +No. of bytes Type [Value] Description +=============== ==================== ========== ======================= +1 ``U8`` 150 *message-type* +1 ``U8`` *enable-flag* +2 ``U16`` *x-position* +2 ``U16`` *y-position* +2 ``U16`` *width* +2 ``U16`` *height* +=============== ==================== ========== ======================= + +If *enable-flag* is non-zero, then the server can start sending +``FramebufferUpdate`` messages as needed for the area specified by +*x-position*, *y-position*, *width*, and *height*. If continuous +updates are already active, then they must remain active active and the +coordinates must be replaced with the last message seen. + +If *enable-flag* is zero, then the server must only send +``FramebufferUpdate`` messages as a result of receiving +``FramebufferUpdateRequest`` messages. The server must also immediately +send out a `EndOfContinuousUpdates`_ message. This message must be sent +out even if continuous updates were already disabled. + +The server must ignore all incremental update requests +(``FramebufferUpdateRequest`` with *incremental* set to non-zero) as +long as continuous updates are active. Non-incremental updates must +however be honored, even if the area in such a request does not overlap +the area specified for continuous updates. + Server to Client Messages +++++++++++++++++++++++++ @@ -1646,8 +1688,11 @@ 253 `gii Server Message`_ 252 tight 250 `xvp Server Message`_ +150 [#]_ `EndOfContinuousUpdates`_ =========== =========================================================== +.. [#] **Warning:** Not officially allocated + Note that before sending a message with an optional message type a server must have determined that the client supports the relevant extension by receiving some extension-specific confirmation from the @@ -1908,6 +1953,21 @@ The *data-length* will be a multiple of (*sample-format* * *nchannels*) as requested by the client in an earlier `QEMU Audio Client Message`_. +EndOfContinuousUpdates +---------------------- + +This message is sent whenever the server sees a +`EnableContinuousUpdates`_ message with *enable* set to a non-zero +value. It indicates that the server has stopped sending continuous +updates and is now only reacting to `FramebufferUpdateRequest`_ +messages. + +=============== ==================== ========== ======================= +No. of bytes Type [Value] Description +=============== ==================== ========== ======================= +1 ``U8`` 150 *message-type* +=============== ==================== ========== ======================= + Encodings +++++++++ -- Pierre Ossman OpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio AB Web: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing?
signature.asc
Description: PGP signature
------------------------------------------------------------------------------ The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev
_______________________________________________ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
