Re: [rfbproto] Describe the CoRRE encoding
On Fri, 08 May 2009 10:31:55 +0200 Peter Rosin p...@lysator.liu.se wrote: Describe the CoRRE encoding in terms of the RRE encoding. Signed-off-by: Peter Rosin p...@lysator.liu.se 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] ExtendedDesktopSize extension
On Wed, 06 May 2009 12:25:12 +0200 Peter Rosin p...@lysator.liu.se 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 oss...@cendio.se 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 p...@lysator.liu.se wrote: I think this is accurate. Signed-off-by: Peter Rosin p...@lysator.liu.se 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
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] ExtendedDesktopSize extension
On Thu, 14 May 2009 15:56:35 +0200 Peter Rosin p...@lysator.liu.se 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 oss...@cendio.se wrote: This extension adds multi-head support to RFB, and allows the client to request framebuffer and screen layout changes on the server. Signed-off-by: Pierre Ossman oss...@cendio.se --- This version includes the restriction that a server may not send both a DesktopSize and an ExtendedDesktopSize rectangle. It also mentions the DesktopSize mess in the Screen Model chapter. Lastly, I clarified the CopyRect behaviour in the Screen Model chapter. Rgds -- Pierre OssmanOpenSource-based Thin Client Technology System Developer Telephone: +46-13-21 46 00 Cendio ABWeb: http://www.cendio.com Index: rfbproto.rst === --- rfbproto.rst (revision 3809) +++ rfbproto.rst (working copy) @@ -69,6 +69,56 @@ ignored, resulting in less network traffic and less drawing for the client. +Screen Model + + +In its simplest form, the RFB protocol uses a single, rectangular +framebuffer. All updates are contained within this buffer and may not +extend outside of it. A client with basic functionality simply presents +this buffer to the user, padding or cropping it as necessary to fit +the user's display. + +More advanced RFB clients and servers have the ability to extend this +model and add multiple screens. The purpose being to create a +server-side representation of the client's physical layout. +Applications can use this information to properly position themselves +with regard to screen borders. + +In the multiple-screen model, there is still just a single framebuffer +and framebuffer updates are unaffected by the screen layout. This +assures compatibility between basic clients and advanced servers. +Screens are added to this model and act like viewports into the +framebuffer. A basic client acts as if there is a single screen +covering the entire framebuffer. + +The server may support up to 255 screens, which must be contained fully +within the current framebuffer. Multiple screens may overlap partially +or completely. + +The client must keep track of the contents of the entire framebuffer, +not just the areas currently covered by a screen. Similarly, the server +is free to use encodings that rely on contents currently not visible +inside any screen. For example it may issue a *CopyRect* rectangle from +any part of the framebuffer that should already be known to the client. + +The client can request changes to the framebuffer size and screen +layout. The server is free to approve or deny these requests at will, +but must always inform the client of the result. See the +`SetDesktopSize`_ message for details. + +If the framebuffer size changes, for whatever reason, then all data in +it is invalidated and considered undefined. The server must not use +any encoding that relies on the previous framebuffer contents. Note +however that the semantics for *DesktopSize* are not well-defined and +do not follow this behaviour in all server implementations. See the +`DesktopSize Pseudo-encoding`_ chapter for full details. + +Changing only the screen layout does not affect the framebuffer +contents. The client must therefore keep track of the current +framebuffer dimensions and compare it with the one received in the +*ExtendedDesktopSize* rectangle. Only when they differ may it discard +the framebuffer contents. + Input Protocol == @@ -508,7 +558,7 @@ 254, 127VMWare 253 `gii (General Input Interface) Client Message`_ 252 tight -251 Pierre Ossman SetDesktopSize +251 `SetDesktopSize`_ 250 Colin Dean xvp === === @@ -1043,6 +1093,72 @@ The event reports *count* valuators starting with *first*. +SetDesktopSize +-- + +Requests a change of desktop size. This message is an extension and +may only be sent if the client has previously received an +*ExtendedDesktopSize* rectangle. + +The server must send an *ExtendedDesktopSize* rectangle for every +*SetDesktopSize* message received. Several rectangles may be +sent in a single *FramebufferUpdate* message, but the rectangles must +not be merged or reordered in any way. Note that rectangles sent for +other reasons may be interleaved with the ones generated as a result +of *SetDesktopSize* messages. + +Upon a successful request the server must send an *ExtendedDesktopSize* +rectangle to the requesting client with the exact same information the +client provided in the corresponding *SetDesktopSize* message. +*x-position* must be set to 1, indicating a client initiated event, and +*y-position* must be set to 0, indicating success. + +The server must also send an *ExtendedDesktopSize* rectangle to all +other connected clients, but with *x-position* set to 2, indicating a +change initiated by another client. + +If the server can not or will not satisfy the request, it must send
Re: [rfbproto] [PATCH] Clarify FramebufferUpdateRequest/FramebufferUpdate behaviour
On Tue, 19 May 2009 15:50:47 +0200 Peter Rosin p...@lysator.liu.se 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 p...@lysator.liu.se 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 oss...@cendio.se 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] Don't spell out General Input Interface in every heading.
On Thu, 28 May 2009 15:05:11 +0200 Peter Rosin p...@lysator.liu.se wrote: Also add some introductory text to each chapter involving gii. Signed-off-by: Peter Rosin p...@lysator.liu.se 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 xvp extension
On Fri, 29 May 2009 07:29:40 +0100 DEAN C.C. c.c.d...@durham.ac.uk 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] ExtendedDesktopSize extension
On Fri, 29 May 2009 12:51:48 +0200 Peter Rosin p...@lysator.liu.se 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 p...@lysator.liu.se 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 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 p...@lysator.liu.se 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 3/5]: Describe the Tight LastRect Pseudo-encoding.
On Thu, 11 Jun 2009 13:30:09 +0200 Peter Rosin p...@lysator.liu.se 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.
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 p...@lysator.liu.se 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 5/5]: Describe the Tight JPEG Quality Level Pseudo-encoding.
On Tue, 16 Jun 2009 16:24:07 +0200 Peter Rosin p...@lysator.liu.se 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 p...@lysator.liu.se 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] Align table in ServerInit message
On Thu, 08 Oct 2009 19:40:39 +0200 Peter Rosin p...@lysator.liu.se 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] Clarify lifetime rules for Hextile fg and bg colors
On Thu, 08 Oct 2009 20:02:14 +0200 Peter Rosin p...@lysator.liu.se 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 d...@berrange.com 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 d...@berrange.com 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] New SecType request, call for reviews
On Wed, 25 May 2011 16:33:13 -0400 Brian Hinz bph...@users.sourceforge.net 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] Horizontal mouse wheel
No objections, so I'm committing this. On Tue, 24 May 2011 13:31:22 +0200 Pierre Ossman oss...@cendio.se 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 oss...@cendio.se --- 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
Re: [rfbproto] [PATCH] X Cursor
On Thu, 27 Oct 2011 17:25:51 +0200 Pierre Ossman oss...@cendio.se wrote: Signed-off-by: Pierre Ossman oss...@cendio.se --- 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 -- RSAreg; Conference 2012 Save #36;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
[rfbproto] [PATCH] Synchronisation fences
This documents the fence messages that can be used to synchronise other messages, and to measure network and processing delays between the client and server. Signed-off-by: Pierre Ossman oss...@cendio.se --- Index: rfbproto.rst === --- rfbproto.rst(revision 4793) +++ rfbproto.rst(working copy) @@ -847,7 +847,7 @@ 127 VMWare 128 Car Connectivity 150 `EnableContinuousUpdates`_ -248 ClientFence +248 `ClientFence`_ 249 OLIVE Call Control 250 `xvp Client Message`_ 251 `SetDesktopSize`_ @@ -1193,6 +1193,75 @@ however be honored, even if the area in such a request does not overlap the area specified for continuous updates. +ClientFence +--- + +A client supporting the *Fence* extension sends this to request a +synchronisation of the data stream. + +=== == === +No. of bytesType [Value]Description +=== == === +1 ``U8`` 248*message-type* +3 *padding* +4 ``U32`` *flags* +1 ``U8`` *length* +*length*``U8`` array*payload* +=== == === + +The *flags* byte informs the server if this is a new request, or a +response to a server request sent earlier, as well as what kind of +synchronisation that is desired. The server should not delay the +response more than necessary, even if the synchronisation requirements +would allow it. + +=== === +Bit Description +=== === +0 **BlockBefore** +1 **BlockAfter** +2 **SyncNext** +3-30Currently unused +31 **Request** +=== === + +The server should respond with a `ServerFence`_ with the **Request** +bit cleared, as well as clearing any bits it does not understand. The +remaining bits should remain set in the response. This allows the +client to determine which flags the server supports when new ones are +defined in the future. + +**BlockBefore** +All messages preceeding this one must have finished processing and +taken effect before the response is sent. + +**BlockAfter** +All messages following this one must not start processing until the +response is sent. + +**SyncNext** +The message following this one must be executed in an atomic manner +so that anything preceeding the fence response **must not** be +affected by the message, and anything following the fence response +*must* be affected by the message. The primary purpose of this +synchronisation is to allow safe usage of stream altering commands +such as `SetPixelFormat`_. + +If **BlockAfter** is set then that synchronisation must be relaxed +to allow processing of the following message. Any message after +that will still be affected by both flags though. + +**Request** +Indicates that this is a new request and that a response is +expected. If this bit is cleared then this message is a response to +an earlier request. + +The client can also include a chunk of data to differentiate between +responses and to avoid keeping state. This data is specified using +*length* and *payload*. The size of this data is limited to 64 bytes in +order to minimise the disturbance to highly parallel clients and +servers. + xvp Client Message -- @@ -1723,7 +1792,7 @@ 128 Car Connectivity 150 `EndOfContinuousUpdates`_ 173 [#off]_ ServerState -248 ServerFence +248 `ServerFence`_ 249 OLIVE Call Control 250 `xvp Server Message`_ 252 tight @@ -1856,6 +1925,25 @@ 1 ``U8`` 150*message-type* === == === +ServerFence +--- + +A server supporting the *Fence* extension sends this to request a +synchronisation of the data stream. + +=== == === +No. of bytesType [Value]Description +=== == === +1 ``U8`` 248*message-type* +3 *padding* +4 ``U32`` *flags* +1 ``U8`` *length* +*length*``U8`` array*payload
[rfbproto] [PATCH] Continuous updates pseudo-encoding
Allows clients and servers to handshake for the continuous updates extension without having to use the tight authentication method. Signed-off-by: Pierre Ossman oss...@cendio.se --- Index: rfbproto.rst === --- rfbproto.rst(revision 4793) +++ rfbproto.rst(working copy) @@ -2041,6 +2041,7 @@ -307 `DesktopName Pseudo-encoding`_ -308 `ExtendedDesktopSize Pseudo-encoding`_ -309 `xvp Pseudo-encoding`_ +-313 `ContinuousUpdates Pseudo-encoding`_ -412 to -512 `JPEG Fine-Grained Quality Level Pseudo-encoding`_ -763 to -768 `JPEG Subsampling Level Pseudo-encoding`_ == @@ -2069,7 +2070,6 @@ -310OLIVE Call Control -311ClientRedirect -312Fence --313ContinuousUpdates -523 to -528Car Connectivity 0x574d5600 to 0x574d56ffVMWare 0xc0a1e5ce ExtendedClipboard @@ -3164,6 +3164,16 @@ *xvp-message-code* of *XVP_INIT*. This informs the client that it may then subsequently send messages of type `xvp Client Message`_. +ContinuousUpdates Pseudo-encoding +- + +A client which requests the *ContinuousUpdates* pseudo-encoding is +declaring that it wishes to use the `EnableContinuousUpdates`_ +extension. The server must send a `EndOfContinuousUpdates`_ message the +first time it sees a ``SetEncodings`` message with the +*ContinuousUpdates* pseudo-encoding, in order to inform the client that +the extension is supported. + JPEG Fine-Grained Quality Level Pseudo-encoding --- -- 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(R) 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
Re: [rfbproto] VNC high latency update
On Sun, 19 Feb 2012 23:32:22 +0530 vasanth kumar d.vas...@gmail.com wrote: Hi, I was going through protocol improvement technique for high latency networks. I adopted your continuous update technique but pausing the updates if send data pushed is more than the congestion window. Windows vista above provides APIs to get the congestion window , with this value we can get the maximum send bytes that can be kept on wire without getting acknowledgement. Nice to see someone else implementing this. :) In TigerVNC we purposefully avoid getting congestion window information from the operating system. The reason for this is that we need to know the congestion for the entire pathway between the server and viewer, which might involve more than one TCP connection (proxies). This is why I also added the Fence extension at the same time as it allows the server to measure the congestion independently of the transport layer. I replaced UVNC server with the above implementation created a separate sourceforge project. You can test the implementation provide me feedback if you find it interesting. http://sourceforge.net/projects/cloudvnc/ Was upstream UltraVNC not interested in these 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 -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] VeNCrypt security type specification
On Fri, 04 Nov 2011 13:03:02 +0100, Adam Tkac wrote: Pierre just poked me about merging VeNCrypt specification into the RFB proto. I'm happy with the latest version, Dan, could you please tell us if it is fine from your point of view? Thanks in advance! Regards, Adam This thing has lingered for way too long. Better we commit this version and do improvements later than have nothing at all. Adam, do you think you could clean up the SASL section and reformat the patch with a commit message and signed off line? Rgds -- Pierre Ossman Software Development Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/+CendioThinLinc 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 -- ___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] RFB : No matching security types
On Sun, 13 Apr 2014 17:27:18 + (GMT+00:00) bori...@bluewin.ch bori...@bluewin.ch wrote: CConnection: Server supports RFB protocol version 4.1 This sounds like RealVNC, given that version number. They are unfortunately not very interested in interoperability so I think you're out of luck using any other client than their own. There is a standardised encryption called VeNCrypt though that many of the other VNC implementations support. So try one of those servers instead and you get a bit more choice in clients. Rgds -- Pierre Ossman Software Development Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/112509906846170010689 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 -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
Re: [rfbproto] VeNCrypt security type specification
I was unable to get in touch with Adam, so I have commit the patch more or less as-is. Regards -- Pierre Ossman Software Development Cendio AB http://cendio.com Teknikringen 8 http://twitter.com/ThinLinc 583 30 Linköpinghttp://facebook.com/ThinLinc Phone: +46-13-214600http://plus.google.com/+CendioThinLinc 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 -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing software faster #149; Expert tips and advice for migrating your SCM now http://p.sf.net/sfu/perforce___ tigervnc-rfbproto mailing list tigervnc-rfbproto@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-rfbproto
