[rfbproto] [PATCH] Prepare document for extensions
To get things started, I though we could begin with a rather small patch. This prepares the document to be extended outside RealVNC's implementation. Primarily it changes some wording as to how extension numbers are allocated and clarifies which messages are mandatory. Since we have a version control system that doesn't allow arbitrary authors, I propose we use kernel style commit messages to keep some track of who has added what. --- 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 --- Index: rfbproto.rst === --- rfbproto.rst(revision 3792) +++ rfbproto.rst(working copy) @@ -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. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performa
Re: [rfbproto] [PATCH] Prepare document for extensions
On Wed, 29 Apr 2009 13:14:27 +0200 Pierre Ossman wrote: > To get things started, I though we could begin with a rather small > patch. This prepares the document to be extended outside RealVNC's > implementation. Primarily it changes some wording as to how extension > numbers are allocated and clarifies which messages are mandatory. > > Since we have a version control system that doesn't allow arbitrary > authors, I propose we use kernel style commit messages to keep some > track of who has added what. > --- No comments? Should I take that as an okay to commit? :) Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
[rfbproto] [PATCH] 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 --- Index: rfbproto.rst === --- rfbproto.rst(revision 3796) +++ rfbproto.rst(working copy) @@ -642,6 +642,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 -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Add gii extension (messages and pseudo-encoding)
cription > +=== == === > +1 ``U8`` 253*message-type* > +1 ``SUB_TYPE`` 0 or 128 *endian-and-sub-type* > +2 ``U16`` *length* > +``EVENT`` array *device-event* We need a size in the first column. Or use the other style in the document and write something along the lines of "followed by *length* bytes of ``EVENT`` entries". > +``PTR_MOVE_EVENT`` is: > + > +=== == === > +No. of bytesType [Value]Description > +=== == === > +1 ``U8`` 24 *event-size* > +1 ``U8`` 8 or 9 *event-type* > +2 ``U16`` *padding* > +4 ``U32`` *device-origin* > +4 ``S32`` *x* > +4 ``S32`` *y* > +4 ``S32`` *z* > +4 ``S32`` *wheel* > +=== == === > + What about mice with multiple wheels? Having a static number of axis was a bit short sighted. I guess a PTR_MOVE_EVENT_EX could be added in the future though. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
[rfbproto] [PATCH] Add README with guidelines
Document the guidelines for submitting patches and the style used in
the document.
Signed-off-by: Pierre Ossman
---
Index: README
===
--- README (revision 0)
+++ README (revision 0)
@@ -0,0 +1,68 @@
+This directory contains the RFB protocol specification. This is a
+community oriented version of the specification that RealVNC maintains
+and the purpose of this version is to be a complete description of the
+protocol including extensions.
+
+If you wish to discuss the protocol, or submit changes, do so on the
+rfbproto mailing list (tigervnc-rfbproto@lists.sourceforge.net).
+
+
+Submitting Patches
+--
+
+Patches should be made in the standard unified diff format (diff -u).
+You should also specify a one line description of the change, a longer
+description with the purpose of the changed, and a Signed-off-by line
+to keep track of who has modified the document.
+
+Also make sure you follow the style guidelines below.
+
+Example:
+
+Clarify how awesome RFB is
+
+It is not apparent in the document how awesome the RFB protocol is.
+Clarify this in the header so that new readers quickly get up to
+speed.
+
+Signed-off-by: John Doe
+---
+
+Index: rfbproto.rst
+===
+--- rfbproto.rst (revision 3796)
rfbproto.rst (working copy)
+@@ -13,6 +13,9 @@
+ Introduction
+
+
++RFB is the most awesome protocol ever invented and will solve every
++problem you've ever had!
++
+ RFB ("remote framebuffer") is a simple protocol for remote access to
+ graphical user interfaces. Because it works at the framebuffer level it
+ is applicable to all windowing systems and applications, including X11,
+
+
+Style Guidelines
+
+
+The document is written using the reStructuredText format. This gives
+us a readable text source, but still allows for easy conversion to
+other formats.
+
+In order to avoid wrapping in most contexts, lines should be no longer
+than 72 characters. The text is always left justified. Indentation is
+4 spaces and never any tabs.
+
+Keywords are marked with *emphasis* to make them easily distinguishable
+from the rest of the text. Every reference to a keyword should be
+marked.
+
+Types are marked using ``LITERAL`` and should be written in all
+upper case.
+
+Tables are written using the simple form and should be extended to fill
+up the full 72 character width. If the section the table is in is
+indented, then the table should also be indented. The width will be
+reduced in this case.
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
signature.asc
Description: PGP signature
--
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___
tigervnc-rfbproto mailing list
tigervnc-rfbproto@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Add README with guidelines
On Thu, 30 Apr 2009 15:02:30 +0200
Pierre Ossman wrote:
> Document the guidelines for submitting patches and the style used in
> the document.
>
> Signed-off-by: Pierre Ossman
> ---
Ooops, forgot the headings part. This is the intended patch:
Index: README
===
--- README (revision 0)
+++ README (revision 0)
@@ -0,0 +1,83 @@
+This directory contains the RFB protocol specification. This is a
+community oriented version of the specification that RealVNC maintains
+and the purpose of this version is to be a complete description of the
+protocol including extensions.
+
+If you wish to discuss the protocol, or submit changes, do so on the
+rfbproto mailing list (tigervnc-rfbproto@lists.sourceforge.net).
+
+
+Submitting Patches
+--
+
+Patches should be made in the standard unified diff format (diff -u).
+You should also specify a one line description of the change, a longer
+description with the purpose of the changed, and a Signed-off-by line
+to keep track of who has modified the document.
+
+Also make sure you follow the style guidelines below.
+
+Example:
+
+Clarify how awesome RFB is
+
+It is not apparent in the document how awesome the RFB protocol is.
+Clarify this in the header so that new readers quickly get up to
+speed.
+
+Signed-off-by: John Doe
+---
+
+Index: rfbproto.rst
+===
+--- rfbproto.rst (revision 3796)
rfbproto.rst (working copy)
+@@ -13,6 +13,9 @@
+ Introduction
+
+
++RFB is the most awesome protocol ever invented and will solve every
++problem you've ever had!
++
+ RFB ("remote framebuffer") is a simple protocol for remote access to
+ graphical user interfaces. Because it works at the framebuffer level it
+ is applicable to all windowing systems and applications, including X11,
+
+
+Style Guidelines
+
+
+The document is written using the reStructuredText format. This gives
+us a readable text source, but still allows for easy conversion to
+other formats.
+
+In order to avoid wrapping in most contexts, lines should be no longer
+than 72 characters. The text is always left justified. Indentation is
+4 spaces and never any tabs.
+
+Keywords are marked with *emphasis* to make them easily distinguishable
+from the rest of the text. Every reference to a keyword should be
+marked.
+
+Types are marked using ``LITERAL`` and should be written in all
+upper case.
+
+Tables are written using the simple form and should be extended to fill
+up the full 72 character width. If the section the table is in is
+indented, then the table should also be indented. The width will be
+reduced in this case.
+
+Headings use the following markers:
+
+Heading 1
+=
+
+Heading 2
++
+
+Heading 3
+-
+
+Heading 4
+~
+
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
signature.asc
Description: PGP signature
--
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___
tigervnc-rfbproto mailing list
tigervnc-rfbproto@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Clarify key autorepeat behaviour
On Thu, 30 Apr 2009 17:43:53 +0100 "Daniel P. Berrange" wrote: > On Thu, Apr 30, 2009 at 02:44:56PM +0200, Pierre Ossman wrote: > > 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. > > FWIW, gtk-vnc used to accidentally handle key repeat by sending > repeated "down" events with no corresponding up events. This > confused some servers, such that no they only registered the > first, and then ignored all following 'down' events. So we > switched GTK-VNC over to generating explict down+up events when > keyrepeating Tough luck unfortunately. There are already major clients of both versions, so the reality is that server will have to deal with it. The point of this patch was to clarify which is preferred so that we can steer new implementation in a desirable direction. > > It is also not, in general, possible to mandate that key repeat > takes place on the client. Where VNC the server is attached to > a X server / other desktop service, it might be possible to disable > server side repeat, but in the case of a VNC server attached to > a virtual machine this is impossible. The VNC server has no control > over how the X server inside the guest deals with key presses. > Indeed. The text was supposed to be read with RFC terminology in mind. I.e. the "should" is to be read as "to the extent possible, but deviations are allowed". From what I can tell, repeats are handled client side in the major clients out there today. And for clients that follow the behaviour of sending just "down" events, determining which events to ignore for a server that wants to do its own repeat is trivial. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Add README with guidelines
On Thu, 30 Apr 2009 18:07:13 +0100
"Daniel P. Berrange" wrote:
>
> I think this should re-iterate that before protocol changes/extensions
> can be accepted into the document, an official pseudo encoding, security
> type, or client/server message code must be allocated by Real VNC.
>
Good point. New version:
---
Document the guidelines for submitting patches and the style used in
the document.
Signed-off-by: Pierre Ossman
---
Index: README
===
--- README (revision 0)
+++ README (revision 0)
@@ -0,0 +1,87 @@
+This directory contains the RFB protocol specification. This is a
+community oriented version of the specification that RealVNC maintains
+and the purpose of this version is to be a complete description of the
+protocol including extensions.
+
+If you wish to discuss the protocol, or submit changes, do so on the
+rfbproto mailing list (tigervnc-rfbproto@lists.sourceforge.net).
+
+Note that before any new extensions can be added to the document, you
+must first obtain an official number allocation from RealVNC Ltd. You
+are very welcome to discuss your ideas before that though.
+
+
+Submitting Patches
+--
+
+Patches should be made in the standard unified diff format (diff -u).
+You should also specify a one line description of the change, a longer
+description with the purpose of the changed, and a Signed-off-by line
+to keep track of who has modified the document.
+
+Also make sure you follow the style guidelines below.
+
+Example:
+
+Clarify how awesome RFB is
+
+It is not apparent in the document how awesome the RFB protocol is.
+Clarify this in the header so that new readers quickly get up to
+speed.
+
+Signed-off-by: John Doe
+---
+
+Index: rfbproto.rst
+===
+--- rfbproto.rst (revision 3796)
rfbproto.rst (working copy)
+@@ -13,6 +13,9 @@
+ Introduction
+
+
++RFB is the most awesome protocol ever invented and will solve every
++problem you've ever had!
++
+ RFB ("remote framebuffer") is a simple protocol for remote access to
+ graphical user interfaces. Because it works at the framebuffer level it
+ is applicable to all windowing systems and applications, including X11,
+
+
+Style Guidelines
+
+
+The document is written using the reStructuredText format. This gives
+us a readable text source, but still allows for easy conversion to
+other formats.
+
+In order to avoid wrapping in most contexts, lines should be no longer
+than 72 characters. The text is always left justified. Indentation is
+4 spaces and never any tabs.
+
+Keywords are marked with *emphasis* to make them easily distinguishable
+from the rest of the text. Every reference to a keyword should be
+marked.
+
+Types are marked using ``LITERAL`` and should be written in all
+upper case.
+
+Tables are written using the simple form and should be extended to fill
+up the full 72 character width. If the section the table is in is
+indented, then the table should also be indented. The width will be
+reduced in this case.
+
+Headings use the following markers:
+
+Heading 1
+=
+
+Heading 2
++
+
+Heading 3
+-----
+
+Heading 4
+~
+
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
signature.asc
Description: PGP signature
--
Register Now & Save for Velocity, the Web Performance & Operations
Conference from O'Reilly Media. Velocity features a full day of
expert-led, hands-on workshops and two days of sessions from industry
leaders in dedicated Performance & Operations tracks. Use code vel09scf
and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___
tigervnc-rfbproto mailing list
tigervnc-rfbproto@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Add gii extension (messages and pseudo-encoding)
On Thu, 30 Apr 2009 15:53:42 +0200 Peter Rosin wrote: > Den 2009-04-30 15:44 skrev Peter Rosin: > > ChangeLog: > > Document the General Input Interface (gii) extension. > > > > Signed-off-by: Peter Rosin > > > > Oh crap, I managed to skip a couple of U16 -> EU16 changes... > > Here's another update and sorry for the noise. > > Cheers, > Peter > > ChangeLog: > Document the General Input Interface (gii) extension. > > Signed-off-by: Peter Rosin Looks good. So if noone objects, I'd like to commit this. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
[rfbproto] [PATCH] 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 -- 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 3796) +++ rfbproto.rst (working copy) @@ -1310,10 +1310,41 @@ 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 -width and height of the framebuffer. There is no further data -associated with the pseudo-rectangle. +and/or height. +The server changes the desktop size by sending a pseudo-rectangle with +the *DesktopSize* pseudo-encoding. The update containing the +pseudo-rectangle must not contain any rectangles that change the +framebuffer data. + +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 old framebuffer data does not need to be preserved when the +framebuffer changes size. The server must therefore not use any +encoding that relies on the previous contents of the framebuffer. + +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 will temporarily be +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. + +Note that some early implementations require the *DesktopSize* +pseudo-rectangle to be the very last rectangle in an update. Servers +should make every effort to support these. + +Also note that some servers send framebuffer data changes before the +*DesktopSize* pseudo-rectangle. A client that wishes to be compatible +with these servers must either retain the framebuffer contents as the +dimensions change, or make sure that the next +*FrameBufferUpdateRequest* has *incremental* set to zero. + +As some clients send a *FramebufferUpdateRequest* with *incremental* +set to zero, because of the issue above, the server must not send a new +*DesktopSize* pseudo-rectangle in the following update. Doing so would +make the system go into an infinite loop. + signature.asc Description: PGP signature -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
[rfbproto] [PATCH] 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 -- 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 3796) +++ rfbproto.rst (working copy) @@ -69,6 +69,53 @@ 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. + +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 and the +client should request a full update. Note that this means that +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 == @@ -497,7 +544,7 @@ 254, 127VMWare 253 gii 252 tight -251 Pierre Ossman SetDesktopSize +251 SetDesktopSize 250 Colin Dean xvp === === @@ -770,6 +817,72 @@ *length*``U8`` array*text* === == === +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 a
Re: [rfbproto] [PATCH] Clarify DesktopSize behaviour
On Mon, 04 May 2009 16:09:24 +0200 Peter Rosin wrote: > Den 2009-05-04 13:49 skrev Pierre Ossman: > > +The server changes the desktop size by sending a pseudo-rectangle with > > +the *DesktopSize* pseudo-encoding. The update containing the > > +pseudo-rectangle must not contain any rectangles that change the > > +framebuffer data. > > I think "must not" is out of line in this paragraph, you even describe > servers not doing it that way in the ending notes... The correct thing > to say is "should not" IMHO. > Perhaps. I could only find a single server that implements it this way though, so I was hoping a strong wording would avoid any more. :) > > +Also note that some servers send framebuffer data changes before the > > +*DesktopSize* pseudo-rectangle. A client that wishes to be compatible > > +with these servers must either retain the framebuffer contents as the > > +dimensions change, or make sure that the next > > +*FrameBufferUpdateRequest* has *incremental* set to zero. > > Are you really certain about how you should interpret the fb-changing > rects leading up to the DesktopSize rect? There are bound to exist > servers that in some cases push out some pending totally superfluous > "dirty" rects before a final DesktopSize rect in an update. Heck, if you > combine with LastRect, the server might not even be aware of the fact > that it is about to send a DesktopSize rect at the end of the update > when it starts to generate it. I suppose there is some value to allow harmless noise before the DesktopSize, but there is a risk that we'll see more people implement it like RealVNC. See below... > > In my reading of the spec, I have always thought that those initial > rects where supposed to be applied before the change in desktop size, > but maybe that's just me. I wouldn't bet on that though. > That would make sense, wouldn't it. :) Unfortunately that's not how RealVNC is implemented. It will send a bunch of updates followed by the DesktopSize, when those updates actually happened after the server resized the framebuffer. This is incompatible with all clients derived from Tight (which is the original implementation of this extension AFAICT) which throw away the framebuffer upon seeing a DesktopSize. > Buttom line is, the only sensible thing for a client to do in response > to a DesktopSize rect is to always make a non-incremental FBU request > in order to not rely on some server-specific quirk. It can't know if > the server has retained the fb or not, so it has to make the non-incr > FBU request to get to a known state. Only UltraVNC sends a non-incr FUR. RealVNC, Tight and gtk-vnc all continue to send incremental FUR (from what I can tell from my reading of the code at least, feel free to object if this is wrong). Unless we want a convoluted specification where the requirements on the server and client do not match up in a symmetrical manner, we need to select on one model and declare the other one a buggy exception. There is the RealVNC model where the client keeps the framebuffer, or the Tight model where the client throws it away. The latter is the simpler and more common one. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now & Save for Velocity, the Web Performance & Operations Conference from O'Reilly Media. Velocity features a full day of expert-led, hands-on workshops and two days of sessions from industry leaders in dedicated Performance & Operations tracks. Use code vel09scf and Save an extra 15% before 5/3. http://p.sf.net/sfu/velocityconf___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Add gii extension (messages and pseudo-encoding)
On Mon, 4 May 2009 13:44:28 +0200 Pierre Ossman wrote: > On Thu, 30 Apr 2009 15:53:42 +0200 > Peter Rosin wrote: > > > Document the General Input Interface (gii) extension. > > > > Signed-off-by: Peter Rosin > > Looks good. So if noone objects, I'd like to commit this. > Done. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Add links from message and encoding lists
On Wed, 06 May 2009 09:13:02 +0200 Peter Rosin wrote: > Make it easier to navigate in hypertext versions of the document. > > Signed-off-by: Peter Rosin > Looks good. Applied. > diff --git a/rfbproto.rst b/rfbproto.rst I see there might be more supporters of moving this project to a sensible VCS in the future. ;) Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Add links from message and encoding lists
On Wed, 6 May 2009 09:32:19 +0100 "Daniel P. Berrange" wrote: > On Wed, May 06, 2009 at 09:13:02AM +0200, Peter Rosin wrote: > > Make it easier to navigate in hypertext versions of the document. > > > > Signed-off-by: Peter Rosin > > It'd be nice to get an HTML-ized version of the spec (automatically?) > published on the website based off RST source > I'd consider having it automatic to be more or less a requirement. Otherwise we'd have different versions saying different things. Does anyone know if you can add triggers for things like this on sourceforge? Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Add SASL security type
On Wed, 06 May 2009 10:23:55 +0200 Peter Rosin wrote: > It is official according to: > http://realvnc.com/pipermail/vnc-list/2008-December/059463.html > > I don't know why it's not in the official spec yet though. > > Signed-off-by: Peter Rosin > --- Also applied. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Add links from message and encoding lists
On Wed, 6 May 2009 09:32:19 +0100 "Daniel P. Berrange" wrote: > On Wed, May 06, 2009 at 09:13:02AM +0200, Peter Rosin wrote: > > Make it easier to navigate in hypertext versions of the document. > > > > Signed-off-by: Peter Rosin > > It'd be nice to get an HTML-ized version of the spec (automatically?) > published on the website based off RST source > I've managed to get this up and running now through a Python CGI script. Check the web page for URI. (Someone might want to make a nice CSS for it though ;)) Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] Describe the CoRRE encoding
On Fri, 08 May 2009 10:31:55 +0200 Peter Rosin wrote: > Describe the CoRRE encoding in terms of the RRE encoding. > > Signed-off-by: Peter Rosin > > Cheers, > Peter Applied. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the zlib encoding
On Fri, 08 May 2009 11:00:03 +0200 Peter Rosin wrote: > Describe the zlib encoding in terms of the Raw encoding. > > Signed-off-by: Peter Rosin > Also applied. > (I'm not all satisfied with the double reference to zlib...) Feel free to change it. I just copied the style from the original document in an effort to be as identical as possible. We're probably better off using a named reference. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Add quirk about the CPIXEL type
On Fri, 08 May 2009 11:31:51 +0200 Peter Rosin wrote: > 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 > Also applied. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the zlibhex encoding
On Fri, 08 May 2009 13:41:56 +0200 Peter Rosin wrote: > Describe the zlibhex encoding in terms of the hextile encoding. > > Signed-off-by: Peter Rosin > > (I'm not all satisfied with the double^Wtripple reference to zlib...) > > Cheers, > Peter > Applied. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Clarify DesktopSize behaviour
> +make the system go into an infinite loop. > > I think it's wrong to disallow all back-to-back uses of DesktopSize > rects. What we want to disallow are servers issuing an automatic > DesktopSize rect in response to each and every non-incr FBU request > they see Indeed. Alternative wording welcome. > (but that's an ExDesktopSize-ism that doesn't really apply > to plain old DesktopSize). > I'd say it does. The problem is that "non-incremental" is rather undefined when it comes to pseudo-encodings. Am I for example guaranteed to get a new "Cursor" rect on a non-incr FUR? It is quite possible that if I've discarded the FB that I've also dropped the cursor data. > (and I further think you should disallow sending DesktopSize > rects to a client that supports both DesktopSize and ExDesktopSize, > allowing both will just add complications without any gain). I figured that servers could get a bit simpler by not having to check both in combination, and clients need to have the logic to determine if the FB dimensions change anyway. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] ExtendedDesktopSize extension
On Wed, 06 May 2009 12:25:12 +0200 Peter Rosin wrote: > Den 2009-05-04 13:50 skrev Pierre Ossman: > > 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 > > Ok by me, it's your extension. > That sounds a bit like "this look like crap, but pff, what do I care?" :) If you have any suggestions, I'd like to hear them. E.g. do you think the "id" field will be sufficient to handle the case of a VNC server interfacing with real hardware? > > Oh, and I still think it would cleaner to hook into the tight > extension for the start-up difficulties. > I agree, but I'm concerned it will severely limit how many will implement it. We could redefine the behaviour in the future, given that the server and client have negotiated via some other mechanism (like tight). Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the Tight security type
On Thu, 07 May 2009 09:23:32 +0200 Peter Rosin wrote: > > I think this is accurate. > > Signed-off-by: Peter Rosin > I'm not sure that Constantin is subscribed unfortunately, but perhaps there are other Tight experts here that can have a look. I have one question though: > +where ``CAPABILITY`` is > + > +=== === === > +No. of bytesTypeDescription > +=== === === > +4 ``U32`` *code* > +4 ``U8`` array*vendor* > +8 ``U8`` array*signature* > +=== === === Why is there both a numerical code, and a string pair used to identify the extension? It seems a bit redundant. > + > +The following *encoding* capabilities are registered: > + > +=== = = === > +CodeVendorSignature 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 0 > +-223``TGHT`` ``NEWFBSIZ`` New FB Size > +-224``TGHT`` ``LASTRECT`` Last Rect > +-232``TGHT`` ``POINTPOS`` Pointer Position > +-239``TGHT`` ``RCHCURSR`` Rich Cursor > +-240``TGHT`` ``X11CURSR`` X Cursor > +-256``TGHT`` ``COMPRLVL`` Compression Level 0 > +-305``GGI_`` ``GII_`` `gii (General Input Interface) > +Pseudo-encoding`_ > +=== ===== ===== === Nit-picking, but code was defined as U32, not S32. :) Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
[rfbproto] [PATCH] 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 --- Index: rfbproto.rst === --- rfbproto.rst(revision 3809) +++ rfbproto.rst(working copy) @@ -637,6 +637,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 +1114,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 --- -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Clarify key autorepeat behaviour
This thread seems to have died off. Daniel, do you feel that your concerns have been addressed, or do we need more discussion? Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Clarify DesktopSize behaviour
It seems we agree that implementations should be done in a way that supports everything, we just need to agree on a wording that conveys that. :) On Thu, 14 May 2009 15:04:27 +0200 Peter Rosin wrote: > Den 2009-05-11 13:24 skrev Pierre Ossman: > > > > That was not my intention. The message was supposed to be "Don't do > > this, it's wrong, but be prepared that such implementations exist in > > the wild". > > > > Do you disagree with that message, or just how it's conveyed? > > I guess I disagree. I wish I could agree though, as it would simplify > things. I think the message should be "There is confusion on how to > interpret this message as the spec has been unclear for a long time. > To avoid this confusion, clients should respond with a non-incr FBU > request and servers should assume that clients need a full update > following an update with a DesktopSize rect." > Ok. What I'd like to include is some message of how it was originally meant to work. I find that it makes the system easier to understand, even if you have to go away from that "perfect" model to be compatible with reality. > > > > Or, what RealVNC's client does, move the old data over to the newly > > allocated framebuffer when it gets the DesktopSize. > > I have not looked at the implementation, but if your description is > accurate, they can't fill the whole FB (in that update) in case it is > growing. > Quite right, which sort of violates the principle that every update is a transition from one valid state to another. The client will get the missing pieces on the next update (even without non-incr as the first updated didn't have a request area that covered the entire, now larger, screen). > > > > Your assumption here that throwing away the FB means you have to send a > > non-incr. FUR is wrong. > > Not from the client side of things. If the client throws its FB away, it > should send a non-incr FBU request. IMHO of course. > I guess it comes down to how you interpret "...if for some reason the client has lost the contents...". The fact that we interpret it differently suggest we need to be explicit here. :) > > I think that RealVNC is quite special, given who is behind it > and who has written the spec. > To some extent, but I don't think they should have carte blanch to do silly (incompatible) things just because they happen to be sitting on the official spec. Does anyone have any numbers on the market share of different VNC implementations? > > That will occasionally mean we'll have to declare some implementations > > "buggy", but that's unavoidable. What we can do is mention those > > "buggy" implementations with suggested tweaks to stay compatible. > > We have forked the spec. If we don't stay compatible with the orig > spec, we will probably lose and will end up the bastard spec that, > like UltraVNC, is "not VNC-compatible". I thought of "our" spec as > a place to add extensions without any agenda to change the spec in > a way that invalidates valid existing interpretations. I agree fully and I did not intend to suggest otherwise. I have no desire for this to be another RFB spec, but rather _the_ RFB spec that covers every implementation. > > Well, I think it is confusing to have a spec that in detail describes > how it could work (but doesn't), and then has the description of what > is really working stuffed away in exception paragraphs. > > We should clarify how alternate (valid) implementations behave, then > go on to describe how to live with it. > I think we're at a point where we can only agree to disagree. I'm not religious about this, so if you feel strongly about it then I can live with your version. > > > > Indeed. Alternative wording welcome. > > Huh? I already suggested an alternate wording in my version > of the patch: > > As some clients send a *FramebufferUpdateRequest* with *incremental* > set to zero, because of the issue above, the server must not send a new > *DesktopSize* pseudo-rectangle as an automatic response to all > *FramebufferUpdateRequests* with *incremental* set to zero. Doing so > would make the system go into an infinite loop. > Oh, sorry. I completely missed that. :/ > > > > I'd say it does. The problem is that "non-incremental" is rather > > undefined when it comes to pseudo-encodings. Am I for example > > guaranteed to get a new "Cursor" rect on a non-incr FUR? It is quite > > possible that if I've discarded the FB that I've also dropped the > > cursor data. > > Since the spec says nothing on
Re: [rfbproto] [PATCH] ExtendedDesktopSize extension
On Thu, 14 May 2009 15:56:35 +0200 Peter Rosin wrote: > Den 2009-05-11 13:27 skrev Pierre Ossman: > > > > That sounds a bit like "this look like crap, but pff, what do I > > care?" :) > > Well, that's stretching it, but exactly one person has commented > (in public) on your encoding and you have shot down all > suggestions I have made (not counting editorial nitpicks). So, > what do you expect? > I can be a bit confrontational, but it was not my intention to put you off and I apologize if I've been too harsh. I really value your input to the discussion. Although I didn't incorporate you changes in this extension, I have been thinking about them and I think they should be added, but as separate extensions. As such, your comments have been very valuable to me. > >> Oh, and I still think it would cleaner to hook into the tight > >> extension for the start-up difficulties. > >> > > > > I agree, but I'm concerned it will severely limit how many will > > implement it. We could redefine the behaviour in the future, given > > that the server and client have negotiated via some other mechanism > > (like tight). > > No good, you would still need to keep the old code to cope with > the old style negotiation to stay compatible all the legacy > installations and the flourish of alternate implementations. I > predict that you will stick with whatever negotiation you start > out with. > We could avoid the extra roundtrip though, so there is some gain outside of the complexity. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] ExtendedDesktopSize extension
On Mon, 4 May 2009 13:50:34 +0200 Pierre Ossman 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 --- 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 +an *ExtendedD
[rfbproto] [PATCH] Clarify DesktopSize behaviour (v2)
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 --- This version tries to give some background to the problem, and separates client and server semantics to avoid confusion. I've used "should" everywhere, but we might want to use "must" if we want to present this text as _the_ way of implementing DesktopSize in a safe and compatible manner. Index: rfbproto.rst === --- rfbproto.rst(revision 3814) +++ rfbproto.rst(working copy) @@ -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 --------- -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] ExtendedDesktopSize extension
On Tue, 19 May 2009 15:45:54 +0200 Peter Rosin wrote: > Den 2009-05-15 12:20 skrev Pierre Ossman: > > Although I didn't incorporate you changes in this extension, I have > > been thinking about them and I think they should be added, but as > > separate extensions. As such, your comments have been very valuable to > > me. > > Only one of my suggestions qualifies as a separate extension. Or? > Two, the pixel format (WMVi replacement) and some way of telling the client possible configurations for SetDesktopSize. > When you say "separate extensions" I assume you are referring to > my WMVi/pixfmt suggestion. Since the only way to change the > server preference of the pixfmt is the WMVi encoding (either that > or reconnecting, bleah), let us see what it will lead to when you > are using both WMVi and EDS. > > The server will be the easy part to implement, so consider the > client impact (keep the client easy, remember): You have said > nothing about WMVi in the EDS spec, so the client has to assume > that a WMVi rect can appear at any point. The WMVi extension is not in the docs, so I don't think it would be appropriate to mention interactions with it yet. If it were, I'd add the same requirement that was originally there for DesktopSize; i.e. the information must not conflict. > 2) WMVi rect appears in an update without any EDS rect, the FB size > doesn't match the previous full FB size. > > Hmm, what to do. Stupid server. Drop all screens and show the > FB according to the WMVi rect I guess... > See above. > (case 3 - 6) We could mandate that a WMVi must never change the FB size if the client also supports EDS. Kind of how we forbid sending a DS if the client support EDS. > I see two problems for the client. It has to deal with the full > update as a single entity in order to do the combinations from > cases 3, 4 and 5. It is not possible to deal with updates on a > rect by rect basis. The FB pixfmt and the FB size are also > tightly coupled. Sure, on the typical windowed desktop you will > typically have 16 or 32 bits and not bother with anything else. > But if you have a client that can render directly into /dev/fb > (or equivalent), the available FB sizes are strongly dependent > on the desired pixfmt. For such a client it will be double work > to first find a good graphics mode using one pixfmt only to redo > it right away with a different pixfmt. The client will gain from > combining the EDS rect and the WMVi rect and it would be so much > easier if the two were combined into one rect from the server. I belive the problem is that WMVi is fundamentally broken. RFB is all about putting complexity at the server and letting the client use whatever formats it wants. As such, WMVi will always be a pain to handle for clients, What should be done is to have an extension where the server informs the client of the server pixfmt, not shoves it down the client's throat. A client can then decide on its own if it wants/can follow this change. > If you do specify when and how a WMVi rect may appear in the > presence of EDS rects, you will get away from many of the above > difficulties. My suggestion is to require that WMVi rects are > only sent alone or directly after an EDS rect and that FB > resizes using the WMVi message are disallowed (i.e. allow > cases 1 and 5). The important thing is to disallow cases 2, 3 > and 6, but I think you should disallow case 4 (and maybe even > case 1) while you have a chance. Agreed. :) > > > > We could avoid the extra roundtrip though, so there is some gain > > outside of the complexity. > > Are you worried about a few extra roundtrips during connection > setup? > When you put it that way, I guess not. :) Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Clarify FramebufferUpdateRequest/FramebufferUpdate behaviour
On Tue, 19 May 2009 15:50:47 +0200 Peter Rosin wrote: > > Maybe add something about the fact that it is not safe to send > SetPixelFormat messages when you have outstanding > FramebufferUpdateRequests? (which is important in the above > context...) > That was the scenario I was thinking of, yes. How about this addition to SetPixelFormat: 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. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Clarify DesktopSize behaviour (v2)
On Thu, 28 May 2009 14:09:45 +0200 Peter Rosin wrote: > Hi Pierre, > > Den 2009-05-28 13:34 skrev Pierre Ossman: > > 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 > > Excellent, please commit as far as I'm concerned. > Done. Thanks for all the feedback. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] ExtendedDesktopSize extension
On Thu, 28 May 2009 14:04:34 +0100 "Daniel P. Berrange" wrote: > On Thu, May 28, 2009 at 01:54:20PM +0200, Pierre Ossman wrote: > > > > I belive the problem is that WMVi is fundamentally broken. RFB is all > > about putting complexity at the server and letting the client use > > whatever formats it wants. As such, WMVi will always be a pain to > > handle for clients, > > > > What should be done is to have an extension where the server informs > > the client of the server pixfmt, not shoves it down the client's > > throat. A client can then decide on its own if it wants/can follow this > > change. > > IIUC, forcing it on the client is an explicit goal of this extension. > Historically the VNC server associated with a virtual machine has had > to maintain a duplicate copy of the video RAM, track changes between > the guest and what the VNC client has, and do pixel format conversions. > This imposes both a memory and CPU overhead on the host, which becomes > non-negligble with lots of guest machines running on a single host. This overhead exists if you have a classical terminal server based on VNC as well, so I think this is a problem that can be managed. Also, virtualisation already has a lot of overhead in a lot of areas. > > With the WMVi extension enabled, the VNC client is set to always have > its framebuffer in exactly the same format as the guest OS has. In > combination with elimination of the video RAM duplicate, the VNC server > now avoids the memory & CPU overheads, pushing these conversion out to > each individual client. > How do these server deal with clients that do not support the WMVi extension? Do they disconnect them upon seeing SetPixelFormat? > NB, this is assuming you have a low latency, high bandwidth link between > client & server, but that's not totally unreasonable given the goal of > this extension is to push resource utilization off the server to the > client - which is sort of an opposite goal to traditional VNC desktop > scenarios. As such it wouldn't make sense to recommend use of WMVi > extension for most VNC servers, where the more common goal is to keep > the overhead/complexity in the server. Probably not. But EDS is desirable on those servers if they want to export multi-head capabilities, so the combination of EDS and WMVi is not unreasonable. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] ExtendedDesktopSize extension
On Thu, 28 May 2009 14:26:42 +0200 Peter Rosin wrote: > > Maybe WMVi should be documented first then, so that there is no > window of opportunity for "bad" implementations, but it's probably > good enough if WMVi is documented soon(ish). > Didn't you point me to a somewhat decent description on some wiki? That should be fairly easy to clean up and merge. > > Let's commit the dang thing and worry about WMVi later... > Will do. :) Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Clarify FramebufferUpdateRequest/FramebufferUpdate behaviour
On Thu, 28 May 2009 14:12:18 +0200 Peter Rosin wrote: > Den 2009-05-28 13:58 skrev Pierre Ossman: > > > > That was the scenario I was thinking of, yes. How about this addition > > to SetPixelFormat: > > > > 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. > > Yes, please add that and commit as far as I'm concerned. > Great. Committed. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
On Wed, 27 May 2009 10:18:46 +0100 Colin Dean wrote: > > It would be really good if QEMU/KVM's VNC server supported this. > Can we agree on some naming, and then I'll submit a new patch. > > How about using "Xen VM control pseudo-encoding", "Xen VM control > client message" and "Xen VM control server message"? > Personally I think we should drop the Xen name completely (it could still be mentioned in the text as the origin though). Having something that sounds Xen-specific, even if it isn't, doesn't help adoption IMO. So my vote is "Virtual Machine Control ..." so that it's clear what this extension does even from just the name. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Don't spell out General Input Interface in every heading.
On Thu, 28 May 2009 15:05:11 +0200 Peter Rosin wrote: > Also add some introductory text to each chapter involving gii. > > Signed-off-by: Peter Rosin > Looks ok to me. Applied. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the Tight security type
On Thu, 28 May 2009 15:55:02 +0200 Peter Rosin wrote: > Den 2009-05-11 13:35 skrev Pierre Ossman: > > Why is there both a numerical code, and a string pair used to identify > > the extension? It seems a bit redundant. > > Once upon a time I asked about related things on the tight list: > http://www.nabble.com/Tight-protocol-extension---clarification-needed-td15063207.html > I see. Could something short about that be added to the spec perhaps to avoid confusion in the future? > > > > Nit-picking, but code was defined as U32, not S32. :) > > Yes, code is defined as unsigned by tight, but I feel that > it should be filled with the encoding value, not its unsigned > hexadecimal representation as is used by the tight team. > > I'd much rather have the same list here as in the SetEncodings > message and live with the S32/U32 mismatch... Agreed, but I think we can define the code field to be S32 as it's clearly meant to overlap the encodings list. > Here's a new version or the patch, with politics moved to the > README file, links added for encodings documented since last > time and the previously missing extension to the SecurityResult > message added. Shouldn't the politics section be in the spec.? I don't think we can expect the README to properly accompany the spec as it moves around the net. > > BTW, you may compare my spec with this one: > http://vnc-tight.svn.sf.net/viewvc/vnc-tight/trunk/doc/rfbtight.odt > > Beware, there are errors in that document. Some are obvious (the > document doesn't make sense) but one major fault is that it lacks > the 2 padding bytes between the number of encodings and the list > of server message types in the "Capabilities negotiation" chapter. > I tried looking at that thing and it just made me queasy. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Clarify key autorepeat behaviour
On Mon, 11 May 2009 13:59:51 +0200 Pierre Ossman wrote: > This thread seems to have died off. > > Daniel, do you feel that your concerns have been addressed, or do we > need more discussion? > *ping* -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Clarify key autorepeat behaviour
On Thu, 28 May 2009 17:00:56 +0100 "Daniel P. Berrange" wrote: > On Mon, May 11, 2009 at 01:59:51PM +0200, Pierre Ossman wrote: > > This thread seems to have died off. > > > > Daniel, do you feel that your concerns have been addressed, or do we > > need more discussion? > > I'm fine with the principle that key repeat should be generated client > side, but I'm not convinced that clients should send a series of > down-down-down events without agreeing this behaviour with the server. > Servers have to deal with this anyway given that the Windows vncviewer in both version 3 and 4 of RealVNC uses this behaviour, and almost every VNC implementation derives from these. Also, given the dominance of the Windows platform, I'd say the absolute majority of all VNC sessions will already be using this method. So us stating that it is the preferred mode is only documenting reality as it already is. What server was it that mishandled this sequence? Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
On Fri, 29 May 2009 07:29:40 +0100 "DEAN C.C." wrote: > That sounds like a perfectly good description, Peter. > > Pierre: would you be happy if I changed all occurrences of "(Xen VNC > Proxy)" in my patch to "(eXtension for Virtual machine Power options)"? > It's a lot more generic, so yes. Although I don't think that it would be a problem to loose the connect to the XVP acronym and avoid this convoluted backronym. I don't think people will be that confused by different names in RealVNC's and our spec. :) Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the DesktopName pseudo-encoding
On Thu, 28 May 2009 23:36:32 +0200 Peter Rosin wrote: > 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 > The only thing I'm missing is what encoding to use. The original thread really didn't come to a decent conclusion. Has anyone done a survey of how implementations treat this extension and the name field in the server init? If there are no existing implementations that prevent it, then I'd like to specify UTF-8 for at least the extension. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the Tight security type
On Thu, 28 May 2009 21:56:24 +0200 Peter Rosin wrote: > > Added short text about this, changed *code* to S32 (with a note) and > moved the "politics" back into the main document from the README. And > some nit-picking editorials. > > Also diffed against trunk this time... > > So, 3rd attempt. > > Cheers, > Peter > > --- > Information collected from the rfbproto.h header and the registered-codes.txt > document from the TightVNC project. > > Signed-off-by: Peter Rosin Looks good to me. Perhaps we should add quotes to the capability strings though so there is no confusion with types? This is how it's done for the version handshake. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Fix grammar in gii Server Message description
On Thu, 28 May 2009 21:58:27 +0200 Peter Rosin wrote: > Signed-off-by: Peter Rosin > > Cheers, > Peter Applied. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the Tight security type
On Fri, 29 May 2009 12:19:17 +0200 Peter Rosin wrote: > Den 2009-05-29 11:00 skrev Pierre Ossman: > > > > Looks good to me. Perhaps we should add quotes to the capability > > strings though so there is no confusion with types? This is how it's > > done for the version handshake. > > I see your point, 4th round... > Applied. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Clarify key autorepeat behaviour
On Fri, 29 May 2009 15:12:22 +0100 "Daniel P. Berrange" wrote: > > Reality sucks :-( I've no objection to comitting this doc though Hopefully we can reduce the suckiness of reality with all of this common documentation. :) > > What server was it that mishandled this sequence? > > It was in the interaction between QEMU and the emulated guest OS' key > handling > I see. Some might consider it a feature that the guest only sees the "real" key events. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Clarify DesktopSize behaviour (v2)
Aw, crap. Somehow one paragraph got lost in the patch. I'd like to apply the following: Index: rfbproto.rst === --- rfbproto.rst(revision 3823) +++ rfbproto.rst(working copy) @@ -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. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] ExtendedDesktopSize extension
On Fri, 29 May 2009 12:51:48 +0200 Peter Rosin wrote: > > The only drawback I can think of is that some server might > not respond at all to empty update requests, even if non- > incremental, and then you'd end up not nowing if you have > one or two outstanding FBU requests and then it's not 100% > safe to issue a change in pixfmt. > > Have I missed something obvious? > Sounds about right. But as you point out, the behaviour of an empty FUR is a bit unknown. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] ExtendedDesktopSize extension
On Fri, 29 May 2009 17:35:30 +0200 Peter Rosin wrote: > > And it's of course a hell of a mess for no real gain. Loads > easier to just have the server issue the requested pseudo-rect > in its first update, regardless of how the request looks. > > What was I thinking? > Apparently the same as the rest of us as nobody else noticed it either. ;) Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
On Fri, 29 May 2009 21:41:22 +0100 Colin Dean wrote: > > I suggest just stick with "xvp", which is what it's been called up to > now. After all, it could be applied to systems other than virtual > machines, so having a name with "virtual machine" in it is unnecessarily > restrictive. > A very good point. So something along the lines of "Power Control Pseudo-encoding" then. :) I won't veto this addition based on the name, but I strongly believe that we should make every effort to produce general extensions so that we don't end up with multiple almost identical ones. > +xvp Server Message > +-- > + > +This has the following format: > + > +=== == === > +No. of bytesType [Value]Description > +=== == === > +1 ``U8`` 250*message-type* > +1 *padding* > +1 ``U8`` 1 *xvp-extension-version* > +1 ``U8`` *xvp-message-code* > +=== == === How should the client react if it sees a higher version number? > +See http://www.dur.ac.uk/c.c.dean/xvp/ for details of the reference > +implementation, which allows shutdown, reboot and reset of virtual > +machines running on Citrix XenServer. Does this page add anything to the protocol definition? We don't have official reference implementations for anything else, so I'm sceptical about adding one here. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Clarify DesktopSize behaviour (v2)
On Fri, 29 May 2009 17:30:40 +0200 Peter Rosin wrote: > > Ok by me, if you also remove the two trailing spaces you > added after the first paragraph under the DesktopSize > Pseudo-encoding (line 2116) :-) I shall be sporting a fancy new brown paper bag for the remainder of the week. > > If you want whitespace nits in a special commit there is > also an extra line at the end of the document that may (or > should, depending on your mood) be removed... > Consider it gone. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
[rfbproto] [PATCH] Add Makefile
Targets for generating a PDF and a HTML page. Signed-off-by: Pierre Ossman --- Index: Makefile === --- Makefile(revision 0) +++ Makefile(revision 0) @@ -0,0 +1,14 @@ +all: rfbproto.pdf rfbproto.html + +.SUFFIXES : .rst .pdf .html + +.rst.pdf: + mkdir -p tmp + rst2newlatex "$<" tmp/tmp.tex + (cd tmp; pdflatex tmp.tex) + # We need to run it twice for links and TOC to work + (cd tmp; pdflatex tmp.tex) + mv tmp/tmp.pdf "$@" + +.rst.html: + rst2html "$<" "$@" -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Add Makefile
On Mon, 01 Jun 2009 13:17:17 +0200 Peter Rosin wrote: > > Those are spelled rst2newlatex.py and rst2html.py on my system. > What are their canonical names? > Upstream uses the .py suffix. Annoying... I guess we need to do something clever here. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
On Mon, 01 Jun 2009 12:51:13 +0100 Colin Dean wrote: > >> +See http://www.dur.ac.uk/c.c.dean/xvp/ for details of the reference > >> +implementation, which allows shutdown, reboot and reset of virtual > >> +machines running on Citrix XenServer. > > > > Does this page add anything to the protocol definition? We don't have > > official reference implementations for anything else, so I'm sceptical > > about adding one here. > > ... I put this wording in at Daniel's suggestion. > This discussion must have been off-list, or on some other list, so I'm not aware of the idea here. Do we want to start adding official reference implementations? I'd rather we try to make the spec good enough on its own and solve any ambiguities on a case-by-case manner. Reference implementations are a cop-out IMO. > Can I suggest we probably have spent enough time on this thread (!) and > ask somebody to sign off and apply my most recent patch (from Friday > evening)? We can drop the naming discussion. But I think the above issue needs to be resolved, as does the issue of how future version numbers should be handled. Since it's just you and Peter Rosin who have implemented this extension, I'd say you're in a best position to specify the handling so that it doesn't break anything existing. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the xvp extension
On Wed, 03 Jun 2009 23:17:44 +0100 Colin Dean wrote: > > > > This discussion must have been off-list, or on some other list, so I'm > > not aware of the idea here. > > Daniel's suggestion on this list, 27 May: > > http://sourceforge.net/mailarchive/message.php?msg_name=20090527095936.GA31980%40berrange.com > Hmm... The reference was present already in your original patch though, albeit in a different form. > However, I have now removed the offending paragraph. > Ok. We can leave that discussion for a later time then. > > We can drop the naming discussion. But I think the above issue needs to > > be resolved, as does the issue of how future version numbers should be > > handled. Since it's just you and Peter Rosin who have implemented this > > extension, I'd say you're in a best position to specify the handling so > > that it doesn't break anything existing. > > In the attached patch, I have attempted to address version numbering > (see the server message description). > Looks very nice. I've applied the patch. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Add Makefile
On Mon, 1 Jun 2009 14:30:55 +0200 Pierre Ossman wrote: > On Mon, 01 Jun 2009 13:17:17 +0200 > Peter Rosin wrote: > > > > > Those are spelled rst2newlatex.py and rst2html.py on my system. > > What are their canonical names? > > > > Upstream uses the .py suffix. Annoying... > > I guess we need to do something clever here. > How about this: Index: rsttool === --- rsttool (revision 0) +++ rsttool (revision 0) @@ -0,0 +1,28 @@ +#!/bin/bash +# +# This is a small wrapper to work around the fact that the +# docutils tools are named differently in different distributions. +# + +if [ $# -lt 1 ]; then + echo "Syntax:" + echo "$0 [args...]" + exit 1 +fi + +TOOL="$1" +shift + +# Upstream name +if type -t "$TOOL.py" > /dev/null; then + exec "$TOOL.py" "$@" +fi + +# "Santised" name +if type -t "$TOOL" > /dev/null; then + exec "$TOOL" "$@" +fi + +echo docutils tool $TOOL could not be found +exit 1 + Property changes on: rsttool ___ Added: svn:executable + * Index: Makefile === --- Makefile(revision 0) +++ Makefile(revision 0) @@ -0,0 +1,14 @@ +all: rfbproto.pdf rfbproto.html + +.SUFFIXES : .rst .pdf .html + +.rst.pdf: + mkdir -p tmp + ./rsttool rst2newlatex "$<" tmp/tmp.tex + (cd tmp; pdflatex tmp.tex) + # We need to run it twice for links and TOC to work + (cd tmp; pdflatex tmp.tex) + mv tmp/tmp.pdf "$@" + +.rst.html: + ./rsttool rst2html "$<" "$@" -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the DesktopName pseudo-encoding
On Fri, 29 May 2009 10:51:14 +0200 Pierre Ossman wrote: > > Has anyone done a survey of how implementations treat this extension > and the name field in the server init? If there are no existing > implementations that prevent it, then I'd like to specify UTF-8 for at > least the extension. > I've been digging through the RealVNC source and string handling is just a complete clusterfuck. The implementation uses the all too familiar approach of sticking one's head in the sand and hoping that all encoding issues will just sort themselves out. This is the reality of things: 1. Unix server Uses whatever encoding the parameters are in when invoking Xvnc or vncconfig. Since most Linux distributions these days use UTF-8, so the desktop name will in turn mostly be UTF-8. 2. Windows server Uses the ACP (Active Code Page). Can really be a lot of things, though most often cp1252 (almost 8859-1) in the west. 3. Unix client Passes the string unmodified to XSetName(). Looking at the xlib reference documentation, this uses "Host Portable Character Encoding" which in turn uses a lot of weasel wording and doesn't really define that much at all. Looking at the ICCCM though and how xlib implementations behave in practice, this encoding is 8859-1. IOW, the Unix client assumes the name is in 8859-1. 4. Window client Like the Windows server, it assumes that things are in ACP. So to summarise, the only part that has some idea of what encoding it wants is the Unix client. Everything else is basically random and dependent on the system settings. ASCII should be fairly safe to use, but I'm not 100% sure of even that. Given that most of the systems (except for the Unix server) have been using 8859-1 (or cp1252, which is close) in practice, I'd say we define the desktop name to be 8859-1 and nothing else. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the DesktopName pseudo-encoding
Just for fun, I had a quick look at the clipboard handling. The situation is better there with the Unix side handling things correctly. Windows however is broken and assumes that the local system uses a superset of 8859-1. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Add Makefile
On Thu, 11 Jun 2009 10:07:01 +0200 Peter Rosin wrote: > > Hi Pierre, > > Sorry for the delay, I was on vacation... > > That works for me (if you lose the trailing newline in rsttool :-) > Will do. ;) Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the DesktopName pseudo-encoding
On Fri, 12 Jun 2009 16:44:46 +0200 Peter Rosin wrote: > > RealVNC didn't recommend that the clipboard text in the *CutText messages > and the string in the ServerInit message should be UTF-8, did they? > Probably not. And to make things more interesting, older versions of the spec stated that the clipboard should be ASCII. It was extended to latin1 in 3.8, but I'm not sure any server or client properly handles backwards compatibility here. Anyway, I think we should ignore the clipboard for now. It needs a major upgrade anyway to support non-text data so I don't think we should think about it at all in this discussion. > I have no trouble having the string in the new DesktopName pseudo-encoding > always be UTF-8. It's all those other strings that currently is ASCII > only (or Latin-1 in the case of *CutText) if you want it to work properly. I think it can be worth the hassle of stating that ServerInit should be UTF-8. There will be some interoperability fallout, but the current implementations aren't properly interoperable as is so I think it's worth it for the long term gains. The things currently defined as ASCII are the version string and the error messages. I see no need to upgrade either of those to UTF-8. I don't support dropping connections on malformed UTF-8. There is no problem determining where the string ends, so there is no reason to terminate the connection. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the DesktopName pseudo-encoding
On Thu, 11 Jun 2009 10:38:45 +0200
Peter Rosin wrote:
> Den 2009-06-04 13:34 skrev Pierre Ossman:
> > 3. Unix client
> >
> > Passes the string unmodified to XSetName(). Looking at the xlib
> > reference documentation, this uses "Host Portable Character Encoding"
> > which in turn uses a lot of weasel wording and doesn't really define
> > that much at all. Looking at the ICCCM though and how xlib
> > implementations behave in practice, this encoding is 8859-1.
> >
> > IOW, the Unix client assumes the name is in 8859-1.
>
> s/XSetName/XStoreName/ ???
>
> On the contrary, it's rather clearly specified as "the set of
> graphic characters in 7-bit ASCII plus [space, tab and newline]".
>
> The graphic characters being:
> a..z A..Z 0..9 !"#$%&'()*+,-./:;<=>?...@[\]^_`{|}~
>
> However, what values these characters have is not specified. Assuming
> something ASCII compatible is the only sane choise. My point is that
> ASCII is much closer than ISO 8859-1.
>
Unfortunately you cannot assume the encoding, so it's more or less
undefined. The ICCCM however states:
"The WM_NAME property is an uninterpreted string that the client wants
the window manager to display in association with the window (for
example, in a window headline bar).
The encoding used for this string (and all other uninterpreted string
properties) is implied by the type of the property. The type atoms to
be used for this purpose are described in section 2.7.1."
And all implementations use STRING as far as I can tell, which the
ICCCM describes as:
"STRING as a type or a target specifies the ISO Latin-1 character set
plus the control characters TAB (octal 11) and NEWLINE (octal 12). The
spacing interpretation of TAB is context dependent. Other ASCII control
characters are explicitly not included in STRING at the present time."
Rgds
--
Pierre OssmanOpenSource-based Thin Client Technology
System Developer Telephone: +46-13-21 46 00
Cendio ABWeb: http://www.cendio.com
signature.asc
Description: PGP signature
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects___
tigervnc-rfbproto mailing list
tigervnc-rfbproto@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH 1/5]: Rearrange described and registered encodings.
On Thu, 11 Jun 2009 13:28:54 +0200 Peter Rosin wrote: > Rearrange described and registered encodings. > > Signed-off-by: Peter Rosin I'm not convinced this is worth it. The style of this table severely deviates from all other tables in the document, and only to handle Tight's allocations. I'd rather have multiple lines with "Reserved for TightVNC" than change the layout of the entire table. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH 2/5]: Describe the Tight Compression Level Pseudo-encoding.
On Thu, 11 Jun 2009 13:29:42 +0200 Peter Rosin wrote: > +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. > + Perhaps we should specify what low and high means a little more clearly. Like that fact that this controls lossless compression, so it's primarily a tradeoff between CPU time and bandwidth. And should we reserve these settings to only Tight or encourage others to use it? I think this can be used more broadly, but I think we need to be more verbose in its description for that. And I also think this should just be a hint to the server, not a requirement. Since we do not specify exactly what the levels mean, I don't see how it can be anything other than a hint. Either way, I think these things should be mentioned. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH 3/5]: Describe the Tight LastRect Pseudo-encoding.
On Thu, 11 Jun 2009 13:30:09 +0200 Peter Rosin wrote: > +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. > + Isn't it required to state 65535 rectangles? And we might want to make a note of this in the FramebufferUpdate section. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH 4/5]: Describe the Tight Encoding.
tes one bit, xxx are the least > +significant 7 bits of the value (bits 0-6), yyy are bits 7-13, > +and are the most significant 8 bits (bits 14-21). For > +example, decimal value 1 should be represented as two bytes: > +binary 1001 01001110, or hexadecimal 90 4E. > + I suspect the Tight project never properly specified this, but what restrictions are placed on the JPEG data? We should at the very least mention that it is a standard JFIF data stream. And if we cannot properly specify the JPEG restrictions, we should mention that the area is a bit grey. > +.. [NOTE3] The "gradient" filter and "jpeg" compression may be used > +only when bits-per-pixel value is either 16 or 32, not 8. Again, is this a hard requirement? > + > +.. [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. Dito. Also, using footnotes without any reference in the text seems wrong. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH 3/5]: Describe the Tight LastRect Pseudo-encoding.
On Tue, 16 Jun 2009 16:19:18 +0200 Peter Rosin wrote: > > > > Isn't it required to state 65535 rectangles? > > Don't think so. I think a LastRect simply terminates the rect loop, > and I don't think there is any way to send more than 65535 rects. > It has to be larger than the actual number of rects though. You can't send an FU with 4 rects in the header and then have 20 rects with a LastRect at the end. > > And we might want to make a note of this in the FramebufferUpdate > > section. > > There is one. :-) > > +See the `LastRect Pseudo-encoding`_ for an extension to this message. > I completely missed that. :) You might want to expand on that paragraph though and mention that LastRect means that the rect count might be something other than that stated. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH 4/5]: Describe the Tight Encoding.
On Tue, 16 Jun 2009 16:22:27 +0200 Peter Rosin wrote: > > So, again, I think all these deficiencies should be fixed in a followup > commit (or commits)... > Fair enough. Could you prepare those changes though so this isn't one of those things that gets overlooked and forgotten? Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH 5/5]: Describe the Tight JPEG Quality Level Pseudo-encoding.
On Tue, 16 Jun 2009 16:24:07 +0200 Peter Rosin wrote: > Den 2009-06-16 14:00 skrev Pierre Ossman: > > And do we want to make this a generic extension? Perhaps call it "Lossy > > Quality Level..." instead? > > I don't think we should rename it, but the ZYWRLE encoding reuses this > pseudo-encoding... > If that encoding doesn't use JPEG (which I suspect it doesn't), then that supports renaming the extension to something more generic. I'm not sure how useful these settings are though when their meaning is so undefined... Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH 5/5]: Describe the Tight JPEG Quality Level Pseudo-encoding.
On Thu, 11 Jun 2009 13:31:09 +0200 Peter Rosin wrote: > +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`_. > + What does "quality" mean though? I'd say it's very undefined, but that fact in itself should be mentioned. And do we want to make this a generic extension? Perhaps call it "Lossy Quality Level..." instead? Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH 5/5]: Describe the Tight JPEG Quality Level Pseudo-encoding.
On Tue, 16 Jun 2009 18:53:58 +0200 Peter Rosin wrote: > > The reason I'm not backing the name change is that the one registering > the encoding gets to decide the name, IMHO. And the zywrle (ab)use > should not interfere with that. > Fair enough. > The main problem is that I suspect that the tight levels have been > experimented with a lot so that you get a good tradeoff in most > situations. You'd think. Unfortunately that's not the case, so we changed the levels in Tiger to something that made more sense from a compression ratio point of view. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH 0/6] Tight: Describe various encodings. v2
On Wed, 17 Jun 2009 10:46:46 +0200 Peter Rosin wrote: > Hello, > > Some more encoding descriptions: > > [PATCH 1/6]: Rearrange described and registered encodings. > [PATCH 2/6]: Describe the Tight Compression Level Pseudo-encoding. > [PATCH 3/6]: Describe the Tight LastRect Pseudo-encoding. > [PATCH 4/6]: Describe the Tight Encoding. > [PATCH 5/6]: Describe the Tight JPEG Quality Level Pseudo-encoding. > [PATCH 6/6]: Update Tight Encoding description to match guidelines. > > The encoding description in [PATCH 4/6] is "stolen" from the tight > docs... > Very nice work, I've committed all of it. I'd kill for git-am though :/ PS. you cannot have a blank line between the definition term and the description. Please have a look at the pdf output before you send the patches. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH 0/6] Tight: Describe various encodings. v2
On Wed, 17 Jun 2009 13:18:37 +0200 Peter Rosin wrote: > Den 2009-06-17 11:46 skrev Pierre Ossman: > > I'd kill for git-am though :/ > > So, why didn't you guys move to git when you forked tiger-vnc? tsk tsk :-) > We had to consider the elderly who had just managed to move from cvs to svn. ;) Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Describe the DesktopName pseudo-encoding. v2
On Wed, 17 Jun 2009 14:35:16 +0200 Peter Rosin wrote: > 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 > > > > I think we decided on UTF-8 *for this text* in that other > thread. So, I'm shortcutting the discussion on the > bigger problem with this updated patch... > Committed, thanks. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Crystal Reports - New Free Runtime and 30 Day Trial Check out the new simplified licensing option that enables unlimited royalty-free distribution of the report engine for externally facing server and web deployment. http://p.sf.net/sfu/businessobjects___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
[rfbproto] [PATCH] 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 --- Index: rfbproto.rst === --- rfbproto.rst(revision 3856) +++ rfbproto.rst(working copy) @@ -201,6 +201,26 @@ security types do not clash. Please see the RealVNC website at http://www.realvnc.com for details of how to contact them. +String Encodings + + +Strings in RFB should in general be encoded using the UTF-8 encoding. +This allows full unicode support, yet retains a good compatibility with +older systems and libraries. + +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. + +Clients and servers must send UTF-8 strings unless that particular part +of the protocol mandates another encoding. They should however be +prepared to receive invalid UTF-8 sequences at all times. Such +sequences should be handled gracefully by stripping the invalid +portions or trying to interpret the string using common encodings such +as ISO 8859-1 or Windows code page 1252. + Protocol Messages = @@ -614,7 +634,8 @@ *name-length* ``U8`` array*name-string* === === === -where ``PIXEL_FORMAT`` is +The text encoding used for *name-string* is UTF-8. ``PIXEL_FORMAT`` is +defined as: === === === No. of bytesTypeDescription -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Specify UTF-8 for strings
On Thu, 25 Jun 2009 15:38:09 +0200 Peter Rosin wrote: > I don't want this, sorry. This is an incompatible change. I think we > need to go with the common denominator (which is ASCII), then use some > kind of extension mechanism that changes over to UTF-8. Incompatible is a term that will have to be used loosly here. There is no compatibility here today as everyone is doing different things, so I don't see this move making things any worse. Would you feel different about things if there was a note stating that ASCII should be used for maximum compatibility, but retaining the preference for UTF-8? > If Real can be coaxed into doing the switch to UTF-8 w/o using an > extension for their free alternative, I'll reconsider. However, I > think that will be hard given the amount of love they spend on that > part of their offering. I'm not sure how their version will affect anything. Given the history, you can never be sure that this field will display correctly when using anything other than ASCII. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Specify UTF-8 for strings
On Fri, 26 Jun 2009 21:15:40 +0200 Peter Rosin wrote: > Den 2009-06-25 16:26 skrev Pierre Ossman: > > Incompatible is a term that will have to be used loosly here. There is > > no compatibility here today as everyone is doing different things, so I > > don't see this move making things any worse. > > I never answered this, so here I go. I'd be happier if it was > formulated more like a recommendation (a strong one if you > like) to use UTF-8 whereever the encoding was unclear. As the > patch is written it seems like an error to not use UTF-8. > > In particular this snippet is bad: "Clients and servers must > send UTF-8 strings". "Must" is just way too strong. > I originally wrote "should" there, but that gives the impression that things work fairly fine even without following this behaviour, which it doesn't. It's a rather odd situation we're in. Not having a defined encoding makes the strings nearly useless, which warrants a "must". But OTOH, that's how it is today and therefore a "should" would normally be appropriate. IMO it's better to have a strong "must" as all strings really need to have a defined encoding, but keep the historical note to warn against the horrible situation we're in with the current implementations. > I also think the second hunk of the patch should be left out > so that the string encoding is left unspecified and thus falls > back to the new "String Encodings" section (which of course > recommends UTF-8). It was for redundancy as I suspect many browse through the initial parts of the spec very quickly. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Specify UTF-8 for strings
We haven't seen anything of what Real thinks about this change. Wez expressed some desire to use UTF-8 in that older thread at lease. Wez, what's your take on this discussion? Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Specify UTF-8 for strings
On Mon, 29 Jun 2009 22:37:18 +0200 Peter Rosin wrote: > Den 2009-06-29 11:16 skrev Pierre Ossman: > > IMO it's better to have a strong "must" as all strings really need to > > have a defined encoding, but keep the historical note to warn against > > the horrible situation we're in with the current implementations. > > And I think "should" is also too strong. It should say that the > encoding *is* unspecified and that everybody "must" treat strings > with care because of this, and then go on to "strongly recommend" > everybody to use UTF-8 (as that's the only sane choice) or limit > themselves to ASCII if they are willing to trade usability for > portability. IMHO of course. > And here I though that this was what I was saying with my text. :) Do you have a preferred wording? Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Specify UTF-8 for strings
Can we please try to find some middle ground here. Is this text acceptable to everyone: 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. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
[rfbproto] [PATCH] Specify UTF-8 for strings (v2)
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 --- Index: rfbproto.rst === --- rfbproto.rst(revision 3887) +++ rfbproto.rst(working copy) @@ -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 bytesTypeDescription === === === -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] Specify UTF-8 for strings (v2)
There are still a couple of string issues remaining: - SecurityResult doesn't mention encoding for reason-string. It should probably be ASCII though, which is what is specified for reason-string in Security. - Tight's capability handshake uses something that looks like strings, but should be handled like opaque, 8 byte blobs (or so I'm assuming). Perhaps this should be clarified? - The GII stuff doesn't mention anything about encodings for its strings. If it's undefined then we should refer to the new encoding chapter. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] Align table in ServerInit message
On Thu, 08 Oct 2009 19:40:39 +0200 Peter Rosin wrote: > Hi! > > Found a minor whitespace glitch. > Applied. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] TRLE Encoding
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*. +For *paletteSize* of 2 this is div(*width* + 7, 8) * *height*, for +*paletteSize* of 3 or 4 this is div(*width* + 3, 4) * *height*, for +*paletteSize* of 5 to 16 this is div(*width* + 1, 2) * *height*. -17 to 127 -Unused (no advantage over palette RLE). +17 to 126 +Unused. (Packed palettes of these sizes would offer no advantage +over palette RLE). +127 +Packed palette with the palette reused from the previous tile. The +subencoding byte is followed by the packed pixels as described +above for packed palette types. + 128 Plain RLE. Consists of a number of runs, repeated until the tile is done. Runs may continue from the end of one row to the beginning of @@ -2344,10 +2342,12 @@ 1 ``U8`` (*runLength* - 1) % 255 === === === === -Where *r* is floor((*runLength* - 1) / 255). +Where *r* is div(*runLength* - 1, 255). 129 -Unused. +Palette RLE with the palette reused from the previous tile. +Followed by a number of runs, repeated until the tile is done, as +described below for 130 to 255. 130 to 255 Palette RLE. Followed by the palette, consisting of @@ -2359,9 +2359,9 @@ *paletteSize* * *bytesPerCPixel* ``CPIXEL`` array *palette* = == == -Then as with plain RLE, consists of a number of runs, repeated -until the tile is done. A run of length one is represented simply -by a palette index: +Following the palette is, as with plain RLE, of a number of runs, +repeated until the tile is done. A run of length one is +represented simply by a palette index: = == == No. of bytes Type Description @@ -2381,8 +2381,38 @@ 1 ``U8`` (*runLength* - 1) % 255 === === === === -Where *r* is floor((*runLength* - 1) / 255). +Where *r* is div(*runLength* - 1, 255). Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] New protocol number
On Thu, 08 Oct 2009 19:49:44 +0200 Peter Rosin wrote: > Hi! > > Adding a few new protocol numbers (MD5 hash and TurboVNC pseudo-encodings). > > Cheers, > Peter Also applied. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] Clarify lifetime rules for Hextile fg and bg colors
On Thu, 08 Oct 2009 20:02:14 +0200 Peter Rosin wrote: > Hi! > > Tristan Richardson said he was going to update the Internet > Draft with this clarification of the Hextile encoding in > a private response to a direct question from me. > > Cheers, > Peter This too. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] FYI: new proposed Tight encoding using PNG instead of JPEG
On Thu, 8 Jul 2010 10:45:13 +0100 "Daniel P. Berrange" wrote: > Of interest to folks on this list.. I've just noticed work on qemu-devel > proposing a new variant of the Tight framebuffer encoding that uses PNG > for compression instead of JPEG: > > http://lists.gnu.org/archive/html/qemu-devel/2010-07/msg00445.html > > "Tight PNG > == > This set introduce a new encoding: VNC_ENCODING_TIGHT_PNG [1] (-260) > and a new tight filter VNC_TIGHT_PNG (0x0A). When the client tells > it supports the -260 encoding, the server will use tight, but will > always send encoding pixels using PNG instead of zlib. If the client > also told it support JPEG, then the server can send JPEG, because > PNG will only be used in the cases zlib was used in normal tight. > > This encoding was introduced to speed up HTML5 based VNC clients like > noVNC but can also be used on devices like iPhone where PNG can be > rendered in hardware." > > > I know the encoding -260 has already been allocated for use by QEMU, > but I'm not sure who is maintaining the authority for tight filter > numbers & can thus records/approves the use of 0x0a ? Is the latter > something we should be doing here if no one else is an authority > for tight filters ? > I'd say it's the TightVNC people who are the authority to any changes to the Tight encoding. I'm not sure any of them are subscribed to this list though. I'm wondering why the integration into an existing encoding though? This extra layer of tight encodings on top of the normal encodings is just extra overhead and is not something that we should be promoting going forward. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com signature.asc Description: PGP signature -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] QEMU protocol extensions
On Fri, 16 Jul 2010 19:54:30 +0100 "Daniel P. Berrange" wrote: > This patch describes 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. > > These are all implemented by QEMU. GTK-VNC only implements the first > two so far, audio is work in progress > Hi Daniel, Thank you for this patch. Sorry about overlooking it until now. It's been committed to the repo. One clarification I'm curious about though; what should clients do if they don't know how to map a key to a XT scan code for a certain key? Picking something at random is probably not going to do wonders for interoperability. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] VeNCrypt security type specification
On Tue, 20 Jul 2010 10:31:09 +0200 Adam Tkac wrote: > > Next revision of VeNCrypt spec is attached. > Any chance of getting this documentation effort restarted/finished? Would be nice to have things finalised as this is a popular extension. :) Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] Provisional new XZ encoding
On Sat, 20 Nov 2010 15:13:14 -0500 Adam Walling wrote: > I'd like to announce a provisional new encoding: XZ. > Hi Adam, I'm sorry you haven't gotten much attention for your work. I'm afraid I don't have the time to look at this properly and give you some decent feedback either. :/ What I can do for you though, is to get documentation for this into the specification here. That might get your encoding some attention at least. If you have a formal description I can have a look at it and get it committed. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- What Every C/C++ and Fortran developer Should Know! Read this article and learn how Intel has extended the reach of its next-generation tools to help Windows* and Linux* C/C++ and Fortran developers boost performance applications - including clusters. http://p.sf.net/sfu/intel-dev2devmay___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
[rfbproto] 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 --- Index: rfbproto.rst === --- rfbproto.rst(revision 4429) +++ rfbproto.rst(working copy) @@ -1086,9 +1086,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 bytesType [Value]Description -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] New SecType request, call for reviews
On Wed, 25 May 2011 16:33:13 -0400 Brian Hinz wrote: > Hi, > > I was going to submit a request to RealVNC for an official allocation for a > new security type, but I wanted to run past you guys first for some > feedback. Basically it's an extension that allows a server side daemon to > act as a manager that just redirects clients to the port where user's > session is running (possibly spawning a new server as part of the process). > This makes administration easier by removing the need to keep files (ie: > /etc/sysconfig/vncservers, /etc/xinetd.d/Xvnc) synchronized between hosts. > In my case the daemon is written in perl and also allows users to change > preferences like geometry and depth in a ~/.vncrc file that the daemon > parses before spawning a new Xvnc session. Please let me know if you have > any suggestions. > The basic idea is a good one, but I'm wondering if this approach is too limited. Some features that might be desired further down the road: - Authentication before the server starts a new session and/or reveals information about it to the client. There are possible information security and denial of service issues here. - Redirection to another host > +=== === === > +No. of bytesTypeDescription > +=== === === > +1 ``U8`` *length of username* 256 bytes probably covers most user names, but I'd bet it doesn't cover all. For example, we've seen some cases where a LDAP dn is used as a user name and that can often exceed 256 bytes. Perhaps a U16 instead? > +*username-length* ``U8`` array*username-string* Given the history of RFB, you should probably be explicit with the encoding used here (UTF-8 if there is no massive reason for something else). Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] Fwd: pseudo encoding request
On Mon, 6 Jun 2011 08:36:13 -0400 Brian Hinz wrote: > FYI. I wasn't aware that the RFB protocol had been RFC'd. > A bit unfortunate, but not unexpected. We noticed the RFC work back before it was finalised and tried to get involved (as the work was based on the original RealVNC specification which we know has issues). Unfortunately we didn't get any attention, and it now seems we have an RFC which lacks a lot of important clarifications. :/ Anyone up for starting a new RFC with our improvements? :) Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] Fwd: pseudo encoding request
On Tue, 7 Jun 2011 08:02:34 -0400 Brian Hinz wrote: > Has anyone dealt with IANA yet? Are they not responsive? I would have > thought that having the specification controlled by someone that doesn't > necessarily have a vested interest in the protocol would be a good thing. It most certainly is. I was thinking about clarifications in the core protocol specification (e.g. the dangers of switching pixel format) though, not extensions. Those are in most cases probably better described in separate RFC:s. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- EditLive Enterprise is the world's most technically advanced content authoring tool. Experience the power of Track Changes, Inline Image Editing and ensure content is compliant with Accessibility Checking. http://p.sf.net/sfu/ephox-dev2dev___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
[rfbproto] Fixing RFB latency sensitivity
(Cross-posting to both tigervnc-devel and rfbproto as this is a general protocol issue, but tigervnc will be the playground for testing it) Hi, I'm looking at making VNC/RFB work better over high latency network. Right now we're limited to one update per RTT, which makes things rather unpleasant over many links. Things are still very much up in the air, but I've written down my thoughts so far and I'd appreciate any input you could give on it. You can find my notes here: https://sourceforge.net/apps/mediawiki/tigervnc/index.php?title=VNC_Latency_Considerations Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] Horizontal mouse wheel
No objections, so I'm committing this. On Tue, 24 May 2011 13:31:22 +0200 Pierre Ossman wrote: > 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 > --- > > Index: rfbproto.rst > === > --- rfbproto.rst (revision 4429) > +++ rfbproto.rst (working copy) > @@ -1086,9 +1086,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 bytesType [Value]Description > > -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
[rfbproto] [PATCH] 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 --- Index: rfbproto.rst === --- rfbproto.rst(revision 4741) +++ rfbproto.rst(working copy) @@ -828,8 +828,11 @@ 252 tight 251 `SetDesktopSize`_ 250 `xvp Client Message`_ +150 [#]_`EnableContinuousUpdates`_ === === +.. [#] **Warning:** Not officially allocated + Note that before sending a message with an optional message type a client must have determined that the server supports the relevant extension by receiving some extension-specific confirmation from the @@ -1621,7 +1624,46 @@ The *nchannels* field must be either ``1`` (mono) or ``2`` (stereo). +EnableContinuousUpdates +--- +This message informs the server to switch between only sending +`FramebufferUpdate`_ messages as a result of a +`FramebufferUpdateRequest`_ message, or sending ``FramebufferUpdate`` +messages continuously. + +Note that there is currently no way to determine if the server supports +this message except for using the `Tight Security Type`_ authentication. + +=== == === +No. of bytesType [Value]Description +=== == === +1 ``U8`` 150*message-type* +1 ``U8`` *enable-flag* +2 ``U16`` *x-position* +2 ``U16`` *y-position* +2 ``U16`` *width* +2 ``U16`` *height* +=== == === + +If *enable-flag* is non-zero, then the server can start sending +``FramebufferUpdate`` messages as needed for the area specified by +*x-position*, *y-position*, *width*, and *height*. If continuous +updates are already active, then they must remain active active and the +coordinates must be replaced with the last message seen. + +If *enable-flag* is zero, then the server must only send +``FramebufferUpdate`` messages as a result of receiving +``FramebufferUpdateRequest`` messages. The server must also immediately +send out a `EndOfContinuousUpdates`_ message. This message must be sent +out even if continuous updates were already disabled. + +The server must ignore all incremental update requests +(``FramebufferUpdateRequest`` with *incremental* set to non-zero) as +long as continuous updates are active. Non-incremental updates must +however be honored, even if the area in such a request does not overlap +the area specified for continuous updates. + Server to Client Messages + @@ -1646,8 +1688,11 @@ 253 `gii Server Message`_ 252 tight 250 `xvp Server Message`_ +150 [#]_`EndOfContinuousUpdates`_ === === +.. [#] **Warning:** Not officially allocated + Note that before sending a message with an optional message type a server must have determined that the client supports the relevant extension by receiving some extension-specific confirmation from the @@ -1908,6 +1953,21 @@ The *data-length* will be a multiple of (*sample-format* * *nchannels*) as requested by the client in an earlier `QEMU Audio Client Message`_. +EndOfContinuousUpdates +-- + +This message is sent whenever the server sees a +`EnableContinuousUpdates`_ message with *enable* set to a non-zero +value. It indicates that the server has stopped sending continuous +updates and is now only reacting to `FramebufferUpdateRequest`_ +messages. + +=== == === +No. of bytesType [Value]Description +=== == === +1 ``U8`` 150*message-type* +=== == === + Encodings + -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training
Re: [rfbproto] Fixing RFB latency sensitivity
On Tue, 4 Oct 2011 14:11:00 +0200 Pierre Ossman wrote: > (Cross-posting to both tigervnc-devel and rfbproto as this is a general > protocol issue, but tigervnc will be the playground for testing it) > > Hi, > > I'm looking at making VNC/RFB work better over high latency network. > Right now we're limited to one update per RTT, which makes things > rather unpleasant over many links. Things are still very much up in the > air, but I've written down my thoughts so far and I'd appreciate any > input you could give on it. You can find my notes here: > > https://sourceforge.net/apps/mediawiki/tigervnc/index.php?title=VNC_Latency_Considerations > > Rgds I was hoping for a bit more comments here, but I guess I have some understanding that this mess is something that people prefer to stay clear off. :) Anyway, I've updated the page linked above with more substantial info from my prototyping. I also have some idea on how the protocol needs to be augmented. The abstract portion of it is on that page, but I've also included patches for the protocol documentation that describes the details. Comments welcome. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? Index: rfbproto.rst === --- rfbproto.rst (revision 4741) +++ rfbproto.rst (working copy) @@ -828,6 +828,7 @@ 252 tight 251 `SetDesktopSize`_ 250 `xvp Client Message`_ +XXX `Fence Client Message`_ === === Note that before sending a message with an optional message type a @@ -1477,6 +1478,72 @@ established that the server supports this extension, by requesting the `xvp Pseudo-encoding`_. +Fence Client Message + + +A client supporting the *Fence* extension sends this to request a +synchronisation of the data stream. + +=== == === +No. of bytesType [Value]Description +=== == === +1 ``U8`` XXX*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. + +=== === +Bit Description +=== === +0 **BlockBefore** +1 **BlockAfter** +2 **SyncNext** +3-30Currently unused +31 **Request** +=== === + +The server should respond 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. + QEMU Client Message ---
[rfbproto] [PATCH] X Cursor
Signed-off-by: Pierre Ossman --- Index: rfbproto.rst === --- rfbproto.rst(revision 4741) +++ rfbproto.rst(working copy) @@ -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 -238Tight options --240 to -246Tight options +-241 to -246Tight options -260 to -272QEMU -273 to -304VMWare -306popa @@ -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 --- -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] [PATCH] X Cursor
On Thu, 27 Oct 2011 17:25:51 +0200 Pierre Ossman wrote: > Signed-off-by: Pierre Ossman > --- Committed. -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? signature.asc Description: PGP signature -- RSA® Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
