TigerVNC

Revision: 3792
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3792&view=rev
Author:   ossman_
Date:     2009-04-28 08:28:07 +0000 (Tue, 28 Apr 2009)

Log Message:
-----------
Fix line that exceeded 72 characters.

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-04-28 08:22:23 UTC (rev 3791)
+++ rfbproto/rfbproto.rst	2009-04-28 08:28:07 UTC (rev 3792)
@@ -1221,8 +1221,8 @@
     where *m* is the number of bytes representing the packed pixels.
     For *paletteSize* of 2 this is floor((*width* + 7) / 8) * *height*,
     for *paletteSize* of 3 or 4 this is
-    floor((*width* + 3) / 4) * *height*, for *paletteSize* of 5 to 16 this
-    is floor((*width* + 1) / 2) * *height*.
+    floor((*width* + 3) / 4) * *height*, for *paletteSize* of 5 to 16
+    this is floor((*width* + 1) / 2) * *height*.
 
 17 to 127
     Unused (no advantage over palette RLE).


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3796
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3796&view=rev
Author:   ossman_
Date:     2009-04-30 12:10:18 +0000 (Thu, 30 Apr 2009)

Log Message:
-----------
Prepare document for extensions

The original document is closely tied to RealVNC's implementation in
many aspects. Try to make the important bits more general and clear.

Signed-off-by: Pierre Ossman <ossman@...>  
Signed-off-by: Daniel P Berrange <dan@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-04-30 11:41:03 UTC (rev 3795)
+++ rfbproto/rfbproto.rst	2009-04-30 12:10:18 UTC (rev 3796)
@@ -106,12 +106,6 @@
 the pixel data. The data itself then follows using the specified
 encoding.
 
-The encoding types defined at present are *Raw*, *CopyRect*, *RRE*,
-*Hextile* and *ZRLE*. In practice we normally use only the *ZRLE*,
-*Hextile* and *CopyRect* encodings since they provide the best
-compression for typical desktops. See `Encodings`_ for a description of
-each of the encodings.
-
 Protocol Extensions
 ===================
 
@@ -143,16 +137,15 @@
     to be anything like the RFB protocol.
 
 **Under no circumstances should you use a different protocol version
-number**. Protocol versions are defined by the maintainers of the RFB
-protocol, RealVNC Ltd. If you use a different protocol version number
-then you are not RFB / VNC compatible. To ensure that you stay
-compatible with the RFB protocol it is important that you contact
-RealVNC Ltd to make sure that your encoding types and security types do
-not clash. Please see the RealVNC website at http://www.realvnc.com for
-details of how to contact us; sending a message to the VNC mailing list
-is the best way to get in touch and let the rest of the VNC community
-know.
+number**. If you use a different protocol version number then you are
+not RFB / VNC compatible.
 
+All three mechanisms for extensions are handled by RealVNC Ltd. To
+ensure that you stay compatible with the RFB protocol it is important
+that you contact RealVNC Ltd to make sure that your encoding types and
+security types do not clash. Please see the RealVNC website at
+http://www.realvnc.com for details of how to contact them.
+
 Protocol Messages
 =================
 
@@ -482,7 +475,7 @@
 Client to Server Messages
 +++++++++++++++++++++++++
 
-The client to server message types defined in this document are:
+The client to server message types that all servers must support are:
 
 =========== ===========================================================
 Number      Name
@@ -495,7 +488,7 @@
 6           ClientCutText
 =========== ===========================================================
 
-Other registered message types are:
+Optional message types are:
 
 =========== ===========================================================
 Number      Name
@@ -508,7 +501,7 @@
 250         Colin Dean xvp
 =========== ===========================================================
 
-Note that before sending a message not defined in this document a
+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
 server.
@@ -780,7 +773,7 @@
 Server to Client Messages
 +++++++++++++++++++++++++
 
-The server to client message types defined in this document are:
+The server to client message types that all clients must support are:
 
 =========== ===========================================================
 Number      Name
@@ -791,7 +784,7 @@
 3           ServerCutText
 =========== ===========================================================
 
-Other registered message types are:
+Optional message types are:
 
 =========== ===========================================================
 Number      Name
@@ -803,7 +796,7 @@
 250         Colin Dean xvp
 =========== ===========================================================
 
-Note that before sending a message not defined in this document a
+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
 client; usually a request for a given pseudo-encoding.


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3799
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3799&view=rev
Author:   ossman_
Date:     2009-05-05 07:05:48 +0000 (Tue, 05 May 2009)

Log Message:
-----------
Add gii extension (messages and pseudo-encoding)

Document the General Input Interface (gii) extension.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-05-04 08:58:43 UTC (rev 3798)
+++ rfbproto/rfbproto.rst	2009-05-05 07:05:48 UTC (rev 3799)
@@ -80,6 +80,11 @@
 example, a pen-based handwriting recognition engine might generate
 keyboard events.
 
+If you have an input source that does not fit this standard workstation
+model, the Generial Input Interface (gii) protocol extension provides
+possibilities for input sources with more axes, relative movement and
+more buttons.
+
 Representation of Pixel Data
 ============================
 
@@ -166,6 +171,11 @@
 signed integers. All multiple byte integers (other than pixel values
 themselves) are in big endian order (most significant byte first).
 
+However, some protocol extensions use protocol messages that have types
+that may be in little endian order. These endian agnostic types are
+``EU16``, ``EU32``, ``ES16``, ``ES32``, with some extension specific
+indicator of the endianess.
+
 The type ``PIXEL`` is taken to mean a pixel value of *bytesPerPixel*
 bytes, where 8 * *bytesPerPixel* is the number of *bits-per-pixel* as
 agreed by the client and server, either in the *ServerInit* message
@@ -495,7 +505,7 @@
 =========== ===========================================================
 255         Anthony Liguori
 254, 127    VMWare
-253         gii
+253         gii (General Input Interface)
 252         tight
 251         Pierre Ossman SetDesktopSize
 250         Colin Dean xvp
@@ -770,6 +780,268 @@
 *length*        ``U8`` array                    *text*
 =============== ==================== ========== =======================
 
+gii (General Input Interface)
+-----------------------------
+
+Version
+~~~~~~~
+
+The client response to a *gii* Version message from the server is the
+following response:
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               253        *message-type*
+1               ``U8``               1 or 129   *endian-and-sub-type*
+2               ``EU16``             4          *length*
+2               ``EU16``             1          *version*
+=============== ==================== ========== =======================
+
+*endian-and-sub-type* is a bit-field with the leftmost bit indicating
+big endian if set, and little endian if cleared. The rest of the bits
+are the actual message sub type.
+
+*version* is set by the client and ultimately decides the version of
+*gii* protocol extension to use. It should be in the range given by the
+server in the *gii* Version message. If the server doesn't support any
+version that the client supports, the client should instead stop using
+the *gii* extension at this point.
+
+Device Creation
+~~~~~~~~~~~~~~~
+
+After establishing the *gii* protocol extension version, the client
+proceeds by requesting creation of one or more devices.
+
+===================== =============== ========== ======================
+No. of bytes          Type            [Value]    Description
+===================== =============== ========== ======================
+1                     ``U8``          253        *message-type*
+1                     ``U8``          2 or 130   *endian-and-sub-type*
+2                     ``EU16``        2          *length*
+31                    ``U8`` array               *device-name*
+1                     ``U8``          0          *nul-terminator*
+4                     ``EU32``                   *vendor-id*
+4                     ``EU32``                   *product-id*
+4                     ``EVENT_MASK``             *can-generate*
+4                     ``EU32``                   *num-registers*
+4                     ``EU32``                   *num-valuators*
+4                     ``EU32``                   *num-buttons*
+*num-valuators* * 116 ``VALUATOR``
+===================== =============== ========== ======================
+
+*endian-and-sub-type* is a bit-field with the leftmost bit indicating
+big endian if set, and little endian if cleared. The rest of the bits
+are the actual message sub type.
+
+``EVENT_MASK`` is a bit-field indicating which events the device
+can generate.
+
+============= =========================================================
+Value         Bit name
+============= =========================================================
+0x00000020    Key press
+0x00000040    Key release
+0x00000080    Key repeat
+0x00000100    Pointer relative
+0x00000200    Pointer absolute
+0x00000400    Pointer button press
+0x00000800    Pointer button release
+0x00001000    Valuator relative
+0x00002000    Valuator absolute
+============= =========================================================
+
+and ``VALUATOR`` is
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+4               ``EU32``                        *index*
+74              ``U8`` array                    *long-name*
+1               ``U8``               0          *nul-terminator*
+4               ``U8`` array                    *short-name*
+1               ``U8``               0          *nul-terminator*
+4               ``ES32``                        *range-min*
+4               ``ES32``                        *range-center*
+4               ``ES32``                        *range-max*
+4               ``EU32``                        *SI-unit*
+4               ``ES32``                        *SI-add*
+4               ``ES32``                        *SI-mul*
+4               ``ES32``                        *SI-div*
+4               ``ES32``                        *SI-shift*
+=============== ==================== ========== =======================
+
+The *SI-unit* field is defined as:
+
+========= ==================== ========================================
+Number    SI-unit              Description
+========= ==================== ========================================
+0                              unknown
+1         s                    time
+2         1/s                  frequency
+3         m                    length
+4         m/s                  velocity
+5         m/s^2                acceleration
+6         rad                  angle
+7         rad/s                angular velocity
+8         rad/s^2              angular acceleration
+9         m^2                  area
+10        m^3                  volume
+11        kg                   mass
+12        N (kg*m/s^2)         force
+13        N/m^2 (Pa)           pressure
+14        Nm                   torque
+15        Nm, VAs, J           energy
+16        Nm/s, VA, W          power
+17        K                    temperature
+18        A                    current
+19        V (kg*m^2/(As^3))    voltage
+20        V/A (Ohm)            resistance
+21        As/V                 capacity
+22        Vs/A                 inductivity
+========= ==================== ========================================
+
+The *SI-add*, *SI-mul*, *SI-div* and *SI-shift* fields of the
+``VALUATOR`` indicate how the raw value should be translated to the
+SI-unit using the below formula.
+
+        float SI = (float) (SI_add + value[n]) * (float) SI_mul
+        / (float) SI_div * pow(2.0, SI_shift);
+
+Setting *SI-mul* to zero indicates that the valuator is non-linear or
+that the factor is unknown.
+
+Device Destruction
+~~~~~~~~~~~~~~~~~~
+
+The client can destroy a device with a device destruct message.
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               253        *message-type*
+1               ``U8``               3 or 131   *endian-and-sub-type*
+2               ``EU16``             4          *length*
+4               ``EU32``                        *device-origin*
+=============== ==================== ========== =======================
+
+*endian-and-sub-type* is a bit-field with the leftmost bit indicating
+big endian if set, and little endian if cleared. The rest of the bits
+are the actual message sub type.
+
+*device-origin* is the handle retrieved with a prior device creation
+request.
+
+Injecting Events
+~~~~~~~~~~~~~~~~
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               253        *message-type*
+1               ``U8``               0 or 128   *endian-and-sub-type*
+2               ``EU16``                        *length*
+=============== ==================== ========== =======================
+
+followed by *length* bytes of ``EVENT`` entries
+
+*endian-and-sub-type* is a bit-field with the leftmost bit indicating
+big endian if set, and little endian if cleared. The rest of the bits
+are the actual message sub type.
+
+``EVENT`` is one of ``KEY_EVENT``, ``PTR_MOVE_EVENT``,
+``PTR_BUTTON_EVENT`` and ``VALUATOR_EVENT``.
+
+``KEY_EVENT`` is:
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               24         *event-size*
+1               ``U8``               5, 6 or 7  *event-type*
+2               ``EU16``                        *padding*
+4               ``EU32``                        *device-origin*
+4               ``EU32``                        *modifiers*
+4               ``EU32``                        *symbol*
+4               ``EU32``                        *label*
+4               ``EU32``                        *button*
+=============== ==================== ========== =======================
+
+The possible values for *event-type* are: 5 - key pressed, 6 - key
+released and 7 - key repeat. XXX describe *modifiers*, *symbol*,
+*label* and *button*. Meanwhile, see
+http://www.ggi-project.org/documentation/libgii/current/gii_key_event.3.html
+for details.
+
+*device-origin* is the handle retrieved with a prior device creation
+request.
+
+``PTR_MOVE_EVENT`` is:
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               24         *event-size*
+1               ``U8``               8 or 9     *event-type*
+2               ``EU16``                        *padding*
+4               ``EU32``                        *device-origin*
+4               ``ES32``                        *x*
+4               ``ES32``                        *y*
+4               ``ES32``                        *z*
+4               ``ES32``                        *wheel*
+=============== ==================== ========== =======================
+
+The possible values for *event-type* are: 8 - pointer relative and
+9 - pointer absolute.
+
+*device-origin* is the handle retrieved with a prior device creation
+request.
+
+``PTR_BUTTON_EVENT`` is:
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               12         *event-size*
+1               ``U8``               10 or 11   *event-type*
+2               ``EU16``                        *padding*
+4               ``EU32``                        *device-origin*
+4               ``EU32``                        *button-number*
+=============== ==================== ========== =======================
+
+The possible values for *event-type* are: 10 - pointer button press and
+11 - pointer button release.
+
+*device-origin* is the handle retrieved with a prior device creation
+request.
+
+*button-number* 1 is the primary or left button, *button-number* 2 is
+the secondary or right button and *button-number* 3 is the tertiary or
+middle button. Other values for *button-number* are also valid.
+
+``VALUATOR_EVENT`` is:
+
+=============== ================= ================== ==================
+No. of bytes    Type              [Value]            Description
+=============== ================= ================== ==================
+1               ``U8``            16 + 4 * *count*   *event-size*
+1               ``U8``            12 or 13           *event-type*
+2               ``EU16``                             *padding*
+4               ``EU32``                             *device-origin*
+4               ``EU32``                             *first*
+4               ``EU32``                             *count*
+4 * *count*     ``ES32`` array                       *value*
+=============== ================= ================== ==================
+
+The possible values for *event-type* are: 12 - relative valuator and
+13 - absolute valuator.
+
+*device-origin* is the handle retrieved with a prior device creation
+request.
+
+The event reports *count* valuators starting with *first*.
+
 Server to Client Messages
 +++++++++++++++++++++++++
 
@@ -791,7 +1063,7 @@
 =========== ===========================================================
 255         Anthony Liguori
 254, 127    VMWare
-253         gii
+253         gii (General Input Interface)
 252         tight
 250         Colin Dean xvp
 =========== ===========================================================
@@ -889,6 +1161,52 @@
 *length*        ``U8`` array                    *text*
 =============== ==================== ========== =======================
 
+gii (General Input Interface)
+-----------------------------
+
+Version
+~~~~~~~
+
+The server response from a with server *gii* capabilities to a client
+declaring *gii* capabilities is a *gii* version message:
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               253        *message-type*
+1               ``SUB_TYPE``         1 or 129   *endian-and-sub-type*
+2               ``EU16``             4          *length*
+2               ``EU16``             1          *maximum-version*
+2               ``EU16``             1          *minimum-version*
+=============== ==================== ========== =======================
+
+*endian-and-sub-type* is a bit-field with the leftmost bit indicating
+big endian if set, and little endian if cleared. The rest of the bits
+are the actual message sub type.
+
+Device Creation Response
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The server response to a *gii* Device Creation request from the client
+is the following response:
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               253        *message-type*
+1               ``SUB_TYPE``         2 or 130   *endian-and-sub-type*
+2               ``EU16``             4          *length*
+4               ``EU32``                        *device-origin*
+=============== ==================== ========== =======================
+
+*endian-and-sub-type* is a bit-field with the leftmost bit indicating
+big endian if set, and little endian if cleared. The rest of the bits
+are the actual message sub type.
+
+*device-origin* is used as a handle to the device in subsequent
+communications. A *device-origin* of zero indicates device creation
+failure.
+
 Encodings
 +++++++++
 
@@ -904,6 +1222,7 @@
 16          ZRLE
 -239        Cursor pseudo-encoding
 -223        DesktopSize pseudo-encoding
+-305        gii (General Input Interface)
 =========== ===========================================================
 
 Other registered encodings are:
@@ -922,7 +1241,6 @@
 -240 to -256                tight options
 -257 to -272                Anthony Liguori
 -273 to -304                VMWare
--305                        gii
 -306                        popa
 -307                        Peter Astrand DesktopName
 -308                        Pierre Ossman ExtendedDesktopSize
@@ -1317,3 +1635,18 @@
 width and height of the framebuffer. There is no further data
 associated with the pseudo-rectangle.
 
+gii (General Input Interface) Pseudo-encoding
+---------------------------------------------
+
+A client which requests the *gii* pseudo-encoding is declaring that it
+is capable of accepting the *gii* server-to-client message. The server
+declares that it is capable of accepting the *gii* client-to-server
+messages by sending a *gii* server-to-client message of subtype
+*version*.
+
+Requesting the *gii* pseudo-encoding is the first step when a client
+wants to use the *gii* extension of the RFB protocol. The *gii*
+extension is used to provide a more powerful input protocol for cases
+where the standard input model is insufficient. It supports relative
+mouse movements, mouses with more than 8 buttons and mouses with more
+than three axes. It even supports joysticks and gamepads.


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3801
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3801&view=rev
Author:   ossman_
Date:     2009-05-07 07:57:37 +0000 (Thu, 07 May 2009)

Log Message:
-----------
Add links from message and encoding lists

Make it easier to navigate in hypertext versions of the document.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-05-07 07:55:33 UTC (rev 3800)
+++ rfbproto/rfbproto.rst	2009-05-07 07:57:37 UTC (rev 3801)
@@ -292,8 +292,8 @@
 Number      Name
 =========== ===========================================================
 0           Invalid
-1           None
-2           VNC Authentication
+1           `None`_
+2           `VNC Authentication`_
 =========== ===========================================================
 
 Other registered security types are:
@@ -490,12 +490,12 @@
 =========== ===========================================================
 Number      Name
 =========== ===========================================================
-0           SetPixelFormat
-2           SetEncodings
-3           FramebufferUpdateRequest
-4           KeyEvent
-5           PointerEvent
-6           ClientCutText
+0           `SetPixelFormat`_
+2           `SetEncodings`_
+3           `FramebufferUpdateRequest`_
+4           `KeyEvent`_
+5           `PointerEvent`_
+6           `ClientCutText`_
 =========== ===========================================================
 
 Optional message types are:
@@ -505,7 +505,7 @@
 =========== ===========================================================
 255         Anthony Liguori
 254, 127    VMWare
-253         gii (General Input Interface)
+253         `gii (General Input Interface) Client Message`_
 252         tight
 251         Pierre Ossman SetDesktopSize
 250         Colin Dean xvp
@@ -780,8 +780,8 @@
 *length*        ``U8`` array                    *text*
 =============== ==================== ========== =======================
 
-gii (General Input Interface)
------------------------------
+gii (General Input Interface) Client Message
+--------------------------------------------
 
 Version
 ~~~~~~~
@@ -1050,10 +1050,10 @@
 =========== ===========================================================
 Number      Name
 =========== ===========================================================
-0           FramebufferUpdate
-1           SetColourMapEntries
-2           Bell
-3           ServerCutText
+0           `FramebufferUpdate`_
+1           `SetColourMapEntries`_
+2           `Bell`_
+3           `ServerCutText`_
 =========== ===========================================================
 
 Optional message types are:
@@ -1063,7 +1063,7 @@
 =========== ===========================================================
 255         Anthony Liguori
 254, 127    VMWare
-253         gii (General Input Interface)
+253         `gii (General Input Interface) Server Message`_
 252         tight
 250         Colin Dean xvp
 =========== ===========================================================
@@ -1161,8 +1161,8 @@
 *length*        ``U8`` array                    *text*
 =============== ==================== ========== =======================
 
-gii (General Input Interface)
------------------------------
+gii (General Input Interface) Server Message
+--------------------------------------------
 
 Version
 ~~~~~~~
@@ -1215,14 +1215,14 @@
 =========== ===========================================================
 Number      Name
 =========== ===========================================================
-0           Raw
-1           CopyRect
-2           RRE
-5           Hextile
-16          ZRLE
--239        Cursor pseudo-encoding
--223        DesktopSize pseudo-encoding
--305        gii (General Input Interface)
+0           `Raw Encoding`_
+1           `CopyRect Encoding`_
+2           `RRE Encoding`_
+5           `Hextile Encoding`_
+16          `ZRLE Encoding`_
+-239        `Cursor Pseudo-encoding`_
+-223        `DesktopSize Pseudo-encoding`_
+-305        `gii (General Input Interface) Pseudo-encoding`_
 =========== ===========================================================
 
 Other registered encodings are:


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3802
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3802&view=rev
Author:   ossman_
Date:     2009-05-07 08:02:03 +0000 (Thu, 07 May 2009)

