[rfbproto] New protocol number
Hi! Adding a few new protocol numbers (MD5 hash and TurboVNC pseudo-encodings). Cheers, Peter commit 284d0b37ee9d0de47e37f962ccfa6bad3fc9ac0b Author: Peter Rosin p...@lysator.liu.se Date: Thu Oct 8 19:46:28 2009 +0200 Add new protocol numbers (MD5 auth and TurboVNC pseudo-encodings) Signed-off-by: Peter Rosin p...@lysator.liu.se diff --git a/rfbproto.rst b/rfbproto.rst index 33b035f..5f5fe90 100644 --- a/rfbproto.rst +++ b/rfbproto.rst @@ -386,6 +386,7 @@ Number Name 18 TLS 19 VeNCrypt 20 SASL +21 MD5 hash authentication === === Once the *security-type* has been decided, data specific to that @@ -1722,6 +1723,8 @@ Number Name -257 to -272Anthony Liguori -273 to -304VMWare -306popa +-412 to -512TurboVNC fine-grained quality level +-763 to -768TurboVNC subsampling level 0x574d5600 to 0x574d56ffVMWare === === -- 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] [PATCH] Specify UTF-8 for strings (v2)
Den 2009-09-01 10:21 skrev Pierre Ossman: 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 oss...@cendio.se Yes, please. Cheers, Peter -- 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
Den 2009-08-17 12:47 skrev Adam Tkac: On Mon, Aug 17, 2009 at 11:20:08AM +0200, Peter Rosin wrote: Den 2009-08-17 10:59 skrev Adam Tkac: On Mon, Aug 17, 2009 at 10:22:56AM +0200, Peter Rosin wrote: If it is so natural with UTF-8 and if it really is the only sane choise (I think it is), it's enough if our spec says (e.g.) It is strongly recommended that all implementations use UTF-8 for all strings (except explicitely stated otherwise) to ensure interoperability. But be prepared that not all implementation do, so fail gracefully if you receive something else. instead of (e.g.) All implementations MUST use UTF-8 for all strings (except explicitely stated otherwise). But not all implementations do, so you SHOULD fail gracefully if you receive something else. I just don't see why the wording with MUST/SHOULD is so superior that it is worth rendering existing implementations incompatible with our spec. This is ok with me. I don't think there's any difference in practice. Oh, cool. Pierre previously asked if I had any alternative wording, so here is my suggestion: diff --git a/rfbproto.rst b/rfbproto.rst index 7852746..0252e4f 100644 --- a/rfbproto.rst +++ b/rfbproto.rst @@ -201,6 +201,26 @@ that you contact RealVNC Ltd to make sure that your encodin security types do not clash. Please see the RealVNC website at http://www.realvnc.com for details of how to contact them. +String Encodings + + +It is strongly recommended that strings in RFB are encoded using the +UTF-8 encoding. This allows full unicode support, yet retains good +compatibility with older RFB implementations. + +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 are encouraged to 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 e.g. stripping the +invalid portions or trying to interpret the string using common +encodings such as ISO 8859-1 or Windows code page 1252. + Hm, it is easy to say invalid portions of UTF-8 string but it is _very_ hard to create an algorithm which will determine if a part of string is valid or invalid. If you are using UTF-8 users might create strings with obscure characters. I think this kind of heuristic should not be included in protocol. The only thing I changed from the original patch (by Pierre) in the last three lines was to add e.g., so that implementors would have a choice of doing something else if they liked to. But is it really hard to determine UTF-8 validity? I think that is exactly one of the nice properties of UTF-8. Quoting from the UTF-8 article on wikipedia: Because the starting and continuation bytes are distinct sets, UTF-8 is self-synchronizing. Character boundaries are easily found when searching either forwards or backwards. If bytes are lost due to error or corruption, one can always locate the beginning of the next character and thus limit the damage. Many multi-byte encodings are much harder to resynchronize. Or are you talking about something else? If an implementation sends strings in, for example, the ISO 8859-* encoding it will end with crippled characters but we have to live with it, there is probably no algorithm to solve this problem. You could have an option that says, if a string has errors according to UTF-8, treat it as ISO 8859-1 (substitute for your preferred encoding). Yes, something like that sounds better for me. I attached improved (I hope it is an improvement ;)) specification of strings. *snip* +All new implementations should encode strings in UTF-8 unless the Sorry, but it's not an improvement if you reintroduce either of the magic words SHOULD and MUST in this context. I'm obviously taking to deaf ears. And my suggested option was just some configuration option in some implementation, I did not intend for that to go into the spec. I agree with Peter Åstrand that the specific names of any fallback encodings should probably be left out of the spec. Cheers, Peter -- 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
Re: [rfbproto] [PATCH] Specify UTF-8 for strings
Den 2009-08-17 11:45 skrev Peter Åstrand: No we didn't, we agreed on that for the desktop name. Refresh my memory - which other strings are sent as ANSI CODE PAGE? Username and password in the VeNCrypt extension. There are some strings in the gii extension. The tight file transfer extension sends filenames. And I'm sure I'm forgetting at least some string, that was just off the top of my head... But neither on those are in the protocol at this point. And the tight file transfer is heavily deprecated, even by TightVNC. You better check that, as gii is in the spec. You continue to ignore and look past everything that smells like a problem, which is not very comforting. You seem too eager to add UTF-8 to the spec. And I'd say they are all in the protocol, just not in our specification of the protocol, so it's still a problem in my book. If we add this language now, we will erect a barrier making it harder to add those other protocol extensions to our spec. I think the burden should be on those trying to do new things (which is to specify UTF-8 for all strings) and not on those documenting existing extensions/behaviours. Oh, and there are also strings in the SASL extension. I think it would be worth more to have SASL, VeNCrypt and Tight file transfer documented (even if deprecated) in the spec than to add some language about UTF-8. BTW, where is this heavy deprecation of tight file transfers documented? Nailing to ASCII is worse than nailing to UTF-8. Both make our spec incompatible with existing implementations. We have to allow for implementations to do whatever non-UTF-8 thingy they have been doing, but still recommend against it. I would say: Don't give people rope. If we start documenting that full UTF-8 intl:ed strings are allowed in, say, ProtocolVersion, I'm sure we will soon se a server that presents itself as RFB 003.008übuñtü or something like that... Come on, that's a stupid argument since ProtocolVersion is specified as ASCII and to be 12 characters long. And to be in a very specific format. By everybody. We are not. It's just that clients that relied on recieving the DesktopName in something else than UTF-8 was on their own and relied on unspecified protocol behaviour. Reversing that argument is so easy, Xvnc were on its own when it relied on unspecified protocol behaviour... True, but you can't avoid the fact that the UTF-8 variant is, currently, transmitted over the wire. True, but you can't avoid the fact that some implementations expect, currently, that the data instead should have been transmitted using CP-1252, or ISO 8859-1, or etc... Today, when there is encoding disconnect, it is the fault of noone (except the spec). If we now start to specify one thing as correct, we will shift the balance and make everybody in the UTF-8 camp right. And everybody else wrong. I don't think that's fair. But I still think we can specify one thing as superior. By doing that the alternative options are no longer wrong, just inferior. Strange language. We are not forbidden any clients. It's true that a few clients could theoretically start rendering the names incorrectly, but... But we seriously do not want to divide the RFB community (any further), and we are doing that if we say MUST use UTF-8. With a MUST in there, anything else is not acceptable, hence illegal by our spec. I see no problem with that our document is somewhat stricter than the RealVNC one, when it comes to previously undefined things. In that we differ. Cheers, Peter -- 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 3/6]: Describe the Tight LastRect Pseudo-encoding. v2
commit 017aa8439b2855792e0ba47092d4354fc26ac064 Author: Peter Rosin p...@lysator.liu.se Date: Tue Jun 16 14:11:11 2009 +0200 Describe the Tight LastRect Pseudo-encoding. Signed-off-by: Peter Rosin p...@lysator.liu.se diff --git a/rfbproto.rst b/rfbproto.rst index 33a8fc5..9db6164 100644 --- a/rfbproto.rst +++ b/rfbproto.rst @@ -750,7 +750,7 @@ CodeVendor Signature Description -32 ``TGHT`` ``JPEGQLVL`` JPEG Quality Level -223``TGHT`` ``NEWFBSIZ`` `DesktopSize Pseudo-encoding`_ (New FB Size) --224``TGHT`` ``LASTRECT`` Last Rect +-224``TGHT`` ``LASTRECT`` `LastRect Pseudo-encoding`_ -232``TGHT`` ``POINTPOS`` Pointer Position -239``TGHT`` ``RCHCURSR`` `Cursor Pseudo-encoding`_ (Rich Cursor) @@ -1510,6 +1510,8 @@ However, because there is no strong connection between a client that has more than one *FramebufferUpdateRequest* pending at any given time cannot be sure that it has received all framebuffer updates. +See the `LastRect Pseudo-encoding`_ for an extension to this message. + SetColourMapEntries --- @@ -1662,6 +1664,7 @@ Number Name 8`zlibhex Encoding`_ 16 `ZRLE Encoding`_ -223 `DesktopSize Pseudo-encoding`_ +-224 `LastRect Pseudo-encoding`_ -239 `Cursor Pseudo-encoding`_ -247 to -256 `Compression Level Pseudo-encoding`_ -305 `gii Pseudo-encoding`_ @@ -1678,7 +1681,7 @@ Number Name 15 TRLE 17 Hitachi ZYWRLE -1 to -222 Tight options --224 to -238Tight options +-225 to -238Tight options -240 to -246Tight options -257 to -272Anthony Liguori -273 to -304VMWare @@ -2242,6 +2245,19 @@ gracefully, e.g. by showing a black framebuffer or delay the screen update until a proper update of the framebuffer contents has been received. +LastRect Pseudo-encoding + + +A client which requests the *LastRect* pseudo-encoding is declaring +that it does not need the exact number of rectangles in a +*FramebufferUpdate* message. Instead, it will stop parsing when it +reaches a *LastRect* rectangle. A server may thus start transmitting +the *FramebufferUpdate* message before it knows exactly how many +rectangles it is going to transmit, and the server typically advertises +this situation by saying that it is going to send 65535 rectangles, +but it then stops with a *LastRect* instead of sending all of them. +There is no further data associated with the pseudo-rectangle. + Compression Level Pseudo-encoding - -- 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 4/6]: Describe the Tight Encoding. v2
commit bd46a9f54ae8c3ff5a6d4566a3332d4cf3e8ac77 Author: Peter Rosin p...@lysator.liu.se Date: Tue Jun 16 14:24:30 2009 +0200 Describe the Tight Encoding. Signed-off-by: Peter Rosin p...@lysator.liu.se diff --git a/rfbproto.rst b/rfbproto.rst index 9db6164..24aab00 100644 --- a/rfbproto.rst +++ b/rfbproto.rst @@ -745,7 +745,7 @@ CodeVendor Signature Description 4 ``STDV`` ``CORRE___`` `CoRRE Encoding`_ 5 ``STDV`` ``HEXTILE_`` `Hextile Encoding`_ 6 ``TRDV`` ``ZLIB`` `ZLib Encoding`_ -7 ``TGHT`` ``TIGHT___`` Tight Encoding +7 ``TGHT`` ``TIGHT___`` `Tight Encoding`_ 8 ``TRDV`` ``ZLIBHEX_`` `ZLibHex Encoding`_ -32 ``TGHT`` ``JPEGQLVL`` JPEG Quality Level -223``TGHT`` ``NEWFBSIZ`` `DesktopSize Pseudo-encoding`_ (New @@ -1661,6 +1661,7 @@ Number Name 4`CoRRE Encoding`_ 5`Hextile Encoding`_ 6`zlib Encoding`_ +7`Tight Encoding`_ 8`zlibhex Encoding`_ 16 `ZRLE Encoding`_ -223 `DesktopSize Pseudo-encoding`_ @@ -1677,7 +1678,6 @@ Other registered encodings are: === === Number Name === === -7 Tight 15 TRLE 17 Hitachi ZYWRLE -1 to -222 Tight options @@ -1945,6 +1945,200 @@ No. of bytesTypeDescription The *zlibData*, when uncompressed, represents a rectangle according to the `Raw Encoding`_. +Tight Encoding +-- + +Tight encoding provides efficient compression for pixel data. + +The first byte of each Tight-encoded rectangle is a +*compression-control* byte: + +=== === === +No. of bytesTypeDescription +=== === === +1 ``U8`` *compression-control* +=== === === + +The least significant four bits of *compression-control* byte inform +the client which zlib compression streams should be reset before +decoding the rectangle. Each bit is independent and corresponds to a +separate zlib stream that should be reset: + +== +BitDescription +== +0 if 1: reset stream 0 +1 if 1: reset stream 1 +2 if 1: reset stream 2 +3 if 1: reset stream 3 +== + +One of three possible compression methods are supported in the Tight +encoding. These are **BasicCompression**, **FillCompression** and +**JpegCompression**. If the bit 7 (the most significant bit) of +*compression-control* byte is 0, then the compression type is +**BasicCompression**. In that case, bits 7-4 (the most significant four +bits) of *compression-control* should be interpreted as follows: + +=== === === +BitsBinary valueDescription +=== === === +5-4 00 *UseStream0* +.. 01 *UseStream1* +.. 10 *UseStream2* +.. 11 *UseStream3* +6 0 --- +.. 1 *ReadFilterId* +7 0 **BasicCompression** +=== === === + +Otherwise, if the bit 7 of *compression-control* is set to 1, then the +compression method is either **FillCompression** or +**JpegCompression**, depending on other bits of the same byte: + +=== === === +BitsBinary valueDescription +=== === === +7-4 1000**FillCompression** +.. 1001**JpegCompression** +.. any other invalid +=== === === + +Note: **JpegCompression** may only be used when *bits-per-pixel* is +either 16 or 32. + +The data following the *compression-control* byte depends on the +compression method. + +**FillCompression** + +If the compression type is fill, then the only pixel value +follows, in client pixel format (see [NOTE1]_). This value applies +to all pixels of the rectangle. + +**JpegCompression** + +If the compression type is jpeg, the following data stream looks +like
Re: [rfbproto] [PATCH] ExtendedDesktopSize extension
Den 2009-05-29 16:38 skrev Pierre Ossman: 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. 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? Cheers, Peter -- 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)
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. Cheers, Peter -- 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] Don't spell out General Input Interface in every heading.
Also add some introductory text to each chapter involving gii. Signed-off-by: Peter Rosin p...@lysator.liu.se diff --git a/rfbproto.rst b/rfbproto.rst index 18cda39..dfea980 100644 --- a/rfbproto.rst +++ b/rfbproto.rst @@ -81,7 +81,7 @@ example, a pen-based handwriting recognition engine might generate keyboard events. If you have an input source that does not fit this standard workstation -model, the Generial Input Interface (gii) protocol extension provides +model, the General Input Interface (gii) protocol extension provides possibilities for input sources with more axes, relative movement and more buttons. @@ -506,7 +506,7 @@ Number Name === === 255 Anthony Liguori 254, 127VMWare -253 `gii (General Input Interface) Client Message`_ +253 `gii Client Message`_ 252 tight 251 Pierre Ossman SetDesktopSize 250 Colin Dean xvp @@ -781,8 +781,12 @@ No. of bytesType [Value]Description *length*``U8`` array*text* === == === -gii (General Input Interface) Client Message - +gii Client Message +-- + +This message is an extension and may only be sent if the client has +previously received a `gii Server Message`_ confirming that the server +supports the General Input Interface extension. Version ~~~ @@ -1064,7 +1068,7 @@ Number Name === === 255 Anthony Liguori 254, 127VMWare -253 `gii (General Input Interface) Server Message`_ +253 `gii Server Message`_ 252 tight 250 Colin Dean xvp === === @@ -1162,8 +1166,13 @@ No. of bytesType [Value] Description *length*``U8`` array*text* === == === -gii (General Input Interface) Server Message - +gii Server Message +-- + +This message is an extension and may only be sent if the server has +previously received a `SetEncodings`_ message confirming that the +client supports the General Input Interface extension via the `gii +Pseudo-encoding`_. Version ~~~ @@ -1226,7 +1235,7 @@ Number Name 16 `ZRLE Encoding`_ -239`Cursor Pseudo-encoding`_ -223`DesktopSize Pseudo-encoding`_ --305`gii (General Input Interface) Pseudo-encoding`_ +-305`gii Pseudo-encoding`_ === === Other registered encodings are: @@ -1799,14 +1808,14 @@ 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 -- +gii Pseudo-encoding +--- -A client which requests the *gii* pseudo-encoding is declaring that it -is capable of accepting the *gii* server-to-client message. The server -declares that it is capable of accepting the *gii* client-to-server -messages by sending a *gii* server-to-client message of subtype -*version*. +A client that supports the General Input Interface extension starts by +requesting the *gii* pseudo-encoding declaring that it is capable of +accepting the `gii Server Message`_. The server, in turn, declares that +it is capable of accepting the `gii Client Message`_ by sending a `gii +Server Message`_ of subtype *version*. Requesting the *gii* pseudo-encoding is the first step when a client wants to use the *gii* extension of the RFB protocol. The *gii* -- 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
Den 2009-05-15 12:20 skrev Pierre Ossman: 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. The conversation as such has been pleasant. I do not perceive you as confrontational, I was just getting tired of not getting any output from my input... 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? 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. 1) WMVi rect appears in an update without any EDS rect, the FB size matches the previous full FB size. Easy, just assume the screen layout stays the same and that the only thing that has changed is the pixfmt. 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... 3) WMVi rect appears in an update with an EDS rect afterwards, the FB size is updated and the size in the WMVi rect matches the size in the EDS rect. On reception of the WMVi rect, the client should wait to see if an EDS rect is appearing in this update and combine the two into one operation instead of ending up in case 2. 4) WMVi rect appears in an update with an EDS rect afterwards, the FB size is updated but the size in the WMVi rect matches the previous FB size. On reception of the WMVi rect, the client could wait to see if an EDS rect is appearing in this update and combine the two into one operation. It could also do as in case 1. 5) EDS rect appears in an update with a WMVi rect afterwards, the FB size is maybe updated and the size in the WMVi rect matches the size in the EDS rect. See 1, but it would probably be better to combine the two operations as in 3 or 4. 6) EDS rect appears in an update with a WMVi rect afterwards, the FB size is maybe updated but the size in the WMVi rect doesn't match the size in the EDS rect. Hmm, what to do. Stupid server. Drop all screens and show the FB according to the WMVi rect I guess... 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. It will also be quite hard to test all the above cases. Where will you find a server that can do all cases? Yeah, I know, you could write a testsuite for your client, but if there were only one case it would get tested for free by regular users, and not only when someone runs some obscure testsuite. 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. 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
Re: [rfbproto] [PATCH] Clarify DesktopSize behaviour
Den 2009-05-15 11:24 skrev Pierre Ossman: 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. :) Indeed :-) On Thu, 14 May 2009 15:04:27 +0200 Peter Rosin p...@lysator.liu.se 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. That's fine. I just don't like to fool the reader into one view (the perfect model) and then have the real stuff last. It might be that it is clearest to start the description with how it was originally meant to work, but in that case it should include some wording that makes it apparant from the start that this mode of thinking is too simplistic for a real implementation. 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. :) Well, the first reason I can think of is if the client window has been obscured but is now brought on top. If the client does not have a copy, then it has to do the non-incr dance. It *could* have kept a copy of the contents of the FB in system memory though. I fail to see how this is fundamentally different from a client that is not keeping a copy in system memory during a graphics mode switch due to a DesktopSize rect. The non-incr FBU request is equally valid in both cases IMHO. 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. Of course not, but this has been sitting for too long in the spec, without any protests AFAIK. 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. Good! 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. I guess I got a bit overboard. I had this feeling that you wanted to describe DS in a way that made EDS look similar. But since you have agreed to not allow DS rects when the client supports EDS, I am more at ease. 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 the subject the client can not assume anything. So, the client should keep a copy of the cursor bits if there is a risk that it might need to recreate the cursor (unless we research the wild and find that all (major) current implementations do in fact send the cursor bits on non-incr FUR, in that case we can tighten the spec and allow clients to officially use that method to restore a discarded
Re: [rfbproto] [PATCH] Clarify DesktopSize behaviour
Den 2009-05-11 13:24 skrev Pierre Ossman: On Tue, 05 May 2009 11:53:27 +0200 Peter Rosin wrote: That doesn't solve anything though. I would like my implementation to be compatible with both the spec and the wilderness. Tightening the spec after the fact does not achieve that goal. 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. It's too late to tidy things up. Aaarghh, the RealVNC interpretation is really insane. You then have to wait for the whole update and check if the last rect is a DesktopSize rect before you start taking any other action (either that, or you need some way to backtrack what you just did and then redo it after changing FB size when you discover a DesktopSize rect, good luck with that...). 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. 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. Here you are not making sense. First you say that UltraVNC is the only one to send non-incr, so the others you mention should be sending incr. But then you say that in the tight model the client throws the FB away, but the only way to do that AFAICT is to send a non-incr FBU request. So, which way is it? 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. The spec. is (unfortunately) completely silent as to what happens to the FB data when it changes size. The original implementation assumed it would be lost, hence sending a incr FUR was safe as the server would consider the entire screen modified. Personally, I think this model makes a lot of sense as it keeps using incr for the normal case. Keeping the FB contents over a change adds complexity and I don't think there is much gain anyway as the entire desktop is likely to refresh. Agreed, it makes sence. But the spec has been unclear and we have major competing implementations. Anyway, do you really think RealVNC is going to change due to something we write in our forked spec? I would very much like to be compatible with RealVNC. Same thing with UltraVNC, as much as is possible without breaking the spec anyway (writing a client that talks to an Ultra server is ok, but writing a server that can handle the Ultra client is worse). And I would like the spec to be compatible with existing versions, not ones that might, if we are lucky, be produced in the future. I'd like to think that my version handles all existing implementations since it mentions the gotchas. So IMO, declaring stuff that exists today and that is compatible with the original spec as buggy is out of the question. I think that when the original spec is unclear, the original (with regard to the extension) or most popular implementation should govern the updated spec, not RealVNC's implementation. I think that RealVNC is quite special, given who is behind it and who has written the spec. 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. So, if there are grey areas with differering implementations then yes, we can and probably should recommend the sane choice, but we can't outlaw the alternatives. If there are grey areas but only one implementation (like the CPIXEL note I sent the other day), we are free to clear up the confusion. Quite possibly we should mark those places in the document though
[rfbproto] [PATCH] Describe the zlibhex encoding
Describe the zlibhex encoding in terms of the hextile encoding. Signed-off-by: Peter Rosin p...@lysator.liu.se (I'm not all satisfied with the double^Wtripple reference to zlib...) Cheers, Peter diff --git a/rfbproto.rst b/rfbproto.rst index 896fb8b..363d0d0 100644 --- a/rfbproto.rst +++ b/rfbproto.rst @@ -1220,6 +1220,7 @@ Number Name 1 `CopyRect Encoding`_ 2 `RRE Encoding`_ 5 `Hextile Encoding`_ +8 `zlibhex Encoding`_ 16 `ZRLE Encoding`_ -239`Cursor Pseudo-encoding`_ -223`DesktopSize Pseudo-encoding`_ @@ -1234,7 +1235,6 @@ Number Name 4 CoRRE 6 zlib 7 tight -8 zlibhex 15 TRLE 17 Hitachi ZYWRLE -1 to -222 @@ -1449,6 +1449,52 @@ least-significant specify the Y position. The most-significant four bits of *width-and-height* specify the width minus one, the least-significant specify the height minus one. +zlibhex Encoding + + +The zlibhex encoding uses zlib [#]_ to optionally compress +subrectangles according to the `Hextile Encoding`_. Refer to the +hextile encoding for information on how the rectangle is divided into +subrectangles and other basic properties of subrectangles. One zlib +stream object is used for subrectangles encoded according to the +**Raw** subencoding and one zlib stream object is used for all other +subrectangles. + +.. [#] see http://www.gzip.org/zlib/ + +The hextile subencoding bitfield is extended with these bits: + +=== === === === +No. of bytesType[Value] Description +=== === === === +1 ``U8`` *subencoding-mask*: +.. 32 **ZlibRaw** +.. 64 **Zlib** +=== === === === + +If either of the **ZlibRaw** or the **Zlib** bit is set, the +subrectangle is compressed using zlib, like this: + +=== === === +No. of bytesTypeDescription +=== === === +2 ``U16`` *length* +*length*``U8`` array*zlibData* +=== === === + +Like the **Raw** bit in hextile, the **ZlibRaw** bit in zlibhex cancels +all other bits and the subrectangle is encoded using the first zlib +stream object. The *zlibData*, when uncompressed, should in this case +be interpreted as the **Raw** data in the hextile encoding. + +If the **Zlib** bit is set, the rectangle is encoded using the second +zlib stream object. The *zlibData*, when uncompressed, represents a +plain hextile rectangle according to the lower 5 bits in the +subencoding. + +If neither the **ZlibRaw** nor the **Zlib** bit is set, the +subrectangle follows the rules described in the `Hextile Encoding`_. + ZRLE Encoding - -- 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
