On Mon, 4 May 2009 13:50:34 +0200
Pierre Ossman oss...@cendio.se wrote:
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 oss...@cendio.se
---
This version includes the restriction that a server may not send both a
DesktopSize and an ExtendedDesktopSize rectangle. It also mentions the
DesktopSize mess in the Screen Model chapter.
Lastly, I clarified the CopyRect behaviour in the Screen Model chapter.
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
Index: rfbproto.rst
===
--- rfbproto.rst (revision 3809)
+++ rfbproto.rst (working copy)
@@ -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, 127VMWare
253 `gii (General Input Interface) Client Message`_
252 tight
-251 Pierre Ossman SetDesktopSize
+251 `SetDesktopSize`_
250 Colin Dean xvp
=== ===
@@ -1043,6 +1093,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