Log Message:
-----------
Add SASL security type

It is official according to:
http://realvnc.com/pipermail/vnc-list/2008-December/059463.html

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-05-07 07:57:37 UTC (rev 3801)
+++ rfbproto/rfbproto.rst	2009-05-07 08:02:03 UTC (rev 3802)
@@ -307,6 +307,7 @@
 17          Ultra
 18          TLS
 19          VeNCrypt
+20          SASL
 =========== ===========================================================
 
 Once the *security-type* has been decided, data specific to that


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3806
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3806&view=rev
Author:   ossman_
Date:     2009-05-11 09:40:30 +0000 (Mon, 11 May 2009)

Log Message:
-----------
Describe the CoRRE encoding

Describe the CoRRE encoding in terms of the RRE encoding.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-05-11 09:26:56 UTC (rev 3805)
+++ rfbproto/rfbproto.rst	2009-05-11 09:40:30 UTC (rev 3806)
@@ -1219,6 +1219,7 @@
 0           `Raw Encoding`_
 1           `CopyRect Encoding`_
 2           `RRE Encoding`_
+4           `CoRRE Encoding`_
 5           `Hextile Encoding`_
 16          `ZRLE Encoding`_
 -239        `Cursor Pseudo-encoding`_
@@ -1231,7 +1232,6 @@
 =========================== ===========================================
 Number                      Name
 =========================== ===========================================
-4                           CoRRE
 6                           zlib
 7                           tight
 8                           zlibhex
@@ -1337,6 +1337,41 @@
 2               ``U16``             *height*
 =============== =================== ===================================
 
+CoRRE Encoding
+--------------
+
+CoRRE stands for *compressed rise-and-run-length encoding* and as its
+name implies, it is a variant of the above `RRE Encoding`_ and as such
+essentially a two-dimensional analogue of run-length encoding.
+
+The only difference between CoRRE and RRE is that the position, width
+and height of the subrectangles are limited to a maximum of 255 pixels.
+Because of this, the server needs to produce several rectangles in
+order to cover a larger area. The `Hextile Encoding`_ is probably a
+better choice in the majority of cases.
+
+On the wire, the data begins with the header:
+
+=============== =================== ===================================
+No. of bytes    Type                Description
+=============== =================== ===================================
+4               ``U32``             *number-of-subrectangles*
+*bytesPerPixel* ``PIXEL``           *background-pixel-value*
+=============== =================== ===================================
+
+This is followed by *number-of-subrectangles* instances of the
+following structure:
+
+=============== =================== ===================================
+No. of bytes    Type                Description
+=============== =================== ===================================
+*bytesPerPixel* ``PIXEL``           *subrect-pixel-value*
+1               ``U8``              *x-position*
+1               ``U8``              *y-position*
+1               ``U8``              *width*
+1               ``U8``              *height*
+=============== =================== ===================================
+
 Hextile Encoding
 ----------------
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3807
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3807&view=rev
Author:   ossman_
Date:     2009-05-11 09:47:53 +0000 (Mon, 11 May 2009)

Log Message:
-----------
Describe the zlib encoding

Describe the zlib encoding in terms of the Raw encoding.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-05-11 09:40:30 UTC (rev 3806)
+++ rfbproto/rfbproto.rst	2009-05-11 09:47:53 UTC (rev 3807)
@@ -1221,6 +1221,7 @@
 2           `RRE Encoding`_
 4           `CoRRE Encoding`_
 5           `Hextile Encoding`_
+6           `zlib Encoding`_
 16          `ZRLE Encoding`_
 -239        `Cursor Pseudo-encoding`_
 -223        `DesktopSize Pseudo-encoding`_
@@ -1232,7 +1233,6 @@
 =========================== ===========================================
 Number                      Name
 =========================== ===========================================
-6                           zlib
 7                           tight
 8                           zlibhex
 15                          TRLE
@@ -1484,6 +1484,26 @@
 bits of *width-and-height* specify the width minus one, the
 least-significant specify the height minus one.
 
+zlib Encoding
+-------------
+
+The zlib encoding uses zlib [#]_ to compress rectangles encoded
+according to the `Raw Encoding`_. A single zlib "stream" object is used
+for a given RFB connection, so that zlib rectangles must be encoded and
+decoded strictly in order.
+
+.. [#] see http://www.gzip.org/zlib/
+
+=============== =================== ===================================
+No. of bytes    Type                Description
+=============== =================== ===================================
+4               ``U32``             *length*
+*length*        ``U8`` array        *zlibData*
+=============== =================== ===================================
+
+The *zlibData*, when uncompressed, represents a rectangle according to
+the `Raw Encoding`_.
+
 ZRLE Encoding
 -------------
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3808
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3808&view=rev
Author:   ossman_
Date:     2009-05-11 09:52:14 +0000 (Mon, 11 May 2009)

Log Message:
-----------
Add quirk about the CPIXEL type

I once did a survey of this involving several of the major implementations,
but can't really remember if I checked both little and big endian servers.
I for sure did check with both little and big endian on the wire though.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-05-11 09:47:53 UTC (rev 3807)
+++ rfbproto/rfbproto.rst	2009-05-11 09:52:14 UTC (rev 3808)
@@ -1539,6 +1539,13 @@
 and contains the least significant or the most significant 3 bytes as
 appropriate. *bytesPerCPixel* is the number of bytes in a ``CPIXEL``.
 
+Note that for the corner case where *bits-per-pixel* is 32 and *depth*
+is 16 or less (this is a corner case, since the client is **much**
+better off using 16 or even 8 *bits-per-pixels*) a ``CPIXEL`` is still
+3 bytes long. By convention, the three least significant bytes are used
+when both the three least and the three most significant bytes would
+cover the used bits.
+
 Each tile begins with a *subencoding* type byte. The top bit of this
 byte is set if the tile has been run-length encoded, clear otherwise.
 The bottom seven bits indicate the size of the palette used: zero means


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3809
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3809&view=rev
Author:   ossman_
Date:     2009-05-11 09:56:12 +0000 (Mon, 11 May 2009)

Log Message:
-----------
Describe the zlibhex encoding

Describe the zlibhex encoding in terms of the hextile encoding.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-05-11 09:52:14 UTC (rev 3808)
+++ rfbproto/rfbproto.rst	2009-05-11 09:56:12 UTC (rev 3809)
@@ -1222,6 +1222,7 @@
 4           `CoRRE Encoding`_
 5           `Hextile Encoding`_
 6           `zlib Encoding`_
+8           `zlibhex Encoding`_
 16          `ZRLE Encoding`_
 -239        `Cursor Pseudo-encoding`_
 -223        `DesktopSize Pseudo-encoding`_
@@ -1234,7 +1235,6 @@
 Number                      Name
 =========================== ===========================================
 7                           tight
-8                           zlibhex
 15                          TRLE
 17                          Hitachi ZYWRLE
 -1 to -222
@@ -1504,6 +1504,52 @@
 The *zlibData*, when uncompressed, represents a rectangle according to
 the `Raw Encoding`_.
 
+zlibhex Encoding
+----------------
+
+The zlibhex encoding uses zlib [#]_ to optionally compress
+subrectangles according to the `Hextile Encoding`_. Refer to the
+hextile encoding for information on how the rectangle is divided into
+subrectangles and other basic properties of subrectangles. One zlib
+"stream" object is used for subrectangles encoded according to the
+**Raw** subencoding and one zlib "stream" object is used for all other
+subrectangles.
+
+.. [#] see http://www.gzip.org/zlib/
+
+The hextile subencoding bitfield is extended with these bits:
+
+=============== ======= =========== ===================================
+No. of bytes    Type    [Value]     Description
+=============== ======= =========== ===================================
+1               ``U8``              *subencoding-mask*:
+..                      32          **ZlibRaw**
+..                      64          **Zlib**
+=============== ======= =========== ===================================
+
+If either of the **ZlibRaw** or the **Zlib** bit is set, the
+subrectangle is compressed using zlib, like this:
+
+=============== =================== ===================================
+No. of bytes    Type                Description
+=============== =================== ===================================
+2               ``U16``             *length*
+*length*        ``U8`` array        *zlibData*
+=============== =================== ===================================
+
+Like the **Raw** bit in hextile, the **ZlibRaw** bit in zlibhex cancels
+all other bits and the subrectangle is encoded using the first zlib
+"stream" object. The *zlibData*, when uncompressed, should in this case
+be interpreted as the **Raw** data in the hextile encoding.
+
+If the **Zlib** bit is set, the rectangle is encoded using the second
+zlib "stream" object. The *zlibData*, when uncompressed, represents a
+plain hextile rectangle according to the lower 5 bits in the
+subencoding.
+
+If neither the **ZlibRaw** nor the **Zlib** bit is set, the
+subrectangle follows the rules described in the `Hextile Encoding`_.
+
 ZRLE Encoding
 -------------
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3815
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3815&view=rev
Author:   ossman_
Date:     2009-05-28 12:19:20 +0000 (Thu, 28 May 2009)

Log Message:
-----------
Clarify DesktopSize behaviour

The implementation of the DesktopSize (also called NewFBSize)
pseudo-encoding differs a bit between VNC families. This tries to
document a behaviour that works in the majority of the
implementations.

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-05-20 09:01:24 UTC (rev 3814)
+++ rfbproto/rfbproto.rst	2009-05-28 12:19:20 UTC (rev 3815)
@@ -1737,13 +1737,68 @@
 
 A client which requests the *DesktopSize* pseudo-encoding is declaring
 that it is capable of coping with a change in the framebuffer width
-and/or height. The server changes the desktop size by sending a
-pseudo-rectangle with the *DesktopSize* pseudo-encoding as the last
-rectangle in an update. The pseudo-rectangle's *x-position* and
-*y-position* are ignored, and *width* and *height* indicate the new
+and/or height.
+  
+The server changes the desktop size by sending a pseudo-rectangle with
+the *DesktopSize* pseudo-encoding. The pseudo-rectangle's *x-position*
+and *y-position* are ignored, and *width* and *height* indicate the new
 width and height of the framebuffer. There is no further data
 associated with the pseudo-rectangle.
 
+The semantics of the *DesktopSize* pseudo-encoding were originally not
+clearly defined and as a results there are multiple differing
+implementations in the wild. Both the client and server need to take
+special steps to ensure maximum compatibility.
+
+In the initial implementation the *DesktopSize* pseudo-rectangle was
+sent in its own update without any modifications to the framebuffer
+data. The client would discard the framebuffer contents upon receiving
+this pseudo-rectangle and the server would consider the entire
+framebuffer to be modified.
+
+The semantics defined here retain compatibility with both of two older
+implementations.
+
+Server Semantics
+~~~~~~~~~~~~~~~~
+
+The update containing the pseudo-rectangle should not contain any
+rectangles that change the framebuffer data as that will most likely be
+discarded by the client and will have to be resent later.
+
+The server should assume that the client discards the framebuffer data
+when receiving a *DesktopSize* pseudo-rectangle. It should therefore
+not use any encoding that relies on the previous contents of the
+framebuffer. The server should also consider the entire framebuffer to
+be modified.
+
+Some early client implementations require the *DesktopSize*
+pseudo-rectangle to be the very last rectangle in an update. Servers
+should make every effort to support these.
+
+The server should only send a *DesktopSize* pseudo-rectangle when an
+actual change of the framebuffer dimensions has occurred. Some clients
+respond to a *DesktopSize* pseudo-rectangle in a way that could send
+the system into an infinite loop if the server sent out the
+pseudo-rectangle for anything other than an actual change.
+
+Client Semantics
+~~~~~~~~~~~~~~~~
+
+The client should assume that the server expects the framebuffer data
+to be retained when the framebuffer dimensions change. This requirement
+can be satisfied either by actually retaining the framebuffer data, or
+by making sure that *incremental* is set to non-zero in the next
+*FramebufferUpdateRequest*.
+
+The principle of one framebuffer update being a transition from one
+valid state to another does not hold for updates with the *DesktopSize*
+pseudo-rectangle as the framebuffer contents can temporarily be
+partially or completely undefined. Clients should try to handle this
+gracefully, e.g. by showing a black framebuffer or delay the screen
+update until a proper update of the framebuffer contents has been
+received.
+
 gii (General Input Interface) Pseudo-encoding
 ---------------------------------------------
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3819
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3819&view=rev
Author:   ossman_
Date:     2009-05-28 13:51:51 +0000 (Thu, 28 May 2009)

Log Message:
-----------
Don't spell out General Input Interface in every heading.

Also add some introductory text to each chapter involving gii.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-05-28 13:38:53 UTC (rev 3818)
+++ rfbproto/rfbproto.rst	2009-05-28 13:51:51 UTC (rev 3819)
@@ -81,7 +81,7 @@
 keyboard events.
 
 If you have an input source that does not fit this standard workstation
-model, the Generial Input Interface (gii) protocol extension provides
+model, the General Input Interface (gii) protocol extension provides
 possibilities for input sources with more axes, relative movement and
 more buttons.
 
@@ -506,7 +506,7 @@
 =========== ===========================================================
 255         Anthony Liguori
 254, 127    VMWare
-253         `gii (General Input Interface) Client Message`_
+253         `gii Client Message`_
 252         tight
 251         Pierre Ossman SetDesktopSize
 250         Colin Dean xvp
@@ -792,9 +792,13 @@
 *length*        ``U8`` array                    *text*
 =============== ==================== ========== =======================
 
-gii (General Input Interface) Client Message
---------------------------------------------
+gii Client Message
+------------------
 
+This message is an extension and may only be sent if the client has
+previously received a `gii Server Message`_ confirming that the server
+supports the General Input Interface extension.
+
 Version
 ~~~~~~~
 
@@ -1075,7 +1079,7 @@
 =========== ===========================================================
 255         Anthony Liguori
 254, 127    VMWare
-253         `gii (General Input Interface) Server Message`_
+253         `gii Server Message`_
 252         tight
 250         Colin Dean xvp
 =========== ===========================================================
@@ -1183,9 +1187,14 @@
 *length*        ``U8`` array                    *text*
 =============== ==================== ========== =======================
 
-gii (General Input Interface) Server Message
---------------------------------------------
+gii Server Message
+------------------
 
+This message is an extension and may only be sent if the server has
+previously received a `SetEncodings`_ message confirming that the
+client supports the General Input Interface extension via the `gii
+Pseudo-encoding`_.
+
 Version
 ~~~~~~~
 
@@ -1247,7 +1256,7 @@
 16          `ZRLE Encoding`_
 -239        `Cursor Pseudo-encoding`_
 -223        `DesktopSize Pseudo-encoding`_
--305        `gii (General Input Interface) Pseudo-encoding`_
+-305        `gii Pseudo-encoding`_
 =========== ===========================================================
 
 Other registered encodings are:
@@ -1820,14 +1829,14 @@
 update until a proper update of the framebuffer contents has been
 received.
 
-gii (General Input Interface) Pseudo-encoding
----------------------------------------------
+gii Pseudo-encoding
+-------------------
 
-A client which requests the *gii* pseudo-encoding is declaring that it
-is capable of accepting the *gii* server-to-client message. The server
-declares that it is capable of accepting the *gii* client-to-server
-messages by sending a *gii* server-to-client message of subtype
-*version*.
+A client that supports the General Input Interface extension starts by
+requesting the *gii* pseudo-encoding declaring that it is capable of
+accepting the `gii Server Message`_. The server, in turn, declares that
+it is capable of accepting the `gii Client Message`_ by sending a `gii
+Server Message`_ of subtype *version*.
 
 Requesting the *gii* pseudo-encoding is the first step when a client
 wants to use the *gii* extension of the RFB protocol. The *gii*


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3818
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3818&view=rev
Author:   ossman_
Date:     2009-05-28 13:38:53 +0000 (Thu, 28 May 2009)

Log Message:
-----------
Clarify FramebufferUpdateRequest/FramebufferUpdate behaviour

There are some corner cases in the framebuffer update system that need
to be explicitly mentioned.

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-05-28 12:54:24 UTC (rev 3817)
+++ rfbproto/rfbproto.rst	2009-05-28 13:38:53 UTC (rev 3818)
@@ -532,6 +532,11 @@
 message the colour map is empty, even if entries had previously been
 set by the server.
 
+Note that a client must not have an outstanding
+*FramebufferUpdateRequest* when it sends *SetPixelFormat* as it would
+be impossible to determine if the next *FramebufferUpdate* is using the
+new or the previous pixel format.
+
 =============== ==================== ========== =======================
 No. of bytes    Type                 [Value]    Description
 =============== ==================== ========== =======================
@@ -637,6 +642,12 @@
 2               ``U16``                         *height*
 =============== ==================== ========== =======================
 
+A request for an area that partly falls outside the current framebuffer
+must be cropped so that it fits within the framebuffer dimensions.
+
+Note that an empty area can still solicit a *FramebufferUpdate* even
+though that update will only contain pseudo-encodings.
+
 KeyEvent
 --------
 
@@ -1108,6 +1119,16 @@
 for the format of the data for each encoding and `Pseudo-encodings`_
 for the meaning of pseudo-encodings.
 
+Note that a framebuffer update marks a transition from one valid
+framebuffer state to another. That means that a single update handles
+all received *FramebufferUpdateRequest* up to the point where the
+update is sent out.
+
+However, because there is no strong connection between a
+*FramebufferUpdateRequest* and a subsequent *FramebufferUpdate*, a
+client that has more than one *FramebufferUpdateRequest* pending at any
+given time cannot be sure that it has received all framebuffer updates.
+
 SetColourMapEntries
 -------------------
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3820
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3820&view=rev
Author:   ossman_
Date:     2009-05-28 14:30:22 +0000 (Thu, 28 May 2009)

Log Message:
-----------
ExtendedDesktopSize extension

This extension adds multi-head support to RFB, and allows the client to
request framebuffer and screen layout changes on the server.

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-05-28 13:51:51 UTC (rev 3819)
+++ rfbproto/rfbproto.rst	2009-05-28 14:30:22 UTC (rev 3820)
@@ -69,6 +69,56 @@
 ignored, resulting in less network traffic and less drawing for the
 client.
 
+Screen Model
+++++++++++++
+
+In its simplest form, the RFB protocol uses a single, rectangular
+framebuffer. All updates are contained within this buffer and may not
+extend outside of it. A client with basic functionality simply presents
+this buffer to the user, padding or cropping it as necessary to fit
+the user's display.
+
+More advanced RFB clients and servers have the ability to extend this
+model and add multiple screens. The purpose being to create a
+server-side representation of the client's physical layout.
+Applications can use this information to properly position themselves
+with regard to screen borders.
+
+In the multiple-screen model, there is still just a single framebuffer
+and framebuffer updates are unaffected by the screen layout. This
+assures compatibility between basic clients and advanced servers.
+Screens are added to this model and act like viewports into the
+framebuffer. A basic client acts as if there is a single screen
+covering the entire framebuffer.
+
+The server may support up to 255 screens, which must be contained fully
+within the current framebuffer. Multiple screens may overlap partially
+or completely.
+
+The client must keep track of the contents of the entire framebuffer,
+not just the areas currently covered by a screen. Similarly, the server
+is free to use encodings that rely on contents currently not visible
+inside any screen. For example it may issue a *CopyRect* rectangle from
+any part of the framebuffer that should already be known to the client.
+
+The client can request changes to the framebuffer size and screen
+layout. The server is free to approve or deny these requests at will,
+but must always inform the client of the result. See the
+`SetDesktopSize`_ message for details.
+
+If the framebuffer size changes, for whatever reason, then all data in
+it is invalidated and considered undefined. The server must not use
+any encoding that relies on the previous framebuffer contents. Note
+however that the semantics for *DesktopSize* are not well-defined and
+do not follow this behaviour in all server implementations. See the
+`DesktopSize Pseudo-encoding`_ chapter for full details.
+
+Changing only the screen layout does not affect the framebuffer
+contents. The client must therefore keep track of the current
+framebuffer dimensions and compare it with the one received in the
+*ExtendedDesktopSize* rectangle. Only when they differ may it discard
+the framebuffer contents.
+
 Input Protocol
 ==============
 
@@ -508,7 +558,7 @@
 254, 127    VMWare
 253         `gii Client Message`_
 252         tight
-251         Pierre Ossman SetDesktopSize
+251         `SetDesktopSize`_
 250         Colin Dean xvp
 =========== ===========================================================
 
@@ -1058,6 +1108,72 @@
 
 The event reports *count* valuators starting with *first*.
 
+SetDesktopSize
+--------------
+
+Requests a change of desktop size. This message is an extension and
+may only be sent if the client has previously received an
+*ExtendedDesktopSize* rectangle.
+
+The server must send an *ExtendedDesktopSize* rectangle for every
+*SetDesktopSize* message received. Several rectangles may be
+sent in a single *FramebufferUpdate* message, but the rectangles must
+not be merged or reordered in any way. Note that rectangles sent for
+other reasons may be interleaved with the ones generated as a result
+of *SetDesktopSize* messages.
+
+Upon a successful request the server must send an *ExtendedDesktopSize*
+rectangle to the requesting client with the exact same information the
+client provided in the corresponding *SetDesktopSize* message.
+*x-position* must be set to 1, indicating a client initiated event, and
+*y-position* must be set to 0, indicating success.
+
+The server must also send an *ExtendedDesktopSize* rectangle to all
+other connected clients, but with *x-position* set to 2, indicating a
+change initiated by another client.
+
+If the server can not or will not satisfy the request, it must send
+an *ExtendedDesktopSize* rectangle to the requesting client with
+*x-position* set to 1 and *y-position* set to the relevant error code.
+All remaining fields are undefined, although the basic structure must
+still be followed. The server must not send an *ExtendedDesktopSize*
+rectangle to any other connected clients.
+
+All *ExtendedDesktopSize* rectangles that are sent as a result of a 
+*SetDesktopSize* message should be sent as soon as possible.
+
+======================== ================= ======= ====================
+No. of bytes             Type              [Value] Description
+======================== ================= ======= ====================
+1                        ``U8``            251     *message-type*
+2                                                  *padding*
+2                        ``U16``                   *width*
+2                        ``U16``                   *height*
+1                        ``U8``                    *number-of-screens*
+1                                                  *padding*
+*number-of-screens* * 16 ``SCREEN`` array          *screens*
+======================== ================= ======= ====================
+
+The *width* and *height* indicates the framebuffer size requested. This
+structure is followed by *number-of-screens* number of ``SCREEN``
+structures, which is defined in `ExtendedDesktopSize Pseudo-encoding`_:
+
+=============== =============================== =======================
+No. of bytes    Type                            Description
+=============== =============================== =======================
+4               ``U32``                         *id*
+2               ``U16``                         *x-position*
+2               ``U16``                         *y-position*
+2               ``U16``                         *width*
+2               ``U16``                         *height*
+4               ``U32``                         *flags*
+=============== =============================== =======================
+
+The *id* field must be preserved upon modification as it determines the
+difference between a moved screen and a newly created one. The client
+should make every effort to preserve the fields it does not wish to
+modify, including any unknown *flags* bits.
+
 Server to Client Messages
 +++++++++++++++++++++++++
 
@@ -1257,6 +1373,7 @@
 -239        `Cursor Pseudo-encoding`_
 -223        `DesktopSize Pseudo-encoding`_
 -305        `gii Pseudo-encoding`_
+-308        `ExtendedDesktopSize Pseudo-encoding`_
 =========== ===========================================================
 
 Other registered encodings are:
@@ -1274,7 +1391,6 @@
 -273 to -304                VMWare
 -306                        popa
 -307                        Peter Astrand DesktopName
--308                        Pierre Ossman ExtendedDesktopSize
 -309                        Colin Dean xvp
 0x574d5600 to 0x574d56ff    VMWare
 =========================== ===========================================
@@ -1844,3 +1960,133 @@
 where the standard input model is insufficient. It supports relative
 mouse movements, mouses with more than 8 buttons and mouses with more
 than three axes. It even supports joysticks and gamepads.
+
+ExtendedDesktopSize Pseudo-encoding
+-----------------------------------
+
+A client which requests the *ExtendedDesktopSize* pseudo-encoding is
+declaring that it is capable of coping with a change in the
+framebuffer width, height, and/or screen configuration. This encoding
+is used in conjunction with the *SetDesktopSize* message. If a server
+supports the *ExtendedDesktopSize* encoding, it must also have basic
+support for the *SetDesktopSize* message although it may deny all
+requests to change the screen layout.
+
+The *ExtendedDesktopSize* pseudo-encoding is designed to replace the
+simpler *DesktopSize* one. Servers and clients should support both for
+maximum compatibility, but a server must only send the extended
+version to a client asking for both. The semantics of *DesktopSize* are
+not as well-defined as for *ExtendedDesktopSize* and handling both at
+the same time would require needless complexity in the client.
+
+The server must send an *ExtendedDesktopSize* rectangle in response to
+a *FramebufferUpdateRequest* with *incremental* set to zero, assuming
+the client has requested the *ExtendedDesktopSize* pseudo-encoding
+using the *SetEncodings* message. This requirement is needed so that
+the client has a reliable way of fetching the initial screen
+configuration, and to determine if the server supports the
+*SetDesktopSize* message.
+
+A consequence of this is that a client must not respond to an
+*ExtendedDesktopSize* rectangle by sending a *FramebufferUpdateRequest*
+with *incremental* set to zero. Doing so would make the system go into
+an infinite loop.
+
+The server must also send an *ExtendedDesktopSize* rectangle in
+response to a *SetDesktopSize* message, indicating the result.
+
+For a full description of server behaviour as a result of the
+*SetDesktopSize* message, `SetDesktopSize`_.
+
+Rectangles sent as a result of a *SetDesktopSize* message must be sent
+as soon as possible. Rectangles sent for other reasons may be subjected
+to delays imposed by the server.
+
+An update containing an *ExtendedDesktopSize* rectangle must not
+contain any changes to the framebuffer data, neither before nor after
+the *ExtendedDesktopSize* rectangle.
+
+The pseudo-rectangle's *x-position* indicates the reason for the
+change:
+
+0
+    The screen layout was changed via non-RFB means on the server. For
+    example the server may have provided means for server-side
+    applications to manipulate the screen layout. This code is also
+    used when the client sends a non-incremental
+    *FrameBufferUpdateRequest* to learn the server's current state.
+
+1
+    The client receiving this message requested a change of the screen
+    layout. The change may or may not have happened depending on server
+    policy or available resources. The status code in the *y-position*
+    field must be used to determine which.
+
+2
+    Another client requested a change of the screen layout and the
+    server approved it. A rectangle with this code is never sent if the
+    server denied the request.
+
+More reasons may be added in the future. Clients should treat an
+unknown value as a server-side change (i.e. as if *x-position* was set
+to zero).
+
+The pseudo-rectangle's *y-position* indicates the status code for a
+change requested by a client:
+
+======= ===============================================================
+Code    Description
+======= ===============================================================
+0       No error
+1       Resize is administratively prohibited
+2       Out of resources
+3       Invalid screen layout
+======= ===============================================================
+
+This field shall be set to zero by the server and ignored by clients
+when not defined. Other error codes may be added in the future and
+clients must treat them as an unknown failure.
+
+The *width* and *height* indicates the new width and height of the
+framebuffer.
+
+The encoding data is defined as:
+
+=========================== =================== =======================
+No. of bytes                Type                Description
+=========================== =================== =======================
+1                           ``U8``              *number-of-screens*
+3                                               *padding*
+*number-of-screens* * 16    ``SCREEN`` array    *screens*
+=========================== =================== =======================
+
+The *number-of-screens* field indicates the number of active screens
+and allows for multi head configurations. It also indicates how many
+``SCREEN`` structures that follows. These are defined as:
+
+=============== =============================== =======================
+No. of bytes    Type                            Description
+=============== =============================== =======================
+4               ``U32``                         *id*
+2               ``U16``                         *x-position*
+2               ``U16``                         *y-position*
+2               ``U16``                         *width*
+2               ``U16``                         *height*
+4               ``U32``                         *flags*
+=============== =============================== =======================
+
+The *id* field contains an arbitrary value that the server and client
+can use to map RFB screens to physical screens. The value must be
+unique in the current set of screens and must be preserved for the
+lifetime of that RFB screen. New ids are assigned by whichever side
+creates the screen. An *id* may be reused if there has been a subsequent
+update of the screen layout where the *id* was not used.
+
+The *flags* field is currently unused. Clients and servers must ignore,
+but preserve, any bits it does not understand. For new screens, those
+bits must be set to zero.
+
+Note that a simple client which does not support multi head does not
+need to parse the list of screens and can simply display the entire
+framebuffer.
+


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3822
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3822&view=rev
Author:   ossman_
Date:     2009-05-29 12:42:07 +0000 (Fri, 29 May 2009)

Log Message:
-----------
Fix grammar in gii Server Message description

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-05-29 12:40:55 UTC (rev 3821)
+++ rfbproto/rfbproto.rst	2009-05-29 12:42:07 UTC (rev 3822)
@@ -1543,7 +1543,7 @@
 Version
 ~~~~~~~
 
-The server response from a with server *gii* capabilities to a client
+The server response from a server with *gii* capabilities to a client
 declaring *gii* capabilities is a *gii* version message:
 
 =============== ==================== ========== =======================


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3821
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3821&view=rev
Author:   ossman_
Date:     2009-05-29 12:40:55 +0000 (Fri, 29 May 2009)

Log Message:
-----------
Describe the Tight security type

Information collected from the rfbproto.h header and the
registered-codes.txt document from the TightVNC project.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-05-28 14:30:22 UTC (rev 3820)
+++ rfbproto/rfbproto.rst	2009-05-29 12:40:55 UTC (rev 3821)
@@ -344,6 +344,7 @@
 0           Invalid
 1           `None`_
 2           `VNC Authentication`_
+16          `Tight Security Type`_
 =========== ===========================================================
 
 Other registered security types are:
@@ -353,7 +354,6 @@
 =========== ===========================================================
 5           RA2
 6           RA2ne
-16          Tight
 17          Ultra
 18          TLS
 19          VeNCrypt
@@ -381,8 +381,11 @@
 4               ``U32``             status:
 ..                      0           OK
 ..                      1           failed
+..                      2           failed, too many attempts [#]_
 =============== ======= =========== ===================================
 
+.. [#] Only valid if the `Tight Security Type`_ is enabled.
+
 If successful, the protocol passes to the initialisation phase
 (`Initialisation Messages`_).
 
@@ -439,6 +442,138 @@
 
 The protocol continues with the *SecurityResult* message.
 
+Tight Security Type
+-------------------
+
+The Tight security type is a generic protocol extension that allows for
+three things:
+
+Tunneling of data
+    A tunnel can be e.g. encryption, or indeed a no-op tunnel.
+
+Authentication
+    The Tight security type allows for flexible authentication of the
+    client, which is typically one of the other security types.
+
+Server capabilities
+    As a last step the Tight security type extends the `ServerInit`_
+    message and enables the server to let the client know about the
+    server capabilities in terms of encodings and supported message
+    types.
+
+The Tight security type is under the control of the TightVNC project,
+and any new numbers must be registered with that project before they
+can be added to any of the lists of Tight capabilities. It is strongly
+recommended that any messages and security types registered with
+RealVNC are also registered with the TightVNC project (register
+security types as Tight authentication capabilities) in order to
+eliminate clashes as much as is possible. Same thing with new
+encodings, but in that case the problem is not as severe as the
+TightVNC project are not using any encodings that are not registered
+with RealVNC. Please see the TightVNC website at
+http://www.tightvnc.com/ for details on how to contact the project.
+
+After the Tight security type has been selected, the server starts by
+sending a list of supported tunnels, in order of preference:
+
+=============== =============================== =======================
+No. of bytes    Type                            Description
+=============== =============================== =======================
+4               ``U32``                         *number-of-tunnels*
+=============== =============================== =======================
+
+followed by *number-of-tunnels* repetitions of the following:
+
+=============== =============================== =======================
+No. of bytes    Type                            Description
+=============== =============================== =======================
+16              ``CAPABILITY``                  *tunnel*
+=============== =============================== =======================
+
+where ``CAPABILITY`` is
+
+=============== =============================== =======================
+No. of bytes    Type                            Description
+=============== =============================== =======================
+4               ``S32``                         *code*
+4               ``U8`` array                    *vendor*
+8               ``U8`` array                    *signature*
+=============== =============================== =======================
+
+Note that the *code* is not the only thing identifying a capability.
+The client must ensure that all members of the structure match before
+using the capability. Also note that *code* is ``U32`` in the original
+Tight documentation and implementation, but since *code* is used to
+hold encoding numbers we have selected ``S32`` in this document.
+
+The following tunnel capabilities are registered:
+
+======= =========== =============== ===================================
+Code    Vendor      Signature       Description
+======= =========== =============== ===================================
+0       "``TGHT``"  "``NOTUNNEL``"  No tunneling
+======= =========== =============== ===================================
+
+If *number-of-tunnels* is non-zero, the client has to request a tunnel
+from the list with a tunneling method request:
+
+=============== =============================== =======================
+No. of bytes    Type                            Description
+=============== =============================== =======================
+4               ``S32``                         *code*
+=============== =============================== =======================
+
+If *number-of-tunnels* is zero, the client must make no such request,
+instead the server carries on with sending the list of supported
+authentication types, in order of preference:
+
+=============== =============================== =======================
+No. of bytes    Type                            Description
+=============== =============================== =======================
+4               ``U32``                         *number-of-auth-types*
+=============== =============================== =======================
+
+followed by *number-of-auth-types* repetitions of the following:
+
+=============== =============================== =======================
+No. of bytes    Type                            Description
+=============== =============================== =======================
+16              ``CAPABILITY``                  *auth-type*
+=============== =============================== =======================
+
+The following authentication capabilities are registered:
+
+======= =========== =============== ===================================
+Code    Vendor      Signature       Description
+======= =========== =============== ===================================
+1       "``STDV``"  "``NOAUTH__``"  `None`_
+2       "``STDV``"  "``VNCAUTH_``"  `VNC Authentication`_
+19      "``VENC``"  "``VENCRYPT``"  VeNCrypt Security
+20      "``GTKV``"  "``SASL____``"  Simple Authentication and Security
+                                    Layer (SASL)
+129     "``TGHT``"  "``ULGNAUTH``"  Unix Login Authentication
+130     "``TGHT``"  "``XTRNAUTH``"  External Authentication
+======= =========== =============== ===================================
+
+If *number-of-auth-types* is non-zero, the client has to request an
+authentication type from the list with an authentication scheme
+request:
+
+=============== =============================== =======================
+No. of bytes    Type                            Description
+=============== =============================== =======================
+4               ``S32``                         *code*
+=============== =============================== =======================
+
+For *code* 1, the protocol the proceeds at security type `None`_ and
+for *code* 2 it proceeds at security type `VNC Authentication`_.
+
+If *number-of-auth-types* is zero, the protocol the proceeds directly
+at security type `None`_.
+
+Note that the `ServerInit`_ message is extended when the Tight security
+type has been activated.
+
 Initialisation Messages
 +++++++++++++++++++++++
 
@@ -533,6 +668,100 @@
 the colour map are set by the server using the *SetColourMapEntries*
 message (`SetColourMapEntries`_).
 
+If the `Tight Security Type`_ is activated, the server init message is
+extended with an interaction capabilities section:
+
+=============== =========== ========== ================================
+No. of bytes    Type        [Value]    Description
+=============== =========== ========== ================================
+2               ``U16``                *number-of-server-messages*
+2               ``U16``                *number-of-client-messages*
+2               ``U16``                *number-of-encodings*
+2               ``U16``     0          *padding*
+=============== =========== ========== ================================
+
+followed by *number-of-server-messages* repetitions of the following:
+
+=============== =============================== =======================
+No. of bytes    Type                            Description
+=============== =============================== =======================
+16              ``CAPABILITY``                  *server-message*
+=============== =============================== =======================
+
+followed by *number-of-client-messages* repetitions of the following:
+
+=============== =============================== =======================
+No. of bytes    Type                            Description
+=============== =============================== =======================
+16              ``CAPABILITY``                  *client-message*
+=============== =============================== =======================
+
+followed by *number-of-encodings* repetitions of the following:
+
+=============== =============================== =======================
+No. of bytes    Type                            Description
+=============== =============================== =======================
+16              ``CAPABILITY``                  *encoding*
+=============== =============================== =======================
+
+The following *server-message* capabilities are registered:
+
+======= =========== =============== ===================================
+Code    Vendor      Signature       Description
+======= =========== =============== ===================================
+130     "``TGHT``"  "``FTS_LSDT``"  File List Data
+131     "``TGHT``"  "``FTS_DNDT``"  File Download Data
+132     "``TGHT``"  "``FTS_UPCN``"  File Upload Cancel
+133     "``TGHT``"  "``FTS_DNFL``"  File Download Failed
+150     "``TGHT``"  "``CUS_EOCU``"  End Of Continuous Updates
+253     "``GGI_``"  "``GII_SERV``"  `gii Server Message`_
+======= =========== =============== ===================================
+
+The following *client-message* capabilities are registered:
+
+======= =========== =============== ===================================
+Code    Vendor      Signature       Description
+======= =========== =============== ===================================
+130     "``TGHT``"  "``FTC_LSRQ``"  File List Request
+131     "``TGHT``"  "``FTC_DNRQ``"  File Download Request
+132     "``TGHT``"  "``FTC_UPRQ``"  File Upload Request
+133     "``TGHT``"  "``FTC_UPDT``"  File Upload Data
+134     "``TGHT``"  "``FTC_DNCN``"  File Download Cancel
+135     "``TGHT``"  "``FTC_UPFL``"  File Upload Failed
+136     "``TGHT``"  "``FTC_FCDR``"  File Create Directory Request
+150     "``TGHT``"  "``CUC_ENCU``"  Enable/Disable Continuous Updates
+151     "``TGHT``"  "``VRECTSEL``"  Video Rectangle Selection
+253     "``GGI_``"  "``GII_CLNT``"  `gii Client Message`_
+======= =========== =============== ===================================
+
+The following *encoding* capabilities are registered:
+
+======= =========== =============== ===================================
+Code    Vendor      Signature       Description
+======= =========== =============== ===================================
+0       "``STDV``"  "``RAW_____``"  `Raw Encoding`_
+1       "``STDV``"  "``COPYRECT``"  `CopyRect Encoding`_
+2       "``STDV``"  "``RRE_____``"  `RRE Encoding`_
+4       "``STDV``"  "``CORRE___``"  `CoRRE Encoding`_
+5       "``STDV``"  "``HEXTILE_``"  `Hextile Encoding`_
+6       "``TRDV``"  "``ZLIB____``"  `ZLib Encoding`_
+7       "``TGHT``"  "``TIGHT___``"  Tight Encoding
+8       "``TRDV``"  "``ZLIBHEX_``"  `ZLibHex Encoding`_
+-32     "``TGHT``"  "``JPEGQLVL``"  JPEG Quality Level
+-223    "``TGHT``"  "``NEWFBSIZ``"  `DesktopSize Pseudo-encoding`_ (New
+                                    FB Size)
+-224    "``TGHT``"  "``LASTRECT``"  Last Rect
+-232    "``TGHT``"  "``POINTPOS``"  Pointer Position
+-239    "``TGHT``"  "``RCHCURSR``"  `Cursor Pseudo-encoding`_ (Rich
+                                    Cursor)
+-240    "``TGHT``"  "``X11CURSR``"  X Cursor
+-256    "``TGHT``"  "``COMPRLVL``"  Compression Level
+-305    "``GGI_``"  "``GII_____``"  `gii Pseudo-encoding`_
+======= =========== =============== ===================================
+
+Note that the server need not (but it may) list the "``RAW_____``"
+capability since it must be supported anyway.
+
 Client to Server Messages
 +++++++++++++++++++++++++
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3823
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3823&view=rev
Author:   ossman_
Date:     2009-05-29 14:27:03 +0000 (Fri, 29 May 2009)

Log Message:
-----------
Clarify key autorepeat behaviour

There exists client that send repeated "down" events on automatic key
repeats, and those that send pairs of "up" and "down". Usually this
behaviour depends on the platform on which the client runs.

Since only the repeated "down" case allows the server to tell the
difference between automatic and manual key repeats, clarify that the
"down" repeat method is the preferred.

Also clarify that the client should handle auto repeat because of
latency problems.

Signed-off-by: Pierre Ossman <ossman@...>
Signed-off-by: Peter Rosin <peda@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-05-29 12:42:07 UTC (rev 3822)
+++ rfbproto/rfbproto.rst	2009-05-29 14:27:03 UTC (rev 3823)
@@ -943,6 +943,16 @@
 4               ``U32``                         *key*
 =============== ==================== ========== =======================
 
+Auto repeating of keys when a key is held down should be handled on the
+client. The rationale being that high latency on the network can make
+it seem like a key is being held for a very long time, yet the problem
+is that the *KeyEvent* message releasing the button has been delayed.
+
+The client should send only repeated "down" *KeyEvent* messages, no
+"up" messages, when a key is automatically repeated. This allows the
+server to tell the difference between automatic repeat and actual
+repeated entry by the user.
+
 For most ordinary keys, the "keysym" is the same as the corresponding
 ASCII value. For full details, see The Xlib Reference Manual, published
 by O'Reilly & Associates, or see the header file ``<X11/keysymdef.h>``


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3824
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3824&view=rev
Author:   ossman_
Date:     2009-06-01 09:45:20 +0000 (Mon, 01 Jun 2009)

Log Message:
-----------
Add missing description for second implementation

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-05-29 14:27:03 UTC (rev 3823)
+++ rfbproto/rfbproto.rst	2009-06-01 09:45:20 UTC (rev 3824)
@@ -2141,6 +2141,11 @@
 this pseudo-rectangle and the server would consider the entire
 framebuffer to be modified.
 
+A later implementation sent the *DesktopSize* pseudo-rectangle together
+with modifications to the framebuffer data. It also expected the client
+to retain the framebuffer contents as those modifications could be from
+after the framebuffer resize had occurred on the server.
+
 The semantics defined here retain compatibility with both of two older
 implementations.
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3825
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3825&view=rev
Author:   ossman_
Date:     2009-06-01 09:51:10 +0000 (Mon, 01 Jun 2009)

Log Message:
-----------
Remove stray whitespace

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-06-01 09:45:20 UTC (rev 3824)
+++ rfbproto/rfbproto.rst	2009-06-01 09:51:10 UTC (rev 3825)
@@ -1378,7 +1378,7 @@
 still be followed. The server must not send an *ExtendedDesktopSize*
 rectangle to any other connected clients.
 
-All *ExtendedDesktopSize* rectangles that are sent as a result of a 
+All *ExtendedDesktopSize* rectangles that are sent as a result of a
 *SetDesktopSize* message should be sent as soon as possible.
 
 ======================== ================= ======= ====================
@@ -2123,7 +2123,7 @@
 A client which requests the *DesktopSize* pseudo-encoding is declaring
 that it is capable of coping with a change in the framebuffer width
 and/or height.
-  
+
 The server changes the desktop size by sending a pseudo-rectangle with
 the *DesktopSize* pseudo-encoding. The pseudo-rectangle's *x-position*
 and *y-position* are ignored, and *width* and *height* indicate the new
@@ -2333,4 +2333,3 @@
 Note that a simple client which does not support multi head does not
 need to parse the list of screens and can simply display the entire
 framebuffer.
-


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3832
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3832&view=rev
Author:   ossman_
Date:     2009-06-04 09:09:43 +0000 (Thu, 04 Jun 2009)

Log Message:
-----------
Describe the xvp extension

The xvp extension allows a client to perform shutdown, reboot and reset
operations on the system whose framebuffer it is displaying.

Signed-off-by: Colin Dean <c.c.dean@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-06-02 13:42:55 UTC (rev 3831)
+++ rfbproto/rfbproto.rst	2009-06-04 09:09:43 UTC (rev 3832)
@@ -788,7 +788,7 @@
 253         `gii Client Message`_
 252         tight
 251         `SetDesktopSize`_
-250         Colin Dean xvp
+250         `xvp Client Message`_
 =========== ===========================================================
 
 Note that before sending a message with an optional message type a
@@ -1413,6 +1413,27 @@
 should make every effort to preserve the fields it does not wish to
 modify, including any unknown *flags* bits.
 
+xvp Client Message
+------------------
+
+A client supporting the *xvp* extension sends this to request that the
+server initiate a clean shutdown, clean reboot or abrupt reset of the
+system whose framebuffer the client is displaying.
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               250        *message-type*
+1                                               *padding*
+1               ``U8``               1          *xvp-extension-version*
+1               ``U8``                          *xvp-message-code*
+=============== ==================== ========== =======================
+
+The possible values for *xvp-message-code* are: 2 - XVP_SHUTDOWN,
+3 - XVP_REBOOT, and 4 - XVP_RESET.  The client must have already
+established that the server supports this extension, by requesting the
+`xvp Pseudo-encoding`_.
+
 Server to Client Messages
 +++++++++++++++++++++++++
 
@@ -1436,7 +1457,7 @@
 254, 127    VMWare
 253         `gii Server Message`_
 252         tight
-250         Colin Dean xvp
+250         `xvp Server Message`_
 =========== ===========================================================
 
 Note that before sending a message with an optional message type a
@@ -1593,6 +1614,36 @@
 communications. A *device-origin* of zero indicates device creation
 failure.
 
+xvp Server Message
+------------------
+
+This has the following format:
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               250        *message-type*
+1                                               *padding*
+1               ``U8``               1          *xvp-extension-version*
+1               ``U8``                          *xvp-message-code*
+=============== ==================== ========== =======================
+
+The possible values for *xvp-message-code* are: 0 - XVP_FAIL and 1 -
+XVP_INIT.
+
+A server which supports the *xvp* extension declares this by sending a
+message with an XVP_INIT *xvp-message-code* when it receives a request
+from the client to use the `xvp Pseudo-encoding`_.  The server must
+specify in this message the highest *xvp-extension-version* it supports:
+the client may assume that the server supports all versions from 1 up to
+this value.  The client is then free to use any supported version.
+Currently, only version 1 is defined.
+
+A server which subsequently receives an `xvp Client Message`_ requesting
+an operation which it is unable to perform, informs the client of this
+by sending a message with an XVP_FAIL *xvp-message-code*, and the same
+*xvp-extension-version* as included in the client's operation request.
+
 Encodings
 +++++++++
 
@@ -1613,6 +1664,7 @@
 -223        `DesktopSize Pseudo-encoding`_
 -305        `gii Pseudo-encoding`_
 -308        `ExtendedDesktopSize Pseudo-encoding`_
+-309        `xvp Pseudo-encoding`_
 =========== ===========================================================
 
 Other registered encodings are:
@@ -1630,7 +1682,6 @@
 -273 to -304                VMWare
 -306                        popa
 -307                        Peter Astrand DesktopName
--309                        Colin Dean xvp
 0x574d5600 to 0x574d56ff    VMWare
 =========================== ===========================================
 
@@ -2333,3 +2384,12 @@
 Note that a simple client which does not support multi head does not
 need to parse the list of screens and can simply display the entire
 framebuffer.
+
+xvp Pseudo-encoding
+-------------------
+
+A client which requests the *xvp* pseudo-encoding is declaring that it
+wishes to use the *xvp* extension.  If the server supports this, it
+replies with a message of type `xvp Server Message`_, using an
+*xvp-message-code* of *XVP_INIT*.  This informs the client that it may
+then subsequently send messages of type `xvp Client Message`_.


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3845
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3845&view=rev
Author:   ossman_
Date:     2009-06-17 09:11:34 +0000 (Wed, 17 Jun 2009)

Log Message:
-----------
Rearrange described and registered encodings.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-06-17 09:08:12 UTC (rev 3844)
+++ rfbproto/rfbproto.rst	2009-06-17 09:11:34 UTC (rev 3845)
@@ -1649,35 +1649,35 @@
 
 The encodings defined in this document are:
 
-=========== ===========================================================
-Number      Name
-=========== ===========================================================
-0           `Raw Encoding`_
-1           `CopyRect Encoding`_
-2           `RRE Encoding`_
-4           `CoRRE Encoding`_
-5           `Hextile Encoding`_
-6           `zlib Encoding`_
-8           `zlibhex Encoding`_
-16          `ZRLE Encoding`_
--239        `Cursor Pseudo-encoding`_
--223        `DesktopSize Pseudo-encoding`_
--305        `gii Pseudo-encoding`_
--308        `ExtendedDesktopSize Pseudo-encoding`_
--309        `xvp Pseudo-encoding`_
-=========== ===========================================================
+============ ==========================================================
+Number       Name
+============ ==========================================================
+0            `Raw Encoding`_
+1            `CopyRect Encoding`_
+2            `RRE Encoding`_
+4            `CoRRE Encoding`_
+5            `Hextile Encoding`_
+6            `zlib Encoding`_
+8            `zlibhex Encoding`_
+16           `ZRLE Encoding`_
+-223         `DesktopSize Pseudo-encoding`_
+-239         `Cursor Pseudo-encoding`_
+-305         `gii Pseudo-encoding`_
+-308         `ExtendedDesktopSize Pseudo-encoding`_
+-309         `xvp Pseudo-encoding`_
+============ ==========================================================
 
 Other registered encodings are:
 
 =========================== ===========================================
 Number                      Name
 =========================== ===========================================
-7                           tight
+7                           Tight
 15                          TRLE
 17                          Hitachi ZYWRLE
--1 to -222
--224 to -238
--240 to -256                tight options
+-1 to -222                  Tight options
+-224 to -238                Tight options
+-240 to -256                Tight options
 -257 to -272                Anthony Liguori
 -273 to -304                VMWare
 -306                        popa


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3846
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3846&view=rev
Author:   ossman_
Date:     2009-06-17 09:14:17 +0000 (Wed, 17 Jun 2009)

Log Message:
-----------
Describe the Tight Compression Level Pseudo-encoding.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-06-17 09:11:34 UTC (rev 3845)
+++ rfbproto/rfbproto.rst	2009-06-17 09:14:17 UTC (rev 3846)
@@ -755,7 +755,8 @@
 -239    "``TGHT``"  "``RCHCURSR``"  `Cursor Pseudo-encoding`_ (Rich
                                     Cursor)
 -240    "``TGHT``"  "``X11CURSR``"  X Cursor
--256    "``TGHT``"  "``COMPRLVL``"  Compression Level
+-256    "``TGHT``"  "``COMPRLVL``"  `Compression Level
+                                    Pseudo-encoding`_
 -305    "``GGI_``"  "``GII_____``"  `gii Pseudo-encoding`_
 ======= =========== =============== ===================================
 
@@ -1662,6 +1663,7 @@
 16           `ZRLE Encoding`_
 -223         `DesktopSize Pseudo-encoding`_
 -239         `Cursor Pseudo-encoding`_
+-247 to -256 `Compression Level Pseudo-encoding`_
 -305         `gii Pseudo-encoding`_
 -308         `ExtendedDesktopSize Pseudo-encoding`_
 -309         `xvp Pseudo-encoding`_
@@ -1677,7 +1679,7 @@
 17                          Hitachi ZYWRLE
 -1 to -222                  Tight options
 -224 to -238                Tight options
--240 to -256                Tight options
+-240 to -246                Tight options
 -257 to -272                Anthony Liguori
 -273 to -304                VMWare
 -306                        popa
@@ -2240,6 +2242,22 @@
 update until a proper update of the framebuffer contents has been
 received.
 
+Compression Level Pseudo-encoding
+---------------------------------
+
+Specifies the desired compression level. Encoding number -247 implies
+high compression level, -255 implies low compression level. Low
+compression level can be useful to get low latency in medium to high
+bandwidth situations and high compression level can be useful in low
+bandwidth situations.
+
+The compression level concerns lossless compression, and hence the
+setting is a tradoff between CPU time and bandwidth. It is therefore
+probably difficult to define exact cut-off points for which compression
+levels should be used for any given bandwidth. The compression level is
+just a hint for the server, and there is no specification for what a
+specific compression level means.
+
 gii Pseudo-encoding
 -------------------
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3847
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3847&view=rev
Author:   ossman_
Date:     2009-06-17 09:17:26 +0000 (Wed, 17 Jun 2009)

Log Message:
-----------
Describe the Tight LastRect Pseudo-encoding.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-06-17 09:14:17 UTC (rev 3846)
+++ rfbproto/rfbproto.rst	2009-06-17 09:17:26 UTC (rev 3847)
@@ -750,7 +750,7 @@
 -32     "``TGHT``"  "``JPEGQLVL``"  JPEG Quality Level
 -223    "``TGHT``"  "``NEWFBSIZ``"  `DesktopSize Pseudo-encoding`_ (New
                                     FB Size)
--224    "``TGHT``"  "``LASTRECT``"  Last Rect
+-224    "``TGHT``"  "``LASTRECT``"  `LastRect Pseudo-encoding`_
 -232    "``TGHT``"  "``POINTPOS``"  Pointer Position
 -239    "``TGHT``"  "``RCHCURSR``"  `Cursor Pseudo-encoding`_ (Rich
                                     Cursor)
@@ -1510,6 +1510,8 @@
 client that has more than one *FramebufferUpdateRequest* pending at any
 given time cannot be sure that it has received all framebuffer updates.
 
+See the `LastRect Pseudo-encoding`_ for an extension to this message.
+
 SetColourMapEntries
 -------------------
 
@@ -1662,6 +1664,7 @@
 8            `zlibhex Encoding`_
 16           `ZRLE Encoding`_
 -223         `DesktopSize Pseudo-encoding`_
+-224         `LastRect Pseudo-encoding`_
 -239         `Cursor Pseudo-encoding`_
 -247 to -256 `Compression Level Pseudo-encoding`_
 -305         `gii Pseudo-encoding`_
@@ -1678,7 +1681,7 @@
 15                          TRLE
 17                          Hitachi ZYWRLE
 -1 to -222                  Tight options
--224 to -238                Tight options
+-225 to -238                Tight options
 -240 to -246                Tight options
 -257 to -272                Anthony Liguori
 -273 to -304                VMWare
@@ -2242,6 +2245,19 @@
 update until a proper update of the framebuffer contents has been
 received.
 
+LastRect Pseudo-encoding
+------------------------
+
+A client which requests the *LastRect* pseudo-encoding is declaring
+that it does not need the exact number of rectangles in a
+*FramebufferUpdate* message. Instead, it will stop parsing when it
+reaches a *LastRect* rectangle. A server may thus start transmitting
+the *FramebufferUpdate* message before it knows exactly how many
+rectangles it is going to transmit, and the server typically advertises
+this situation by saying that it is going to send 65535 rectangles,
+but it then stops with a *LastRect* instead of sending all of them.
+There is no further data associated with the pseudo-rectangle.
+
 Compression Level Pseudo-encoding
 ---------------------------------
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3848
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3848&view=rev
Author:   ossman_
Date:     2009-06-17 09:27:52 +0000 (Wed, 17 Jun 2009)

Log Message:
-----------
Describe the Tight Encoding.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-06-17 09:17:26 UTC (rev 3847)
+++ rfbproto/rfbproto.rst	2009-06-17 09:27:52 UTC (rev 3848)
@@ -745,7 +745,7 @@
 4       "``STDV``"  "``CORRE___``"  `CoRRE Encoding`_
 5       "``STDV``"  "``HEXTILE_``"  `Hextile Encoding`_
 6       "``TRDV``"  "``ZLIB____``"  `ZLib Encoding`_
-7       "``TGHT``"  "``TIGHT___``"  Tight Encoding
+7       "``TGHT``"  "``TIGHT___``"  `Tight Encoding`_
 8       "``TRDV``"  "``ZLIBHEX_``"  `ZLibHex Encoding`_
 -32     "``TGHT``"  "``JPEGQLVL``"  JPEG Quality Level
 -223    "``TGHT``"  "``NEWFBSIZ``"  `DesktopSize Pseudo-encoding`_ (New
@@ -1661,6 +1661,7 @@
 4            `CoRRE Encoding`_
 5            `Hextile Encoding`_
 6            `zlib Encoding`_
+7            `Tight Encoding`_
 8            `zlibhex Encoding`_
 16           `ZRLE Encoding`_
 -223         `DesktopSize Pseudo-encoding`_
@@ -1677,7 +1678,6 @@
 =========================== ===========================================
 Number                      Name
 =========================== ===========================================
-7                           Tight
 15                          TRLE
 17                          Hitachi ZYWRLE
 -1 to -222                  Tight options
@@ -1945,6 +1945,197 @@
 The *zlibData*, when uncompressed, represents a rectangle according to
 the `Raw Encoding`_.
 
+Tight Encoding
+--------------
+
+Tight encoding provides efficient compression for pixel data.
+
+The first byte of each Tight-encoded rectangle is a
+*compression-control* byte:
+
+=============== =================== ===================================
+No. of bytes    Type                Description
+=============== =================== ===================================
+1               ``U8``              *compression-control*
+=============== =================== ===================================
+
+The least significant four bits of *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:
+
+================== ====================================================
+Bit                Description
+================== ====================================================
+0                  if 1: reset stream 0
+1                  if 1: reset stream 1
+2                  if 1: reset stream 2
+3                  if 1: reset stream 3
+================== ====================================================
+
+One of three possible compression methods are supported in the Tight
+encoding. These are **BasicCompression**, **FillCompression** and
+**JpegCompression**. If the bit 7 (the most significant bit) of
+*compression-control* byte is 0, then the compression type is
+**BasicCompression**. In that case, bits 7-4 (the most significant four
+bits) of *compression-control* should be interpreted as follows:
+
+=============== =================== ===================================
+Bits            Binary value        Description
+=============== =================== ===================================
+5-4             00                  *UseStream0*
+..              01                  *UseStream1*
+..              10                  *UseStream2*
+..              11                  *UseStream3*
+6               0                   ---
+..              1                   *ReadFilterId*
+7               0                   **BasicCompression**
+=============== =================== ===================================
+
+Otherwise, if the bit 7 of *compression-control* is set to 1, then the
+compression method is either **FillCompression** or
+**JpegCompression**, depending on other bits of the same byte:
+
+=============== =================== ===================================
+Bits            Binary value        Description
+=============== =================== ===================================
+7-4             1000                **FillCompression**
+..              1001                **JpegCompression**
+..              any other           invalid
+=============== =================== ===================================
+
+Note: **JpegCompression** may only be used when *bits-per-pixel* is
+either 16 or 32.
+
+The data following the *compression-control* byte depends on the
+compression method.
+
+**FillCompression**
+    If the compression type is "fill", then the only pixel value
+    follows, in client pixel format (see [NOTE1]_). This value applies
+    to all pixels of the rectangle.
+
+**JpegCompression**
+    If the compression type is "jpeg", the following data stream looks
+    like this:
+
+    =============== =================== ===============================
+    No. of bytes    Type                Description
+    =============== =================== ===============================
+    1-3                                 *length* in compact
+                                        representation
+    *length*        ``U8`` array        *jpegData*
+    =============== =================== ===============================
+
+    *length* is compactly represented in one, two or three bytes,
+    according to the following scheme:
+
+    =========================== =======================================
+    Value                       Description
+    =========================== =======================================
+    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.
+
+**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:
+
+    =============== ========= ======== ================================
+    No. of bytes    Type      [Value]  Description
+    =============== ========= ======== ================================
+    1               ``U8``             *filter-id*
+    ..                        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 [NOTE1]_) 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 [NOTE1]_).
+
+    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
+    [NOTE2]_).
+
+    If the compression is not used, then the pixel data is sent as is,
+    otherwise the data stream looks like this:
+
+    =============== =================== ===============================
+    No. of bytes    Type                Description
+    =============== =================== ===============================
+    1-3                                 *length* in compact
+                                        representation
+    *length*        ``U8`` array        *zlibData*
+    =============== =================== ===============================
+
+    *length* is compactly represented in one, two or three bytes, just
+    like in the **JpegCompression** method (see above).
+
+..  [NOTE1] 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.
+
+..  [NOTE2] 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".
+
+..  [NOTE3] The "gradient" filter and "jpeg" compression may be used
+    only when bits-per-pixel value is either 16 or 32, not 8.
+
+..  [NOTE4] 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.
+
 zlibhex Encoding
 ----------------
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3849
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3849&view=rev
Author:   ossman_
Date:     2009-06-17 09:30:15 +0000 (Wed, 17 Jun 2009)

Log Message:
-----------
Describe the Tight JPEG Quality Level Pseudo-encoding.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-06-17 09:27:52 UTC (rev 3848)
+++ rfbproto/rfbproto.rst	2009-06-17 09:30:15 UTC (rev 3849)
@@ -747,7 +747,8 @@
 6       "``TRDV``"  "``ZLIB____``"  `ZLib Encoding`_
 7       "``TGHT``"  "``TIGHT___``"  `Tight Encoding`_
 8       "``TRDV``"  "``ZLIBHEX_``"  `ZLibHex Encoding`_
--32     "``TGHT``"  "``JPEGQLVL``"  JPEG Quality Level
+-32     "``TGHT``"  "``JPEGQLVL``"  `JPEG Quality Level
+                                    Pseudo-encoding`_
 -223    "``TGHT``"  "``NEWFBSIZ``"  `DesktopSize Pseudo-encoding`_ (New
                                     FB Size)
 -224    "``TGHT``"  "``LASTRECT``"  `LastRect Pseudo-encoding`_
@@ -1664,6 +1665,7 @@
 7            `Tight Encoding`_
 8            `zlibhex Encoding`_
 16           `ZRLE Encoding`_
+-23 to -32   `JPEG Quality Level Pseudo-encoding`_
 -223         `DesktopSize Pseudo-encoding`_
 -224         `LastRect Pseudo-encoding`_
 -239         `Cursor Pseudo-encoding`_
@@ -1680,7 +1682,8 @@
 =========================== ===========================================
 15                          TRLE
 17                          Hitachi ZYWRLE
--1 to -222                  Tight options
+-1 to -22                   Tight options
+-33 to -222                 Tight options
 -225 to -238                Tight options
 -240 to -246                Tight options
 -257 to -272                Anthony Liguori
@@ -2340,6 +2343,21 @@
 Pseudo-encodings
 ++++++++++++++++
 
+JPEG Quality Level Pseudo-encoding
+----------------------------------
+
+Specifies the desired quality from the JPEG encoder. Encoding number
+-23 implies high JPEG quality and -32 implies low JPEG quality. Low
+quality can be useful in low bandwidth situations. If the JPEG quality
+level is not specified, **JpegCompression** is not used in the `Tight
+Encoding`_.
+
+The quality level concerns lossy compression and hence the setting is a
+tradeoff between image quality and bandwidth. The specification defines
+neither what bandwidth is required at a certain quality level nor what
+image quality you can expect. The quality level is also just a hint to
+the server.
+
 Cursor Pseudo-encoding
 -----------------------
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3850
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3850&view=rev
Author:   ossman_
Date:     2009-06-17 09:45:44 +0000 (Wed, 17 Jun 2009)

Log Message:
-----------
Update Tight Encoding description to match guidelines.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-06-17 09:30:15 UTC (rev 3849)
+++ rfbproto/rfbproto.rst	2009-06-17 09:45:44 UTC (rev 3850)
@@ -1951,7 +1951,11 @@
 Tight Encoding
 --------------
 
-Tight encoding provides efficient compression for pixel data.
+Tight encoding provides efficient compression for pixel data. To
+reduce implementation complexity, the width of any Tight-encoded
+rectangle cannot exceed 2048 pixels. If a wider rectangle is desired,
+it must be split into several rectangles and each one should be encoded
+separately.
 
 The first byte of each Tight-encoded rectangle is a
 *compression-control* byte:
@@ -1962,23 +1966,23 @@
 1               ``U8``              *compression-control*
 =============== =================== ===================================
 
-The least significant four bits of *compression-control* byte inform
-the client which zlib compression streams should be reset before
+The least significant four bits of the *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:
 
 ================== ====================================================
 Bit                Description
 ================== ====================================================
-0                  if 1: reset stream 0
-1                  if 1: reset stream 1
-2                  if 1: reset stream 2
-3                  if 1: reset stream 3
+0                  Reset stream 0
+1                  Reset stream 1
+2                  Reset stream 2
+3                  Reset stream 3
 ================== ====================================================
 
 One of three possible compression methods are supported in the Tight
 encoding. These are **BasicCompression**, **FillCompression** and
-**JpegCompression**. If the bit 7 (the most significant bit) of
+**JpegCompression**. If the bit 7 (the most significant bit) of the
 *compression-control* byte is 0, then the compression type is
 **BasicCompression**. In that case, bits 7-4 (the most significant four
 bits) of *compression-control* should be interpreted as follows:
@@ -1986,12 +1990,12 @@
 =============== =================== ===================================
 Bits            Binary value        Description
 =============== =================== ===================================
-5-4             00                  *UseStream0*
-..              01                  *UseStream1*
-..              10                  *UseStream2*
-..              11                  *UseStream3*
+5-4             00                  Use stream 0
+..              01                  Use stream 1
+..              10                  Use stream 2
+..              11                  Use stream 3
 6               0                   ---
-..              1                   *ReadFilterId*
+..              1                   *read-filter-id*
 7               0                   **BasicCompression**
 =============== =================== ===================================
 
@@ -2004,31 +2008,40 @@
 =============== =================== ===================================
 7-4             1000                **FillCompression**
 ..              1001                **JpegCompression**
-..              any other           invalid
+..              any other           Invalid
 =============== =================== ===================================
 
 Note: **JpegCompression** may only be used when *bits-per-pixel* is
-either 16 or 32.
+either 16 or 32 and the client has advertized a quality level using the
+`JPEG Quality Level Pseudo-encoding`_.
 
+The Tight encoding makes use of a new type ``TPIXEL`` (Tight pixel).
+This is the same as a ``PIXEL`` for the agreed pixel format, except
+where *true-colour-flag* is non-zero, *bits-per-pixel* is 32, *depth*
+is 24 and all of the bits making up the red, green and blue intensities
+are exactly 8 bits wide. In this case a ``TPIXEL`` is only 3 bytes
+long, where the first byte is the red component, the second byte is the
+green component, and the third byte is the blue component of the pixel
+color value.
+
 The data following the *compression-control* byte depends on the
 compression method.
 
 **FillCompression**
-    If the compression type is "fill", then the only pixel value
-    follows, in client pixel format (see [NOTE1]_). This value applies
-    to all pixels of the rectangle.
+    If the compression type is **FillCompression**, then the only pixel
+    value follows, in ``TPIXEL`` format. This value applies to all
+    pixels of the rectangle.
 
 **JpegCompression**
-    If the compression type is "jpeg", the following data stream looks
-    like this:
+    If the compression type is **JpegCompression**, the following data
+    stream looks like this:
 
-    =============== =================== ===============================
-    No. of bytes    Type                Description
-    =============== =================== ===============================
-    1-3                                 *length* in compact
-                                        representation
-    *length*        ``U8`` array        *jpegData*
-    =============== =================== ===============================
+    =============== ================ ==================================
+    No. of bytes    Type             Description
+    =============== ================ ==================================
+    1-3                              *length* in compact representation
+    *length*        ``U8`` array     *jpeg-data*
+    =============== ================ ==================================
 
     *length* is compactly represented in one, two or three bytes,
     according to the following scheme:
@@ -2047,98 +2060,96 @@
     example, decimal value 10000 should be represented as two bytes:
     binary 10010000 01001110, or hexadecimal 90 4E.
 
+    The *jpeg-data* is a JFIF stream.
+
 **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:
+    If the compression type is **BasicCompression** and bit 6 (the
+    *read-filter-id* bit) 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:
 
     =============== ========= ======== ================================
     No. of bytes    Type      [Value]  Description
     =============== ========= ======== ================================
     1               ``U8``             *filter-id*
-    ..                        0        **no filter** ("copy" filter)
-    ..                        1        **palette filter**
-    ..                        2        **gradient filter**
+    ..                        0        **CopyFilter** (no filter)
+    ..                        1        **PaletteFilter**
+    ..                        2        **GradientFilter**
     =============== ========= ======== ================================
 
-    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 [NOTE1]_) will be compressed. See
-    below details on the compression.
+    If bit 6 of the *compression-control* byte is set to 0 (no
+    *filter-id* byte), then the **CopyFilter** is used.
 
-    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:
+    **CopyFilter**
+        When the **CopyFilter** is active, raw pixel values in
+        ``TPIXEL`` format will be compressed. See below for details on
+        the compression.
 
-    ::
+    **PaletteFilter**
+        The **PaletteFilter** 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 are used to encode one pixel. 1-bit encoding
+        is performed such way that the most significant bits correspond
+        to the leftmost pixels, and each row of pixels is aligned to
+        the byte boundary. When the **PaletteFilter** 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 ``TPIXEL`` format.
 
-        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];
+    **GradientFilter**
+        The **GradientFilter** 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 follows::
 
-    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.
+            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];
 
-    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 [NOTE1]_).
+        Here ``V[i,j]`` is the intensity of a color component for a
+        pixel at coordinates ``(i,j)``. For pixels outside the current
+        rectangle, ``V[i,j]`` is assumed to be zero (which is relevant
+        for ``P[i,0]`` and ``P[0,j]``). MAX is the maximum intensity
+        value for a color component.
 
-    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
-    [NOTE2]_).
+        Note: The **GradientFilter** may only be used when
+        *bits-per-pixel* is either 16 or 32.
 
+    After the pixel data has been filtered with one of the above three
+    filters, it 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
+    [NOTE1]_).
+
     If the compression is not used, then the pixel data is sent as is,
     otherwise the data stream looks like this:
 
-    =============== =================== ===============================
-    No. of bytes    Type                Description
-    =============== =================== ===============================
-    1-3                                 *length* in compact
-                                        representation
-    *length*        ``U8`` array        *zlibData*
-    =============== =================== ===============================
+    =============== ================ ==================================
+    No. of bytes    Type             Description
+    =============== ================ ==================================
+    1-3                              *length* in compact representation
+    *length*        ``U8`` array     *zlibData*
+    =============== ================ ==================================
 
     *length* is compactly represented in one, two or three bytes, just
     like in the **JpegCompression** method (see above).
 
-..  [NOTE1] 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.
+..  [NOTE1] The decoder must reset the zlib streams before decoding the
+    rectangle, if some of the bits 0, 1, 2 and 3 in the
+    *compression-control* byte are set to 1. Note that the decoder must
+    reset the indicated zlib streams even if the compression type is
+    **FillCompression** or **JpegCompression**.
 
-..  [NOTE2] 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".
-
-..  [NOTE3] The "gradient" filter and "jpeg" compression may be used
-    only when bits-per-pixel value is either 16 or 32, not 8.
-
-..  [NOTE4] 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.
-
 zlibhex Encoding
 ----------------
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3852
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3852&view=rev
Author:   ossman_
Date:     2009-06-18 09:18:39 +0000 (Thu, 18 Jun 2009)

Log Message:
-----------
Describe the DesktopName pseudo-encoding

Description derived from a message on the vnc-list:
http://www.realvnc.com/pipermail/vnc-list/2008-January/058496.html

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-06-17 11:53:56 UTC (rev 3851)
+++ rfbproto/rfbproto.rst	2009-06-18 09:18:39 UTC (rev 3852)
@@ -1671,6 +1671,7 @@
 -239         `Cursor Pseudo-encoding`_
 -247 to -256 `Compression Level Pseudo-encoding`_
 -305         `gii Pseudo-encoding`_
+-307         `DesktopName Pseudo-encoding`_
 -308         `ExtendedDesktopSize Pseudo-encoding`_
 -309         `xvp Pseudo-encoding`_
 ============ ==========================================================
@@ -1689,7 +1690,6 @@
 -257 to -272                Anthony Liguori
 -273 to -304                VMWare
 -306                        popa
--307                        Peter Astrand DesktopName
 0x574d5600 to 0x574d56ff    VMWare
 =========================== ===========================================
 
@@ -2510,6 +2510,25 @@
 mouse movements, mouses with more than 8 buttons and mouses with more
 than three axes. It even supports joysticks and gamepads.
 
+DesktopName Pseudo-encoding
+---------------------------
+
+A client which requests the DesktopName pseudo-encoding is declaring
+that it is capable of coping with a change of the desktop name. The
+server changes the desktop name by sending a pseudo-rectangle with the
+DesktopName pseudo-encoding in an update. The pseudo-rectangle's
+x-position, y-position, width, and height must be zero. After the
+rectangle header, a string with the new name follows.
+
+=============== =================== ===================================
+No. of bytes    Type                Description
+=============== =================== ===================================
+4               ``U32``             *name-length*
+*name-length*   ``U8`` array        *name-string*
+=============== =================== ===================================
+
+The text encoding used for *name-string* is UTF-8.
+
 ExtendedDesktopSize Pseudo-encoding
 -----------------------------------
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3896
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3896&view=rev
Author:   ossman_
Date:     2009-09-07 09:51:11 +0000 (Mon, 07 Sep 2009)

Log Message:
-----------
Specify UTF-8 for strings

Steer things towards UTF-8, whilst also adding a notice that
historically there has been a lot of different encodings in use.

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-09-04 13:19:19 UTC (rev 3895)
+++ rfbproto/rfbproto.rst	2009-09-07 09:51:11 UTC (rev 3896)
@@ -201,6 +201,34 @@
 security types do not clash. Please see the RealVNC website at
 http://www.realvnc.com for details of how to contact them.
 
+String Encodings
+================
+
+The encoding used for strings in the protocol has historically often
+been unspecified, or has changed between versions of the protocol. As a
+result, there are a lot of implementations which use different,
+incompatible encodings. Commonly those encodings have been ISO 8859-1
+(also known as Latin-1) or Windows code pages.
+
+It is strongly recommended that new implementations use the UTF-8
+encoding for these strings. This allows full unicode support, yet
+retains good compatibility with older RFB implementations.
+
+New protocol additions that do not have a legacy problem should mandate
+the UTF-8 encoding to provide full character support and to avoid any
+issues with ambiguity.
+
+All clients and servers should be prepared to receive invalid UTF-8
+sequences at all times. These can occur as a result of historical
+ambiguity or because of bugs. Neither case should result in lost
+protocol synchronization.
+
+Handling an invalid UTF-8 sequence is largely dependent on the role
+that string plays. Modifying the string should only be done when the
+string is only used in the user interface. It should be obvious in that
+case that the string has been modified, e.g. by appending a notice to
+the string.
+
 Protocol Messages
 =================
 
@@ -614,8 +642,12 @@
 *name-length*   ``U8`` array        *name-string*
 =============== =================== ===================================
 
-where ``PIXEL_FORMAT`` is
+The text encoding used for *name-string* is historically undefined but
+it is strongly recommended to use UTF-8 (see `String Encodings`_ for
+more details).
 
+``PIXEL_FORMAT`` is defined as:
+
 =============== =================== ===================================
 No. of bytes    Type                Description
 =============== =================== ===================================


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3914
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3914&view=rev
Author:   ossman_
Date:     2009-10-21 09:17:58 +0000 (Wed, 21 Oct 2009)

Log Message:
-----------
Align ServerInit table.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-10-12 15:54:59 UTC (rev 3913)
+++ rfbproto/rfbproto.rst	2009-10-21 09:17:58 UTC (rev 3914)
@@ -637,7 +637,7 @@
 =============== =================== ===================================
 2               ``U16``             *framebuffer-width*
 2               ``U16``             *framebuffer-height*
-16               ``PIXEL_FORMAT``   *server-pixel-format*
+16              ``PIXEL_FORMAT``    *server-pixel-format*
 4               ``U32``             *name-length*
 *name-length*   ``U8`` array        *name-string*
 =============== =================== ===================================


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3915
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3915&view=rev
Author:   ossman_
Date:     2009-10-21 11:54:53 +0000 (Wed, 21 Oct 2009)

Log Message:
-----------
Add new protocol numbers (MD5 auth and TurboVNC pseudo-encodings)

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-10-21 09:17:58 UTC (rev 3914)
+++ rfbproto/rfbproto.rst	2009-10-21 11:54:53 UTC (rev 3915)
@@ -386,6 +386,7 @@
 18          TLS
 19          VeNCrypt
 20          SASL
+21          MD5 hash authentication
 =========== ===========================================================
 
 Once the *security-type* has been decided, data specific to that
@@ -1722,6 +1723,8 @@
 -257 to -272                Anthony Liguori
 -273 to -304                VMWare
 -306                        popa
+-412 to -512                TurboVNC fine-grained quality level
+-763 to -768                TurboVNC subsampling level
 0x574d5600 to 0x574d56ff    VMWare
 =========================== ===========================================
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 3916
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=3916&view=rev
Author:   ossman_
Date:     2009-10-21 11:57:35 +0000 (Wed, 21 Oct 2009)

Log Message:
-----------
Describe lifetime rules of the Hextile fg and bg colors.

Signed-off-by: Peter Rosin <peda@...>
Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2009-10-21 11:54:53 UTC (rev 3915)
+++ rfbproto/rfbproto.rst	2009-10-21 11:57:35 UTC (rev 3916)
@@ -1866,13 +1866,19 @@
 in the final row will also be smaller.
 
 Each tile is either encoded as raw pixel data, or as a variation on
-RRE. Each tile has a background pixel value, as before. However, the
-background pixel value does not need to be explicitly specified for a
-given tile if it is the same as the background of the previous tile. If
-all of the subrectangles of a tile have the same pixel value, this can
-be specified once as a foreground pixel value for the whole tile. As
-with the background, the foreground pixel value can be left
-unspecified, meaning it is carried over from the previous tile.
+RRE. Each tile has a background pixel value, as before. The background
+pixel value does not need to be explicitly specified for a given tile
+if it is the same as the background of the previous tile. However the
+background pixel value may not be carried over if the previous tile was
+raw. If all of the subrectangles of a tile have the same pixel value,
+this can be specified once as a foreground pixel value for the whole
+tile. As with the background, the foreground pixel value can be left
+unspecified, meaning it is carried over from the previous tile. The
+foreground pixel value may not be carried over if the previous tile was
+raw or had the SubrectsColored bit set. It may, however, be carried
+over from a previous tile with the AnySubrects bit clear, as long as
+that tile itself carried over a valid foreground from its previous
+tile.
 
 So the data consists of each tile encoded in order. Each tile begins
 with a subencoding type byte, which is a mask made up of a number of


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4429
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4429&view=rev
Author:   ossman_
Date:     2011-05-19 09:35:36 +0000 (Thu, 19 May 2011)

Log Message:
-----------
QEMU protocol extensions

Document three QEMU protocol extensions:

 - Pointer motion mode: Allows switching between relative & absolute
   motion events
 - Extended key event: Allows providing the hardware keycode alongside
   the X11 keysym in key events
 - Audio: Allows client to receive the audio stream associated with
   the virtual desktop.

Documentation provided by Daniel P. Berrange.

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-05-17 21:30:11 UTC (rev 4428)
+++ rfbproto/rfbproto.rst	2011-05-19 09:35:36 UTC (rev 4429)
@@ -818,7 +818,7 @@
 =========== ===========================================================
 Number      Name
 =========== ===========================================================
-255         Anthony Liguori
+255         `QEMU Client Message`_
 254, 127    VMWare
 253         `gii Client Message`_
 252         tight
@@ -1099,6 +1099,10 @@
 2               ``U16``                         *y-position*
 =============== ==================== ========== =======================
 
+The `QEMU Pointer Motion Change Psuedo-encoding`_ allows for the
+negotiation of an alternative interpretation for the *x-position*
+and *y-position* fields, as relative deltas.
+
 ClientCutText
 -------------
 
@@ -1469,6 +1473,151 @@
 established that the server supports this extension, by requesting the
 `xvp Pseudo-encoding`_.
 
+QEMU Client Message
+-------------------
+
+This message may only be sent if the client has previously received
+a *FrameBufferUpdate* that confirms support for the intended
+*submessage-type*. Every ``QEMU Client Message`` begins with
+a standard header
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               255        *message-type*
+1               ``U8``                          *submessage-type*
+=============== ==================== ========== =======================
+
+This header is then followed by arbitrary data whose format is
+determined by the *submessage-type*. Possible values for
+*submessage-type* and their associated psuedo encodings are
+
+================ ================ ====================
+Submessage Type  Psuedo Encoding  Description
+================ ================ ====================
+0                -258             Extended key events
+1                -259             Audio
+================ ================ ====================
+
+QEMU Extended Key Event Message
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This submessage allows the client to send an extended key event
+containing a keycode, in addition to a keysym. The advantage of
+providing the keycode is that it enables the server to interpret
+the key event independantly of the clients' locale specific
+keymap. This can be important for virtual desktops whose key
+input device requires scancodes, for example, virtual machines
+emulating a PS/2 keycode. Prior to this extension, RFB servers
+for such virtualization software would have to be configured
+with a keymap matching the client. With this extension it is
+sufficient for the guest operating system to be configured with
+the matching keymap. The VNC server is keymap independant.
+
+The full message is:
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               255        *message-type*
+1               ``U8``               0          *submessage-type*
+2               ``U16``                         *down-flag*
+4               ``U32``                         *keysym*
+4               ``U32``                         *keycode*
+=============== ==================== ========== =======================
+
+The *keysym* and *down-flag* fields also take the same values as
+described for the `KeyEvent`_ message. Auto repeating behaviour
+of keys is also as described for the `KeyEvent`_ message.
+
+The *keycode* is the XT keycode that produced the *keysym*. An
+XT keycode is an XT make scancode sequence encoded to fit in
+a single ``U32`` quantity. Single byte XT scancodes with a byte
+value less than 0x7f are encoded as is. 2-byte XT scancodes
+whose first byte is 0xe0 and second byte is less than 0x7f are
+encoded with the high bit of the first byte set. Some example
+mappings are
+
+============= ================== ============ ==========
+XT scancode   X11 keysym         RFB keycode  down-flag
+============= ================== ============ ==========
+0x1e          XK_A (0x41)        0x1e         1
+0x9e          XK_A (0x41)        0x1e         0
+0xe0 0x4d     XK_Right (0xff53)  0xcd         1
+0xe0 0xcd     XK_Right (0xff53)  0xcd         0
+============= ================== ============ ==========
+
+
+QEMU Audio Client Message
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This submessage allows the client to control how the audio data
+stream is received. There are three operations that can be invoked
+with this submessage, the payload varies according to which
+operation is requested.
+
+The first operation enables audio capture from the server:
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               255        *message-type*
+1               ``U8``               1          *submessage-type*
+2               ``U16``              0          *operation*
+=============== ==================== ========== =======================
+
+After invoking this operation, the client will receive a
+`QEMU Audio Server Message`_ when an audio stream begins.
+
+The second operation is the inverse, to disable audio capture
+on the server:
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               255        *message-type*
+1               ``U8``               1          *submessage-type*
+2               ``U16``              1          *operation*
+=============== ==================== ========== =======================
+
+Due to inherant race conditions in the protocol, after invoking this
+operation, the client may still receive further
+`QEMU Audio Server Message`_ messages for a short time.
+
+The third and final operation is to set the audio sample format.
+This should be set before audio capture is enabled on the server,
+otherwise the client will not be able to reliably interpret the
+receiving audio buffers:
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               255        *message-type*
+1               ``U8``               1          *submessage-type*
+2               ``U16``              2          *operation*
+1               ``U8``                          *sample-format*
+1               ``U8``                          *nchannels*
+4               ``U32``                         *frequency*
+=============== ==================== ========== =======================
+
+The *sample-format* field must take one of the following values,
+and this describes the number of bytes that each sample will
+consume:
+
+====== ============= =======
+Value  No. of bytes  Type
+====== ============= =======
+0      1             ``U8``
+1      1             ``S8``
+2      2             ``U16``
+3      2             ``S16``
+4      4             ``U32``
+5      4             ``S32``
+====== ============= =======
+
+The *nchannels* field must be either ``1`` (mono) or ``2`` (stereo).
+
+
 Server to Client Messages
 +++++++++++++++++++++++++
 
@@ -1488,7 +1637,7 @@
 =========== ===========================================================
 Number      Name
 =========== ===========================================================
-255         Anthony Liguori
+255         QEMU
 254, 127    VMWare
 253         `gii Server Message`_
 252         tight
@@ -1681,6 +1830,80 @@
 by sending a message with an XVP_FAIL *xvp-message-code*, and the same
 *xvp-extension-version* as included in the client's operation request.
 
+QEMU Server Message
+-------------------
+
+This message may only be sent if the client has previously received
+a *FrameBufferUpdate* that confirms support for the intended
+*submessage-type*. Every ``QEMU Server Message`` begins with
+a standard header
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               255        *message-type*
+1               ``U8``                          *submessage-type*
+=============== ==================== ========== =======================
+
+This header is then followed by arbitrary data whose format is
+determined by the *submessage-type*. Possible values for
+*submessage-type* and their associated psuedo encodings are
+
+================ ================ ====================
+Submessage Type  Psuedo Encoding  Description
+================ ================ ====================
+1                -259             Audio
+================ ================ ====================
+
+Submessage type 0 is unused, since the
+`QEMU Extended Key Event Psuedo-encoding`_ does not require any
+server messages.
+
+QEMU Audio Server Message
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+This submessage allows the server to send an audio data stream
+to the client. There are three operations that can be invoked
+with this submessage, the payload varies according to which
+operation is requested.
+
+The first operation informs the client that an audio stream is
+about to start
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               255        *message-type*
+1               ``U8``               1          *submessage-type*
+2               ``U16``              1          *operation*
+=============== ==================== ========== =======================
+
+The second operation informs the client that an audio stream has
+now finished:
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               255        *message-type*
+1               ``U8``               1          *submessage-type*
+2               ``U16``              0          *operation*
+=============== ==================== ========== =======================
+
+The third and final operation is to provide audio data.
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               255        *message-type*
+1               ``U8``               1          *submessage-type*
+2               ``U16``              2          *operation*
+4               ``U32``                         *data-length*
+*data-length*   ``U8`` array                    *data*
+=============== ==================== ========== =======================
+
+The *data-length* will be a multiple of (*sample-format* * *nchannels*)
+as requested by the client in an earlier `QEMU Audio Client Message`_.
+
 Encodings
 +++++++++
 
@@ -1703,6 +1926,9 @@
 -224         `LastRect Pseudo-encoding`_
 -239         `Cursor Pseudo-encoding`_
 -247 to -256 `Compression Level Pseudo-encoding`_
+-257         `QEMU Pointer Motion Change Psuedo-encoding`_
+-258         `QEMU Extended Key Event Psuedo-encoding`_
+-259         `QEMU Audio Psuedo-encoding`_
 -305         `gii Pseudo-encoding`_
 -307         `DesktopName Pseudo-encoding`_
 -308         `ExtendedDesktopSize Pseudo-encoding`_
@@ -1720,7 +1946,7 @@
 -33 to -222                 Tight options
 -225 to -238                Tight options
 -240 to -246                Tight options
--257 to -272                Anthony Liguori
+-260 to -272                QEMU
 -273 to -304                VMWare
 -306                        popa
 -412 to -512                TurboVNC fine-grained quality level
@@ -2535,6 +2761,67 @@
 just a hint for the server, and there is no specification for what a
 specific compression level means.
 
+QEMU Pointer Motion Change Psuedo-encoding
+------------------------------------------
+
+A client that supports this encoding declares that is able to send
+pointer motion events either as absolute coordinates, or relative
+deltas. The server can switch between different pointer motion modes
+by sending a `FrameBufferUpdate`_ message. If the *x-position* in
+the update is 1, the server is requesting absolute coordinates, which
+is the RFB protocol default when this encoding is not supported. If
+the *x-position* in the update is 0, the server is requesting relative
+deltas.
+
+When relative delta mode is active, the semantics of the
+`PointerEvent`_ message are changed. The *x-position* and *y-position*
+fields are to be treated as ``S16`` quantities, denoting the delta
+from the last position. A client can compute the signed deltas with
+the logic::
+
+  uint16 dx = x + 0x7FFF - last_x
+  uint16 dy = y + 0x7FFF - last_y
+
+If the client needs to send an updated *button-mask* without
+any associated motion, it should use the value 0x7FFF in the
+*x-position* and *y-position* fields of the `PointerEvent`_
+
+Servers are advised to implement this psuedo-encoding if the virtual
+desktop is associated a input device that expects relative coordinates,
+for example, a virtual machine with a PS/2 mouse. Prior to this
+extension, a server with such a input device would have to perform the
+absolute to relative delta conversion itself. This can result in the
+client pointer hitting an "invisible wall".
+
+Clients are advised that when generating events in relative pointer
+mode, they should grab and hide the local pointer. When the local
+pointer hits any edge of the client window, it should be warped
+back by 100 pixels. This ensures that continued movement of the
+user's input device will continue to generate relative deltas and
+thus avoid the "invisible wall" problem.
+
+QEMU Extended Key Event Psuedo-encoding
+---------------------------------------
+
+A client that supports this encoding is indicating that it is able
+to provide raw keycodes as an alternative to keysyms. If a server
+wishes to receive raw keycodes it will send a `FrameBufferUpdate`_
+with the matching psuedo-encoding and the *num-rectanges* field
+set to 1, however, no rectanges will actually be sent. After receiving
+this notification, clients may optionally use the
+`QEMU Extended Key Event Message`_ to send key events, in preference
+to the traditional `KeyEvent`_ message.
+
+QEMU Audio Psuedo-encoding
+--------------------------
+
+A client that supports this encoding is indicating that it is able
+to receive an audio data stream. If a server wishes to send audio
+data it will send a `FrameBufferUpdate`_ with the matching
+psuedo-encoding and the *num-rectangles* field set to 1, however, no
+rectangles will actually be sent. After receiving this notification,
+clients may optionally use the `QEMU Audio Client Message`_.
+
 gii Pseudo-encoding
 -------------------
 


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4673
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4673&view=rev
Author:   dcommander
Date:     2011-09-14 17:59:18 +0000 (Wed, 14 Sep 2011)
Log Message:
-----------
Document TurboVNC pseudo-encodings

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-09-14 17:08:29 UTC (rev 4672)
+++ rfbproto/rfbproto.rst	2011-09-14 17:59:18 UTC (rev 4673)
@@ -792,6 +792,10 @@
 -256    "``TGHT``"  "``COMPRLVL``"  `Compression Level
                                     Pseudo-encoding`_
 -305    "``GGI_``"  "``GII_____``"  `gii Pseudo-encoding`_
+-512    "``TRBO``"  "``FINEQLVL``"  `TurboVNC Fine-Grained Quality Level
+                                    Pseudo-encoding`_
+-768    "``TRBO``"  "``SSAMPLVL``"  `TurboVNC Subsampling Level
+                                    Pseudo-encoding`_
 ======= =========== =============== ===================================
 
 Note that the server need not (but it may) list the "``RAW_____``"
@@ -1933,6 +1937,8 @@
 -307         `DesktopName Pseudo-encoding`_
 -308         `ExtendedDesktopSize Pseudo-encoding`_
 -309         `xvp Pseudo-encoding`_
+-412 to -512 `TurboVNC Fine-Grained Quality Level Pseudo-encoding`_
+-763 to -768 `TurboVNC Subsampling Level Pseudo-encoding`_
 ============ ==========================================================
 
 Other registered encodings are:
@@ -2636,6 +2642,59 @@
 image quality you can expect. The quality level is also just a hint to
 the server.
 
+TurboVNC Fine-Grained Quality Level Pseudo-encoding
+---------------------------------------------------
+
+The TurboVNC Fine-Grained Quality Level pseudo-encoding allows the image
+quality to be specified on a 0 to 100 scale, with -512 corresponding to image
+quality 0 and -412 corresponding to image quality 100.  This pseudo-encoding
+was originally intended for use with JPEG-encoded subrectangles, but it could
+be used with other types of image encoding as well.
+
+TurboVNC Subsampling Level Pseudo-Encoding
+------------------------------------------
+
+The TurboVNC Subsampling Level pseudo-encoding allows the level of chrominance
+subsampling to be specified.  When a JPEG image is encoded, the RGB pixels are
+first converted to YCbCr, a colorspace in which brightness (luminance) is
+separated from color (chrominance.)  Since the human eye is more sensitive to
+spatial changes in brightness than to spatial changes in color, the chrominance
+components (Cb, Cr) can be subsampled to save bandwidth without losing much
+image quality (on smooth images, such as photographs, chrominance subsampling
+is often not distinguishable by the human eye.)  Subsampling can be implemented
+either by averaging together groups of chrominance components or by simply
+picking one component from the group and discarding the rest.
+
+The values for this pseudo-encoding are defined as follows:
+
+-768 = 1X chrominance subsampling (no chrominance subsampling).
+       Chrominance components are sent for every pixel in the source image.
+
+-767 = 4X chrominance subsampling.  Chrominance components are sent for every
+       fourth pixel in the source image.  This would typically be implemented
+       using 4:2:0 subsampling (2X subsampling in both X and Y directions), but
+       it could also be implemented using 4:1:1 subsampling (4X subsampling in
+       the X direction.)
+
+-766 = 2X chrominance subsampling.  Chrominance components are sent for every
+       other pixel in the source image.  This would typically be implemented
+       using 4:2:2 subsampling (2X subsampling in the X direction.)
+
+-765 = Grayscale.  All chrominance components in the source image are
+       discarded.
+
+-764 = 8X chrominance subsampling.  Chrominance components are sent for every
+       8th pixel in the source image.  This would typically be implemented
+       using 4:1:0 subsampling (4X subsampling in the X direction and 2X
+       subsampling in the Y direction.)
+
+-763 = 16X chrominance subsampling.  Chrominance components are sent for every
+       16th pixel in the source image.  This would typically be implemented
+       using 4X subsampling in both X and Y directions.
+
+This pseudo-encoding was originally intended for use with JPEG-encoded
+subrectangles, but it could be used with other types of image encoding as well.
+
 Cursor Pseudo-encoding
 -----------------------
 

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4738
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4738&view=rev
Author:   ossman_
Date:     2011-10-27 12:07:05 +0000 (Thu, 27 Oct 2011)
Log Message:
-----------
Horizontal mouse wheel

As RFB vertical wheel events are based on X11's way of representing
these as buttons 4 and 5, it's only natural to extend button 6 and 7 to
represent horizontal wheel events. This behaviour is what is seen on
modern X servers.

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-10-25 15:20:05 UTC (rev 4737)
+++ rfbproto/rfbproto.rst	2011-10-27 12:07:05 UTC (rev 4738)
@@ -1090,9 +1090,9 @@
 
 On a conventional mouse, buttons 1, 2 and 3 correspond to the left,
 middle and right buttons on the mouse. On a wheel mouse, each step of
-the wheel upwards is represented by a press and release of button 4,
-and each step downwards is represented by a press and release of
-button 5.
+the wheel is represented by a press and release of a certain button.
+Button 4 means up, button 5 means down, button 6 means left and
+button 7 means right.
 
 =============== ==================== ========== =======================
 No. of bytes    Type                 [Value]    Description

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4739
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4739&view=rev
Author:   ossman_
Date:     2011-10-27 12:12:32 +0000 (Thu, 27 Oct 2011)
Log Message:
-----------
Use a more generic name for these encodings as they have a broad (possible) use.

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-10-27 12:07:05 UTC (rev 4738)
+++ rfbproto/rfbproto.rst	2011-10-27 12:12:32 UTC (rev 4739)
@@ -792,9 +792,9 @@
 -256    "``TGHT``"  "``COMPRLVL``"  `Compression Level
                                     Pseudo-encoding`_
 -305    "``GGI_``"  "``GII_____``"  `gii Pseudo-encoding`_
--512    "``TRBO``"  "``FINEQLVL``"  `TurboVNC Fine-Grained Quality Level
+-512    "``TRBO``"  "``FINEQLVL``"  `JPEG Fine-Grained Quality Level
                                     Pseudo-encoding`_
--768    "``TRBO``"  "``SSAMPLVL``"  `TurboVNC Subsampling Level
+-768    "``TRBO``"  "``SSAMPLVL``"  `JPEG Subsampling Level
                                     Pseudo-encoding`_
 ======= =========== =============== ===================================
 
@@ -1937,8 +1937,8 @@
 -307         `DesktopName Pseudo-encoding`_
 -308         `ExtendedDesktopSize Pseudo-encoding`_
 -309         `xvp Pseudo-encoding`_
--412 to -512 `TurboVNC Fine-Grained Quality Level Pseudo-encoding`_
--763 to -768 `TurboVNC Subsampling Level Pseudo-encoding`_
+-412 to -512 `JPEG Fine-Grained Quality Level Pseudo-encoding`_
+-763 to -768 `JPEG Subsampling Level Pseudo-encoding`_
 ============ ==========================================================
 
 Other registered encodings are:
@@ -2642,19 +2642,19 @@
 image quality you can expect. The quality level is also just a hint to
 the server.
 
-TurboVNC Fine-Grained Quality Level Pseudo-encoding
----------------------------------------------------
+JPEG Fine-Grained Quality Level Pseudo-encoding
+-----------------------------------------------
 
-The TurboVNC Fine-Grained Quality Level pseudo-encoding allows the image
+The JPEG Fine-Grained Quality Level pseudo-encoding allows the image
 quality to be specified on a 0 to 100 scale, with -512 corresponding to image
 quality 0 and -412 corresponding to image quality 100.  This pseudo-encoding
 was originally intended for use with JPEG-encoded subrectangles, but it could
 be used with other types of image encoding as well.
 
-TurboVNC Subsampling Level Pseudo-Encoding
-------------------------------------------
+JPEG Subsampling Level Pseudo-Encoding
+--------------------------------------
 
-The TurboVNC Subsampling Level pseudo-encoding allows the level of chrominance
+The JPEG Subsampling Level pseudo-encoding allows the level of chrominance
 subsampling to be specified.  When a JPEG image is encoded, the RGB pixels are
 first converted to YCbCr, a colorspace in which brightness (luminance) is
 separated from color (chrominance.)  Since the human eye is more sensitive to

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4740
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4740&view=rev
Author:   ossman_
Date:     2011-10-27 12:14:56 +0000 (Thu, 27 Oct 2011)
Log Message:
-----------
Sort the encoding descriptions so they match the allocation tables.

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-10-27 12:12:32 UTC (rev 4739)
+++ rfbproto/rfbproto.rst	2011-10-27 12:14:56 UTC (rev 4740)
@@ -2642,59 +2642,6 @@
 image quality you can expect. The quality level is also just a hint to
 the server.
 
-JPEG Fine-Grained Quality Level Pseudo-encoding
------------------------------------------------
-
-The JPEG Fine-Grained Quality Level pseudo-encoding allows the image
-quality to be specified on a 0 to 100 scale, with -512 corresponding to image
-quality 0 and -412 corresponding to image quality 100.  This pseudo-encoding
-was originally intended for use with JPEG-encoded subrectangles, but it could
-be used with other types of image encoding as well.
-
-JPEG Subsampling Level Pseudo-Encoding
---------------------------------------
-
-The JPEG Subsampling Level pseudo-encoding allows the level of chrominance
-subsampling to be specified.  When a JPEG image is encoded, the RGB pixels are
-first converted to YCbCr, a colorspace in which brightness (luminance) is
-separated from color (chrominance.)  Since the human eye is more sensitive to
-spatial changes in brightness than to spatial changes in color, the chrominance
-components (Cb, Cr) can be subsampled to save bandwidth without losing much
-image quality (on smooth images, such as photographs, chrominance subsampling
-is often not distinguishable by the human eye.)  Subsampling can be implemented
-either by averaging together groups of chrominance components or by simply
-picking one component from the group and discarding the rest.
-
-The values for this pseudo-encoding are defined as follows:
-
--768 = 1X chrominance subsampling (no chrominance subsampling).
-       Chrominance components are sent for every pixel in the source image.
-
--767 = 4X chrominance subsampling.  Chrominance components are sent for every
-       fourth pixel in the source image.  This would typically be implemented
-       using 4:2:0 subsampling (2X subsampling in both X and Y directions), but
-       it could also be implemented using 4:1:1 subsampling (4X subsampling in
-       the X direction.)
-
--766 = 2X chrominance subsampling.  Chrominance components are sent for every
-       other pixel in the source image.  This would typically be implemented
-       using 4:2:2 subsampling (2X subsampling in the X direction.)
-
--765 = Grayscale.  All chrominance components in the source image are
-       discarded.
-
--764 = 8X chrominance subsampling.  Chrominance components are sent for every
-       8th pixel in the source image.  This would typically be implemented
-       using 4:1:0 subsampling (4X subsampling in the X direction and 2X
-       subsampling in the Y direction.)
-
--763 = 16X chrominance subsampling.  Chrominance components are sent for every
-       16th pixel in the source image.  This would typically be implemented
-       using 4X subsampling in both X and Y directions.
-
-This pseudo-encoding was originally intended for use with JPEG-encoded
-subrectangles, but it could be used with other types of image encoding as well.
-
 Cursor Pseudo-encoding
 -----------------------
 
@@ -3053,3 +3000,56 @@
 replies with a message of type `xvp Server Message`_, using an
 *xvp-message-code* of *XVP_INIT*.  This informs the client that it may
 then subsequently send messages of type `xvp Client Message`_.
+
+JPEG Fine-Grained Quality Level Pseudo-encoding
+-----------------------------------------------
+
+The JPEG Fine-Grained Quality Level pseudo-encoding allows the image
+quality to be specified on a 0 to 100 scale, with -512 corresponding to image
+quality 0 and -412 corresponding to image quality 100.  This pseudo-encoding
+was originally intended for use with JPEG-encoded subrectangles, but it could
+be used with other types of image encoding as well.
+
+JPEG Subsampling Level Pseudo-Encoding
+--------------------------------------
+
+The JPEG Subsampling Level pseudo-encoding allows the level of chrominance
+subsampling to be specified.  When a JPEG image is encoded, the RGB pixels are
+first converted to YCbCr, a colorspace in which brightness (luminance) is
+separated from color (chrominance.)  Since the human eye is more sensitive to
+spatial changes in brightness than to spatial changes in color, the chrominance
+components (Cb, Cr) can be subsampled to save bandwidth without losing much
+image quality (on smooth images, such as photographs, chrominance subsampling
+is often not distinguishable by the human eye.)  Subsampling can be implemented
+either by averaging together groups of chrominance components or by simply
+picking one component from the group and discarding the rest.
+
+The values for this pseudo-encoding are defined as follows:
+
+-768 = 1X chrominance subsampling (no chrominance subsampling).
+       Chrominance components are sent for every pixel in the source image.
+
+-767 = 4X chrominance subsampling.  Chrominance components are sent for every
+       fourth pixel in the source image.  This would typically be implemented
+       using 4:2:0 subsampling (2X subsampling in both X and Y directions), but
+       it could also be implemented using 4:1:1 subsampling (4X subsampling in
+       the X direction.)
+
+-766 = 2X chrominance subsampling.  Chrominance components are sent for every
+       other pixel in the source image.  This would typically be implemented
+       using 4:2:2 subsampling (2X subsampling in the X direction.)
+
+-765 = Grayscale.  All chrominance components in the source image are
+       discarded.
+
+-764 = 8X chrominance subsampling.  Chrominance components are sent for every
+       8th pixel in the source image.  This would typically be implemented
+       using 4:1:0 subsampling (4X subsampling in the X direction and 2X
+       subsampling in the Y direction.)
+
+-763 = 16X chrominance subsampling.  Chrominance components are sent for every
+       16th pixel in the source image.  This would typically be implemented
+       using 4X subsampling in both X and Y directions.
+
+This pseudo-encoding was originally intended for use with JPEG-encoded
+subrectangles, but it could be used with other types of image encoding as well.

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4741
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4741&view=rev
Author:   ossman_
Date:     2011-10-27 12:18:12 +0000 (Thu, 27 Oct 2011)
Log Message:
-----------
Remove encodings that we now have documentation for.

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-10-27 12:14:56 UTC (rev 4740)
+++ rfbproto/rfbproto.rst	2011-10-27 12:18:12 UTC (rev 4741)
@@ -1955,8 +1955,6 @@
 -260 to -272                QEMU
 -273 to -304                VMWare
 -306                        popa
--412 to -512                TurboVNC fine-grained quality level
--763 to -768                TurboVNC subsampling level
 0x574d5600 to 0x574d56ff    VMWare
 =========================== ===========================================
 

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4746
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4746&view=rev
Author:   ossman_
Date:     2011-11-01 11:54:12 +0000 (Tue, 01 Nov 2011)
Log Message:
-----------
X Cursor

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-10-31 08:14:40 UTC (rev 4745)
+++ rfbproto/rfbproto.rst	2011-11-01 11:54:12 UTC (rev 4746)
@@ -788,7 +788,7 @@
 -232    "``TGHT``"  "``POINTPOS``"  Pointer Position
 -239    "``TGHT``"  "``RCHCURSR``"  `Cursor Pseudo-encoding`_ (Rich
                                     Cursor)
--240    "``TGHT``"  "``X11CURSR``"  X Cursor
+-240    "``TGHT``"  "``X11CURSR``"  `X Cursor Pseudo-encoding`_
 -256    "``TGHT``"  "``COMPRLVL``"  `Compression Level
                                     Pseudo-encoding`_
 -305    "``GGI_``"  "``GII_____``"  `gii Pseudo-encoding`_
@@ -1929,6 +1929,7 @@
 -223         `DesktopSize Pseudo-encoding`_
 -224         `LastRect Pseudo-encoding`_
 -239         `Cursor Pseudo-encoding`_
+-240         `X Cursor Pseudo-encoding`_
 -247 to -256 `Compression Level Pseudo-encoding`_
 -257         `QEMU Pointer Motion Change Psuedo-encoding`_
 -258         `QEMU Extended Key Event Psuedo-encoding`_
@@ -1951,7 +1952,7 @@
 -1 to -22                   Tight options
 -33 to -222                 Tight options
 -225 to -238                Tight options
--240 to -246                Tight options
+-241 to -246                Tight options
 -260 to -272                QEMU
 -273 to -304                VMWare
 -306                        popa
@@ -2664,6 +2665,41 @@
 floor((*width* + 7) / 8) * *height*    ``U8`` array     *bitmask*
 ====================================== ================ ===============
 
+X Cursor Pseudo-encoding
+------------------------
+
+A client which requests the *X Cursor* pseudo-encoding is declaring
+that it is capable of drawing a mouse cursor locally. This can
+significantly improve perceived performance over slow links. The
+server sets the cursor shape by sending a pseudo-rectangle with the
+*X Cursor* pseudo-encoding as part of an update.
+
+The pseudo-rectangle's *x-position* and *y-position* indicate the
+hotspot of the cursor, and *width* and *height* indicate the width and
+height of the cursor in pixels. 
+
+The data consists of the primary and secondary colours for the cursor,
+followed by one bitmap for the colour and one bitmask for the
+transparency. The bitmap and bitmask both consist of left-to-right,
+top-to-bottom scanlines, where each scanline is padded to a whole
+number of bytes floor((*width* + 7) / 8). Within each byte the most
+significant bit represents the leftmost pixel, with a 1-bit meaning the
+corresponding pixel should use the primary colour, or that the pixel is
+valid.
+
+====================================== ================ ===============
+No. of bytes                           Type             Description
+====================================== ================ ===============
+1                                      ``U8``           *primary-r*
+1                                      ``U8``           *primary-g*
+1                                      ``U8``           *primary-b*
+1                                      ``U8``           *secondary-r*
+1                                      ``U8``           *secondary-g*
+1                                      ``U8``           *secondary-b*
+floor((*width* + 7) / 8) * *height*    ``U8`` array     *bitmap*
+floor((*width* + 7) / 8) * *height*    ``U8`` array     *bitmask*
+====================================== ================ ===============
+
 DesktopSize Pseudo-encoding
 ---------------------------
 

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4747
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4747&view=rev
Author:   ossman_
Date:     2011-11-01 11:54:35 +0000 (Tue, 01 Nov 2011)
Log Message:
-----------
Merge the zlib footnotes into one.

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-11-01 11:54:12 UTC (rev 4746)
+++ rfbproto/rfbproto.rst	2011-11-01 11:54:35 UTC (rev 4747)
@@ -2203,12 +2203,12 @@
 zlib Encoding
 -------------
 
-The zlib encoding uses zlib [#]_ to compress rectangles encoded
+The zlib encoding uses zlib [#zlib]_ to compress rectangles encoded
 according to the `Raw Encoding`_. A single zlib "stream" object is used
 for a given RFB connection, so that zlib rectangles must be encoded and
 decoded strictly in order.
 
-.. [#] see http://www.gzip.org/zlib/
+.. [#zlib] see http://www.gzip.org/zlib/
 
 =============== =================== ===================================
 No. of bytes    Type                Description
@@ -2425,7 +2425,7 @@
 zlibhex Encoding
 ----------------
 
-The zlibhex encoding uses zlib [#]_ to optionally compress
+The zlibhex encoding uses zlib [#zlib]_ to optionally compress
 subrectangles according to the `Hextile Encoding`_. Refer to the
 hextile encoding for information on how the rectangle is divided into
 subrectangles and other basic properties of subrectangles. One zlib
@@ -2433,8 +2433,6 @@
 **Raw** subencoding and one zlib "stream" object is used for all other
 subrectangles.
 
-.. [#] see http://www.gzip.org/zlib/
-
 The hextile subencoding bitfield is extended with these bits:
 
 =============== ======= =========== ===================================
@@ -2471,15 +2469,13 @@
 ZRLE Encoding
 -------------
 
-ZRLE stands for Zlib [#]_ Run-Length Encoding, and combines zlib
+ZRLE stands for Zlib [#zlib]_ Run-Length Encoding, and combines zlib
 compression, tiling, palettisation and run-length encoding. On the
 wire, the rectangle begins with a 4-byte length field, and is followed
 by that many bytes of zlib-compressed data. A single zlib "stream"
 object is used for a given RFB protocol connection, so that ZRLE
 rectangles must be encoded and decoded strictly in order.
 
-.. [#] see http://www.gzip.org/zlib/
-
 =============== =================== ===================================
 No. of bytes    Type                Description
 =============== =================== ===================================

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4748
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4748&view=rev
Author:   ossman_
Date:     2011-11-01 12:01:46 +0000 (Tue, 01 Nov 2011)
Log Message:
-----------
Continuous updates

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 <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-11-01 11:54:35 UTC (rev 4747)
+++ rfbproto/rfbproto.rst	2011-11-01 12:01:46 UTC (rev 4748)
@@ -828,8 +828,11 @@
 252         tight
 251         `SetDesktopSize`_
 250         `xvp Client Message`_
+150 [#off]_ `EnableContinuousUpdates`_
 =========== ===========================================================
 
+.. [#off] **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,6 +1688,7 @@
 253         `gii Server Message`_
 252         tight
 250         `xvp Server Message`_
+150 [#off]_ `EndOfContinuousUpdates`_
 =========== ===========================================================
 
 Note that before sending a message with an optional message type a
@@ -1908,6 +1951,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
 +++++++++
 

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4749
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4749&view=rev
Author:   ossman_
Date:     2011-11-01 12:14:10 +0000 (Tue, 01 Nov 2011)
Log Message:
-----------
Registry cleanup

Update the list of registered protocol numbers from upstream and clean up
the ordering in the process.

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-11-01 12:01:46 UTC (rev 4748)
+++ rfbproto/rfbproto.rst	2011-11-01 12:14:10 UTC (rev 4749)
@@ -380,13 +380,18 @@
 =========== ===========================================================
 Number      Name
 =========== ===========================================================
+3-4         RealVNC
 5           RA2
 6           RA2ne
+7-15        RealVNC
 17          Ultra
 18          TLS
 19          VeNCrypt
 20          SASL
 21          MD5 hash authentication
+22          xvp
+30-35       Apple Inc.
+128-255     RealVNC
 =========== ===========================================================
 
 Once the *security-type* has been decided, data specific to that
@@ -822,13 +827,16 @@
 =========== ===========================================================
 Number      Name
 =========== ===========================================================
+127         VMWare
+128         Car Connectivity
+150 [#off]_ `EnableContinuousUpdates`_
+249         OLIVE Call Control
+250         `xvp Client Message`_
+251         `SetDesktopSize`_
+252         tight
+253         `gii Client Message`_
+254         VMWare
 255         `QEMU Client Message`_
-254, 127    VMWare
-253         `gii Client Message`_
-252         tight
-251         `SetDesktopSize`_
-250         `xvp Client Message`_
-150 [#off]_ `EnableContinuousUpdates`_
 =========== ===========================================================
 
 .. [#off] **Warning:** Not officially allocated
@@ -1683,12 +1691,15 @@
 =========== ===========================================================
 Number      Name
 =========== ===========================================================
+127         VMWare
+128         Car Connectivity
+150 [#off]_ `EndOfContinuousUpdates`_
+249         OLIVE Call Control
+250         `xvp Server Message`_
+252         tight
+253         `gii Server Message`_
+254         VMWare
 255         QEMU
-254, 127    VMWare
-253         `gii Server Message`_
-252         tight
-250         `xvp Server Message`_
-150 [#off]_ `EndOfContinuousUpdates`_
 =========== ===========================================================
 
 Note that before sending a message with an optional message type a
@@ -2007,6 +2018,10 @@
 =========================== ===========================================
 15                          TRLE
 17                          Hitachi ZYWRLE
+1000 to 1002                Apple Inc.
+1011                        Apple Inc.
+1024 to 1099                RealVNC
+1100 to 1104                Apple Inc.
 -1 to -22                   Tight options
 -33 to -222                 Tight options
 -225 to -238                Tight options
@@ -2014,6 +2029,9 @@
 -260 to -272                QEMU
 -273 to -304                VMWare
 -306                        popa
+-310                        OLIVE Call Control
+-311                        ClientRedirect
+-523 to -528                Car Connectivity
 0x574d5600 to 0x574d56ff    VMWare
 =========================== ===========================================
 

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4750
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4750&view=rev
Author:   ossman_
Date:     2011-11-01 12:17:35 +0000 (Tue, 01 Nov 2011)
Log Message:
-----------
Add references to upstream registry

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-11-01 12:14:10 UTC (rev 4749)
+++ rfbproto/rfbproto.rst	2011-11-01 12:17:35 UTC (rev 4750)
@@ -394,6 +394,10 @@
 128-255     RealVNC
 =========== ===========================================================
 
+The official, up-to-date list is maintained by IANA [#reg]_.
+
+.. [#reg] http://www.ietf.org/assignments/rfb/rfb.xml
+
 Once the *security-type* has been decided, data specific to that
 *security-type* follows (see `Security Types`_ for details). At the end
 of the security handshaking phase, the protocol normally continues with
@@ -841,6 +845,8 @@
 
 .. [#off] **Warning:** Not officially allocated
 
+The official, up-to-date list is maintained by IANA [#reg]_.
+
 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
@@ -1702,6 +1708,8 @@
 255         QEMU
 =========== ===========================================================
 
+The official, up-to-date list is maintained by IANA [#reg]_.
+
 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
@@ -2035,6 +2043,8 @@
 0x574d5600 to 0x574d56ff    VMWare
 =========================== ===========================================
 
+The official, up-to-date list is maintained by IANA [#reg]_.
+
 Raw Encoding
 ------------
 

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4751
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4751&view=rev
Author:   ossman_
Date:     2011-11-01 12:35:24 +0000 (Tue, 01 Nov 2011)
Log Message:
-----------
Document protocol numbers used by UltraVNC

It seems UltraVNC has allocated a lot of protocol numbers on their own.
We need to know of these to avoid conflicts.

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-11-01 12:17:35 UTC (rev 4750)
+++ rfbproto/rfbproto.rst	2011-11-01 12:35:24 UTC (rev 4751)
@@ -831,6 +831,17 @@
 =========== ===========================================================
 Number      Name
 =========== ===========================================================
+7 [#off]_   FileTransfer
+8 [#off]_   SetScale
+9 [#off]_   SetServerInput
+10 [#off]_  SetSW
+11 [#off]_  TextChat
+12 [#off]_  KeyFrameRequest
+13 [#off]_  KeepAlive
+15 [#off]_  SetScaleFactor
+20 [#off]_  RequestSession
+21 [#off]_  SetSession
+80 [#off]_  NotifyPluginStreaming
 127         VMWare
 128         Car Connectivity
 150 [#off]_ `EnableContinuousUpdates`_
@@ -1697,9 +1708,16 @@
 =========== ===========================================================
 Number      Name
 =========== ===========================================================
+4 [#off]_   ResizeFrameBuffer
+5 [#off]_   KeyFrameUpdate
+7 [#off]_   FileTransfer
+11 [#off]_  TextChat
+13 [#off]_  KeepAlive
+15 [#off]_  ResizeFrameBuffer
 127         VMWare
 128         Car Connectivity
 150 [#off]_ `EndOfContinuousUpdates`_
+173 [#off]_ ServerState
 249         OLIVE Call Control
 250         `xvp Server Message`_
 252         tight
@@ -2024,6 +2042,8 @@
 =========================== ===========================================
 Number                      Name
 =========================== ===========================================
+9 [#off]_                   Ultra
+10 [#off]_                  Ultra2
 15                          TRLE
 17                          Hitachi ZYWRLE
 1000 to 1002                Apple Inc.
@@ -2032,7 +2052,8 @@
 1100 to 1104                Apple Inc.
 -1 to -22                   Tight options
 -33 to -222                 Tight options
--225 to -238                Tight options
+-225                        PointerPos
+-226 to -238                Tight options
 -241 to -246                Tight options
 -260 to -272                QEMU
 -273 to -304                VMWare
@@ -2041,6 +2062,22 @@
 -311                        ClientRedirect
 -523 to -528                Car Connectivity
 0x574d5600 to 0x574d56ff    VMWare
+0xc0a1e5ce [#off]_          ExtendedClipboard
+0xc0a1e5cf [#off]_          PluginStreaming
+0xffff0000 [#off]_          Cache
+0xffff0001 [#off]_          CacheEnable
+0xffff0002 [#off]_          XOR zlib
+0xffff0003 [#off]_          XORMonoRect zlib
+0xffff0004 [#off]_          XORMultiColor zlib
+0xffff0005 [#off]_          SolidColor
+0xffff0006 [#off]_          XOREnable
+0xffff0007 [#off]_          CacheZip
+0xffff0008 [#off]_          SolMonoZip
+0xffff0009 [#off]_          UltraZip
+0xffff8000 [#off]_          ServerState
+0xffff8001 [#off]_          EnableKeepAlive
+0xffff8002 [#off]_          FTProtocolVersion
+0xffff8003 [#off]_          Session
 =========================== ===========================================
 
 The official, up-to-date list is maintained by IANA [#reg]_.

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4767
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4767&view=rev
Author:   ossman_
Date:     2011-11-04 12:04:53 +0000 (Fri, 04 Nov 2011)
Log Message:
-----------
Wrong upstream URI

Seems like IETF has a stale copy of these things. iana.org should be the
proper one though.

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-11-04 11:42:16 UTC (rev 4766)
+++ rfbproto/rfbproto.rst	2011-11-04 12:04:53 UTC (rev 4767)
@@ -396,7 +396,7 @@
 
 The official, up-to-date list is maintained by IANA [#reg]_.
 
-.. [#reg] http://www.ietf.org/assignments/rfb/rfb.xml
+.. [#reg] http://www.iana.org/assignments/rfb/rfb.xml
 
 Once the *security-type* has been decided, data specific to that
 *security-type* follows (see `Security Types`_ for details). At the end

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4791
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4791&view=rev
Author:   ossman_
Date:     2011-11-11 08:38:37 +0000 (Fri, 11 Nov 2011)
Log Message:
-----------
Update to latest IANA repository information

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-11-10 14:59:24 UTC (rev 4790)
+++ rfbproto/rfbproto.rst	2011-11-11 08:38:37 UTC (rev 4791)
@@ -831,20 +831,23 @@
 =========== ===========================================================
 Number      Name
 =========== ===========================================================
-7 [#off]_   FileTransfer
-8 [#off]_   SetScale
-9 [#off]_   SetServerInput
-10 [#off]_  SetSW
-11 [#off]_  TextChat
-12 [#off]_  KeyFrameRequest
-13 [#off]_  KeepAlive
-15 [#off]_  SetScaleFactor
-20 [#off]_  RequestSession
-21 [#off]_  SetSession
-80 [#off]_  NotifyPluginStreaming
+7           FileTransfer
+8           SetScale
+9           SetServerInput
+10          SetSW
+11          TextChat
+12          KeyFrameRequest
+13          KeepAlive
+14          Possibly used in UltraVNC
+15          SetScaleFactor
+16-19       Possibly used in UltraVNC
+20          RequestSession
+21          SetSession
+80          NotifyPluginStreaming
 127         VMWare
 128         Car Connectivity
-150 [#off]_ `EnableContinuousUpdates`_
+150         `EnableContinuousUpdates`_
+248         ClientFence
 249         OLIVE Call Control
 250         `xvp Client Message`_
 251         `SetDesktopSize`_
@@ -854,8 +857,6 @@
 255         `QEMU Client Message`_
 =========== ===========================================================
 
-.. [#off] **Warning:** Not officially allocated
-
 The official, up-to-date list is maintained by IANA [#reg]_.
 
 Note that before sending a message with an optional message type a
@@ -1708,16 +1709,21 @@
 =========== ===========================================================
 Number      Name
 =========== ===========================================================
-4 [#off]_   ResizeFrameBuffer
-5 [#off]_   KeyFrameUpdate
-7 [#off]_   FileTransfer
-11 [#off]_  TextChat
-13 [#off]_  KeepAlive
-15 [#off]_  ResizeFrameBuffer
+4           ResizeFrameBuffer
+5           KeyFrameUpdate
+6           Possibly used in UltraVNC
+7           FileTransfer
+8-10        Possibly used in UltraVNC
+11          TextChat
+12          Possibly used in UltraVNC
+13          KeepAlive
+14          Possibly used in UltraVNC
+15          ResizeFrameBuffer
 127         VMWare
 128         Car Connectivity
-150 [#off]_ `EndOfContinuousUpdates`_
+150         `EndOfContinuousUpdates`_
 173 [#off]_ ServerState
+248         ServerFence
 249         OLIVE Call Control
 250         `xvp Server Message`_
 252         tight
@@ -1726,6 +1732,8 @@
 255         QEMU
 =========== ===========================================================
 
+.. [#off] **Warning:** Not officially allocated
+
 The official, up-to-date list is maintained by IANA [#reg]_.
 
 Note that before sending a message with an optional message type a
@@ -2042,14 +2050,14 @@
 =========================== ===========================================
 Number                      Name
 =========================== ===========================================
-9 [#off]_                   Ultra
-10 [#off]_                  Ultra2
+9                           Ultra
+10                          Ultra2
 15                          TRLE
 17                          Hitachi ZYWRLE
 1000 to 1002                Apple Inc.
 1011                        Apple Inc.
 1024 to 1099                RealVNC
-1100 to 1104                Apple Inc.
+1100 to 1105                Apple Inc.
 -1 to -22                   Tight options
 -33 to -222                 Tight options
 -225                        PointerPos
@@ -2060,24 +2068,26 @@
 -306                        popa
 -310                        OLIVE Call Control
 -311                        ClientRedirect
+-312                        Fence
+-313                        ContinuousUpdates
 -523 to -528                Car Connectivity
 0x574d5600 to 0x574d56ff    VMWare
-0xc0a1e5ce [#off]_          ExtendedClipboard
-0xc0a1e5cf [#off]_          PluginStreaming
-0xffff0000 [#off]_          Cache
-0xffff0001 [#off]_          CacheEnable
-0xffff0002 [#off]_          XOR zlib
-0xffff0003 [#off]_          XORMonoRect zlib
-0xffff0004 [#off]_          XORMultiColor zlib
-0xffff0005 [#off]_          SolidColor
-0xffff0006 [#off]_          XOREnable
-0xffff0007 [#off]_          CacheZip
-0xffff0008 [#off]_          SolMonoZip
-0xffff0009 [#off]_          UltraZip
-0xffff8000 [#off]_          ServerState
-0xffff8001 [#off]_          EnableKeepAlive
-0xffff8002 [#off]_          FTProtocolVersion
-0xffff8003 [#off]_          Session
+0xc0a1e5ce                  ExtendedClipboard
+0xc0a1e5cf                  PluginStreaming
+0xffff0000                  Cache
+0xffff0001                  CacheEnable
+0xffff0002                  XOR zlib
+0xffff0003                  XORMonoRect zlib
+0xffff0004                  XORMultiColor zlib
+0xffff0005                  SolidColor
+0xffff0006                  XOREnable
+0xffff0007                  CacheZip
+0xffff0008                  SolMonoZip
+0xffff0009                  UltraZip
+0xffff8000                  ServerState
+0xffff8001                  EnableKeepAlive
+0xffff8002                  FTProtocolVersion
+0xffff8003                  Session
 =========================== ===========================================
 
 The official, up-to-date list is maintained by IANA [#reg]_.

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4792
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4792&view=rev
Author:   ossman_
Date:     2011-11-11 08:40:27 +0000 (Fri, 11 Nov 2011)
Log Message:
-----------
Add missing link from server to client message list to the QEMU message.

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-11-11 08:38:37 UTC (rev 4791)
+++ rfbproto/rfbproto.rst	2011-11-11 08:40:27 UTC (rev 4792)
@@ -1729,7 +1729,7 @@
 252         tight
 253         `gii Server Message`_
 254         VMWare
-255         QEMU
+255         `QEMU Server Message`_
 =========== ===========================================================
 
 .. [#off] **Warning:** Not officially allocated

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4793
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4793&view=rev
Author:   ossman_
Date:     2011-11-11 08:44:13 +0000 (Fri, 11 Nov 2011)
Log Message:
-----------
Reorder messages so that they follow the order of the allocation list

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-11-11 08:40:27 UTC (rev 4792)
+++ rfbproto/rfbproto.rst	2011-11-11 08:44:13 UTC (rev 4793)
@@ -1153,6 +1153,133 @@
 *length*        ``U8`` array                    *text*
 =============== ==================== ========== =======================
 
+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.
+
+xvp Client Message
+------------------
+
+A client supporting the *xvp* extension sends this to request that the
+server initiate a clean shutdown, clean reboot or abrupt reset of the
+system whose framebuffer the client is displaying.
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               250        *message-type*
+1                                               *padding*
+1               ``U8``               1          *xvp-extension-version*
+1               ``U8``                          *xvp-message-code*
+=============== ==================== ========== =======================
+
+The possible values for *xvp-message-code* are: 2 - XVP_SHUTDOWN,
+3 - XVP_REBOOT, and 4 - XVP_RESET.  The client must have already
+established that the server supports this extension, by requesting the
+`xvp Pseudo-encoding`_.
+
+SetDesktopSize
+--------------
+
+Requests a change of desktop size. This message is an extension and
+may only be sent if the client has previously received an
+*ExtendedDesktopSize* rectangle.
+
+The server must send an *ExtendedDesktopSize* rectangle for every
+*SetDesktopSize* message received. Several rectangles may be
+sent in a single *FramebufferUpdate* message, but the rectangles must
+not be merged or reordered in any way. Note that rectangles sent for
+other reasons may be interleaved with the ones generated as a result
+of *SetDesktopSize* messages.
+
+Upon a successful request the server must send an *ExtendedDesktopSize*
+rectangle to the requesting client with the exact same information the
+client provided in the corresponding *SetDesktopSize* message.
+*x-position* must be set to 1, indicating a client initiated event, and
+*y-position* must be set to 0, indicating success.
+
+The server must also send an *ExtendedDesktopSize* rectangle to all
+other connected clients, but with *x-position* set to 2, indicating a
+change initiated by another client.
+
+If the server can not or will not satisfy the request, it must send
+an *ExtendedDesktopSize* rectangle to the requesting client with
+*x-position* set to 1 and *y-position* set to the relevant error code.
+All remaining fields are undefined, although the basic structure must
+still be followed. The server must not send an *ExtendedDesktopSize*
+rectangle to any other connected clients.
+
+All *ExtendedDesktopSize* rectangles that are sent as a result of a
+*SetDesktopSize* message should be sent as soon as possible.
+
+======================== ================= ======= ====================
+No. of bytes             Type              [Value] Description
+======================== ================= ======= ====================
+1                        ``U8``            251     *message-type*
+2                                                  *padding*
+2                        ``U16``                   *width*
+2                        ``U16``                   *height*
+1                        ``U8``                    *number-of-screens*
+1                                                  *padding*
+*number-of-screens* * 16 ``SCREEN`` array          *screens*
+======================== ================= ======= ====================
+
+The *width* and *height* indicates the framebuffer size requested. This
+structure is followed by *number-of-screens* number of ``SCREEN``
+structures, which is defined in `ExtendedDesktopSize Pseudo-encoding`_:
+
+=============== =============================== =======================
+No. of bytes    Type                            Description
+=============== =============================== =======================
+4               ``U32``                         *id*
+2               ``U16``                         *x-position*
+2               ``U16``                         *y-position*
+2               ``U16``                         *width*
+2               ``U16``                         *height*
+4               ``U32``                         *flags*
+=============== =============================== =======================
+
+The *id* field must be preserved upon modification as it determines the
+difference between a moved screen and a newly created one. The client
+should make every effort to preserve the fields it does not wish to
+modify, including any unknown *flags* bits.
+
 gii Client Message
 ------------------
 
@@ -1419,93 +1546,6 @@
 
 The event reports *count* valuators starting with *first*.
 
-SetDesktopSize
---------------
-
-Requests a change of desktop size. This message is an extension and
-may only be sent if the client has previously received an
-*ExtendedDesktopSize* rectangle.
-
-The server must send an *ExtendedDesktopSize* rectangle for every
-*SetDesktopSize* message received. Several rectangles may be
-sent in a single *FramebufferUpdate* message, but the rectangles must
-not be merged or reordered in any way. Note that rectangles sent for
-other reasons may be interleaved with the ones generated as a result
-of *SetDesktopSize* messages.
-
-Upon a successful request the server must send an *ExtendedDesktopSize*
-rectangle to the requesting client with the exact same information the
-client provided in the corresponding *SetDesktopSize* message.
-*x-position* must be set to 1, indicating a client initiated event, and
-*y-position* must be set to 0, indicating success.
-
-The server must also send an *ExtendedDesktopSize* rectangle to all
-other connected clients, but with *x-position* set to 2, indicating a
-change initiated by another client.
-
-If the server can not or will not satisfy the request, it must send
-an *ExtendedDesktopSize* rectangle to the requesting client with
-*x-position* set to 1 and *y-position* set to the relevant error code.
-All remaining fields are undefined, although the basic structure must
-still be followed. The server must not send an *ExtendedDesktopSize*
-rectangle to any other connected clients.
-
-All *ExtendedDesktopSize* rectangles that are sent as a result of a
-*SetDesktopSize* message should be sent as soon as possible.
-
-======================== ================= ======= ====================
-No. of bytes             Type              [Value] Description
-======================== ================= ======= ====================
-1                        ``U8``            251     *message-type*
-2                                                  *padding*
-2                        ``U16``                   *width*
-2                        ``U16``                   *height*
-1                        ``U8``                    *number-of-screens*
-1                                                  *padding*
-*number-of-screens* * 16 ``SCREEN`` array          *screens*
-======================== ================= ======= ====================
-
-The *width* and *height* indicates the framebuffer size requested. This
-structure is followed by *number-of-screens* number of ``SCREEN``
-structures, which is defined in `ExtendedDesktopSize Pseudo-encoding`_:
-
-=============== =============================== =======================
-No. of bytes    Type                            Description
-=============== =============================== =======================
-4               ``U32``                         *id*
-2               ``U16``                         *x-position*
-2               ``U16``                         *y-position*
-2               ``U16``                         *width*
-2               ``U16``                         *height*
-4               ``U32``                         *flags*
-=============== =============================== =======================
-
-The *id* field must be preserved upon modification as it determines the
-difference between a moved screen and a newly created one. The client
-should make every effort to preserve the fields it does not wish to
-modify, including any unknown *flags* bits.
-
-xvp Client Message
-------------------
-
-A client supporting the *xvp* extension sends this to request that the
-server initiate a clean shutdown, clean reboot or abrupt reset of the
-system whose framebuffer the client is displaying.
-
-=============== ==================== ========== =======================
-No. of bytes    Type                 [Value]    Description
-=============== ==================== ========== =======================
-1               ``U8``               250        *message-type*
-1                                               *padding*
-1               ``U8``               1          *xvp-extension-version*
-1               ``U8``                          *xvp-message-code*
-=============== ==================== ========== =======================
-
-The possible values for *xvp-message-code* are: 2 - XVP_SHUTDOWN,
-3 - XVP_REBOOT, and 4 - XVP_RESET.  The client must have already
-established that the server supports this extension, by requesting the
-`xvp Pseudo-encoding`_.
-
 QEMU Client Message
 -------------------
 
@@ -1650,46 +1690,6 @@
 
 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
 +++++++++++++++++++++++++
 
@@ -1841,6 +1841,51 @@
 *length*        ``U8`` array                    *text*
 =============== ==================== ========== =======================
 
+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*
+=============== ==================== ========== =======================
+
+xvp Server Message
+------------------
+
+This has the following format:
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               250        *message-type*
+1                                               *padding*
+1               ``U8``               1          *xvp-extension-version*
+1               ``U8``                          *xvp-message-code*
+=============== ==================== ========== =======================
+
+The possible values for *xvp-message-code* are: 0 - XVP_FAIL and 1 -
+XVP_INIT.
+
+A server which supports the *xvp* extension declares this by sending a
+message with an XVP_INIT *xvp-message-code* when it receives a request
+from the client to use the `xvp Pseudo-encoding`_.  The server must
+specify in this message the highest *xvp-extension-version* it supports:
+the client may assume that the server supports all versions from 1 up to
+this value.  The client is then free to use any supported version.
+Currently, only version 1 is defined.
+
+A server which subsequently receives an `xvp Client Message`_ requesting
+an operation which it is unable to perform, informs the client of this
+by sending a message with an XVP_FAIL *xvp-message-code*, and the same
+*xvp-extension-version* as included in the client's operation request.
+
 gii Server Message
 ------------------
 
@@ -1892,36 +1937,6 @@
 communications. A *device-origin* of zero indicates device creation
 failure.
 
-xvp Server Message
-------------------
-
-This has the following format:
-
-=============== ==================== ========== =======================
-No. of bytes    Type                 [Value]    Description
-=============== ==================== ========== =======================
-1               ``U8``               250        *message-type*
-1                                               *padding*
-1               ``U8``               1          *xvp-extension-version*
-1               ``U8``                          *xvp-message-code*
-=============== ==================== ========== =======================
-
-The possible values for *xvp-message-code* are: 0 - XVP_FAIL and 1 -
-XVP_INIT.
-
-A server which supports the *xvp* extension declares this by sending a
-message with an XVP_INIT *xvp-message-code* when it receives a request
-from the client to use the `xvp Pseudo-encoding`_.  The server must
-specify in this message the highest *xvp-extension-version* it supports:
-the client may assume that the server supports all versions from 1 up to
-this value.  The client is then free to use any supported version.
-Currently, only version 1 is defined.
-
-A server which subsequently receives an `xvp Client Message`_ requesting
-an operation which it is unable to perform, informs the client of this
-by sending a message with an XVP_FAIL *xvp-message-code*, and the same
-*xvp-extension-version* as included in the client's operation request.
-
 QEMU Server Message
 -------------------
 
@@ -1996,21 +2011,6 @@
 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
 +++++++++
 

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4806
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4806&view=rev
Author:   ossman_
Date:     2011-11-15 12:23:46 +0000 (Tue, 15 Nov 2011)
Log Message:
-----------
Continuous updates pseudo-encoding

Allows clients and servers to handshake for the continuous updates
extension without having to use the tight authentication method.

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-11-15 12:13:37 UTC (rev 4805)
+++ rfbproto/rfbproto.rst	2011-11-15 12:23:46 UTC (rev 4806)
@@ -2041,6 +2041,7 @@
 -307         `DesktopName Pseudo-encoding`_
 -308         `ExtendedDesktopSize Pseudo-encoding`_
 -309         `xvp Pseudo-encoding`_
+-313         `ContinuousUpdates Pseudo-encoding`_
 -412 to -512 `JPEG Fine-Grained Quality Level Pseudo-encoding`_
 -763 to -768 `JPEG Subsampling Level Pseudo-encoding`_
 ============ ==========================================================
@@ -2069,7 +2070,6 @@
 -310                        OLIVE Call Control
 -311                        ClientRedirect
 -312                        Fence
--313                        ContinuousUpdates
 -523 to -528                Car Connectivity
 0x574d5600 to 0x574d56ff    VMWare
 0xc0a1e5ce                  ExtendedClipboard
@@ -3164,6 +3164,16 @@
 *xvp-message-code* of *XVP_INIT*.  This informs the client that it may
 then subsequently send messages of type `xvp Client Message`_.
 
+ContinuousUpdates Pseudo-encoding
+---------------------------------
+
+A client which requests the *ContinuousUpdates* pseudo-encoding is
+declaring that it wishes to use the `EnableContinuousUpdates`_
+extension. The server must send a `EndOfContinuousUpdates`_ message the
+first time it sees a ``SetEncodings`` message with the
+*ContinuousUpdates* pseudo-encoding, in order to inform the client that
+the extension is supported.
+
 JPEG Fine-Grained Quality Level Pseudo-encoding
 -----------------------------------------------
 

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4807
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4807&view=rev
Author:   ossman_
Date:     2011-11-15 12:26:30 +0000 (Tue, 15 Nov 2011)
Log Message:
-----------
Synchronisation fences

This documents the fence messages that can be used to synchronise
other messages, and to measure network and processing delays between
the client and server.

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-11-15 12:23:46 UTC (rev 4806)
+++ rfbproto/rfbproto.rst	2011-11-15 12:26:30 UTC (rev 4807)
@@ -847,7 +847,7 @@
 127         VMWare
 128         Car Connectivity
 150         `EnableContinuousUpdates`_
-248         ClientFence
+248         `ClientFence`_
 249         OLIVE Call Control
 250         `xvp Client Message`_
 251         `SetDesktopSize`_
@@ -1193,6 +1193,75 @@
 however be honored, even if the area in such a request does not overlap
 the area specified for continuous updates.
 
+ClientFence
+-----------
+
+A client supporting the *Fence* extension sends this to request a
+synchronisation of the data stream.
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               248        *message-type*
+3                                               *padding*
+4               ``U32``                         *flags*
+1               ``U8``                          *length*
+*length*        ``U8`` array                    *payload*
+=============== ==================== ========== =======================
+
+The *flags* byte informs the server if this is a new request, or a
+response to a server request sent earlier, as well as what kind of
+synchronisation that is desired. The server should not delay the
+response more than necessary, even if the synchronisation requirements
+would allow it.
+
+=============== =======================================================
+Bit             Description
+=============== =======================================================
+0               **BlockBefore**
+1               **BlockAfter**
+2               **SyncNext**
+3-30            Currently unused
+31              **Request**
+=============== =======================================================
+
+The server should respond with a `ServerFence`_ with the **Request**
+bit cleared, as well as clearing any bits it does not understand. The
+remaining bits should remain set in the response. This allows the
+client to determine which flags the server supports when new ones are
+defined in the future.
+
+**BlockBefore**
+    All messages preceeding this one must have finished processing and
+    taken effect before the response is sent.
+
+**BlockAfter**
+    All messages following this one must not start processing until the
+    response is sent.
+
+**SyncNext**
+    The message following this one must be executed in an atomic manner
+    so that anything preceeding the fence response **must not** be
+    affected by the message, and anything following the fence response
+    *must* be affected by the message. The primary purpose of this
+    synchronisation is to allow safe usage of stream altering commands
+    such as `SetPixelFormat`_.
+
+    If **BlockAfter** is set then that synchronisation must be relaxed
+    to allow processing of the following message. Any message after
+    that will still be affected by both flags though.
+
+**Request**
+    Indicates that this is a new request and that a response is
+    expected. If this bit is cleared then this message is a response to
+    an earlier request.
+
+The client can also include a chunk of data to differentiate between
+responses and to avoid keeping state. This data is specified using
+*length* and *payload*. The size of this data is limited to 64 bytes in
+order to minimise the disturbance to highly parallel clients and
+servers.
+
 xvp Client Message
 ------------------
 
@@ -1723,7 +1792,7 @@
 128         Car Connectivity
 150         `EndOfContinuousUpdates`_
 173 [#off]_ ServerState
-248         ServerFence
+248         `ServerFence`_
 249         OLIVE Call Control
 250         `xvp Server Message`_
 252         tight
@@ -1856,6 +1925,25 @@
 1               ``U8``               150        *message-type*
 =============== ==================== ========== =======================
 
+ServerFence
+-----------
+
+A server supporting the *Fence* extension sends this to request a
+synchronisation of the data stream.
+
+=============== ==================== ========== =======================
+No. of bytes    Type                 [Value]    Description
+=============== ==================== ========== =======================
+1               ``U8``               248        *message-type*
+3                                               *padding*
+4               ``U32``                         *flags*
+1               ``U8``                          *length*
+*length*        ``U8`` array                    *payload*
+=============== ==================== ========== =======================
+
+The format and semantics is identical to `ClientFence`_, but with the
+roles of the client and server reversed.
+
 xvp Server Message
 ------------------
 
@@ -2041,6 +2129,7 @@
 -307         `DesktopName Pseudo-encoding`_
 -308         `ExtendedDesktopSize Pseudo-encoding`_
 -309         `xvp Pseudo-encoding`_
+-312         `Fence Pseudo-encoding`_
 -313         `ContinuousUpdates Pseudo-encoding`_
 -412 to -512 `JPEG Fine-Grained Quality Level Pseudo-encoding`_
 -763 to -768 `JPEG Subsampling Level Pseudo-encoding`_
@@ -2069,7 +2158,6 @@
 -306                        popa
 -310                        OLIVE Call Control
 -311                        ClientRedirect
--312                        Fence
 -523 to -528                Car Connectivity
 0x574d5600 to 0x574d56ff    VMWare
 0xc0a1e5ce                  ExtendedClipboard
@@ -3164,6 +3252,16 @@
 *xvp-message-code* of *XVP_INIT*.  This informs the client that it may
 then subsequently send messages of type `xvp Client Message`_.
 
+Fence Pseudo-encoding
+---------------------
+
+A client which requests the *Fence* pseudo-encoding is declaring that
+it supports and/or wishes to use the *Fence* extension. The server
+should send a `ServerFence`_ the first time it sees a ``SetEncodings``
+message with the *Fence* pseudo-encoding, in order to inform the client
+that this extension is supported. The message can use any flags or
+payload.
+
 ContinuousUpdates Pseudo-encoding
 ---------------------------------
 

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.

Revision: 4815
          http://tigervnc.svn.sourceforge.net/tigervnc/?rev=4815&view=rev
Author:   ossman_
Date:     2011-11-23 12:58:58 +0000 (Wed, 23 Nov 2011)
Log Message:
-----------
Update to latest IANA list

Signed-off-by: Pierre Ossman <ossman@...>

Modified Paths:
--------------
    rfbproto/rfbproto.rst

Modified: rfbproto/rfbproto.rst
===================================================================
--- rfbproto/rfbproto.rst	2011-11-22 07:42:35 UTC (rev 4814)
+++ rfbproto/rfbproto.rst	2011-11-23 12:58:58 UTC (rev 4815)
@@ -1791,7 +1791,7 @@
 127         VMWare
 128         Car Connectivity
 150         `EndOfContinuousUpdates`_
-173 [#off]_ ServerState
+173         ServerState
 248         `ServerFence`_
 249         OLIVE Call Control
 250         `xvp Server Message`_
@@ -1801,8 +1801,6 @@
 255         `QEMU Server Message`_
 =========== ===========================================================
 
-.. [#off] **Warning:** Not officially allocated
-
 The official, up-to-date list is maintained by IANA [#reg]_.
 
 Note that before sending a message with an optional message type a

This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.