[rfbproto] [PATCH] Prepare document for extensions

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.

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

[rfbproto] [PATCH] Clarify key autorepeat behaviour

ell 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. Sign

Re: [rfbproto] [PATCH] Add gii extension (messages and pseudo-encoding)

`U16`` *padding* > +4 ``U32`` *device-origin* > +4 ``S32`` *x* > +4 ``S32`` *y* > +4 ``S32`` *z* > +4 ``S32`` *wheel* >

[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

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:

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" a

Re: [rfbproto] [PATCH] Add README with guidelines

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 (

Re: [rfbproto] [PATCH] Add gii extension (messages and pseudo-encoding)

e 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

[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

[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 AB

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 c

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

Re: [rfbproto] [PATCH] Add links from message and encoding lists

is 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

Re: [rfbproto] [PATCH] Add links from message and encoding lists

ce 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 fo

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 a

Re: [rfbproto] [PATCH] Add links from message and encoding lists

ce 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 Ossm

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 Telep

Re: [rfbproto] [PATCH] Describe the zlib encoding

le 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.c

Re: [rfbproto] [PATCH] Add quirk about the CPIXEL type

h. > > 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 Des

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 &g

Re: [rfbproto] [PATCH] Clarify DesktopSize behaviour

d 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 figur

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: P

Re: [rfbproto] [PATCH] Describe the Tight security type

+-305``GGI_`` ``GII_`` `gii (General Input Interface) > +Pseudo-encoding`_ > +=== ===== ===== === Nit-picking, but code was defined as U32, not S32. :) Rgds -- Pierre OssmanO

[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

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

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.

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 commen

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

[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

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. A

Re: [rfbproto] [PATCH] Clarify FramebufferUpdateRequest/FramebufferUpdate behaviour

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

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

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 lett

Re: [rfbproto] [PATCH] ExtendedDesktopSize extension

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 Teleph

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 >

Re: [rfbproto] [PATCH] Describe the xvp extension

O. 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 A

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 Telephon

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 t

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 S

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 mo

Re: [rfbproto] [PATCH] Describe the xvp extension

quot;? > 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

Re: [rfbproto] [PATCH] Describe the DesktopName pseudo-encoding

iginal 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 exte

Re: [rfbproto] [PATCH] Describe the Tight security type

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

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://ww

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 ve

Re: [rfbproto] [PATCH] Clarify key autorepeat behaviour

is 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

Re: [rfbproto] [PATCH] Clarify DesktopSize behaviour (v2)

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 AB

Re: [rfbproto] [PATCH] ExtendedDesktopSize extension

ts 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 Develop

Re: [rfbproto] [PATCH] ExtendedDesktopSize extension

; 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

Re: [rfbproto] [PATCH] Describe the xvp extension

h 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 Ossman

Re: [rfbproto] [PATCH] Clarify DesktopSize behaviour (v2)

ek. > > 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 Devel

[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

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 Ossman

Re: [rfbproto] [PATCH] Describe the xvp extension

d 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

Re: [rfbproto] [PATCH] Describe the xvp extension

tion 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 OssmanOpen

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

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 >

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

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 Techno

Re: [rfbproto] [PATCH] Describe the DesktopName pseudo-encoding

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 Ossman

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&

Re: [rfbproto] [PATCH 1/5]: Rearrange described and registered encodings.

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 AB

Re: [rfbproto] [PATCH 2/5]: Describe the Tight Compression Level Pseudo-encoding.

t 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 Develop

Re: [rfbproto] [PATCH 3/5]: Describe the Tight LastRect Pseudo-encoding.

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 Frameb

Re: [rfbproto] [PATCH 4/5]: Describe the Tight Encoding.

ression 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

Re: [rfbproto] [PATCH 3/5]: Describe the Tight LastRect Pseudo-encoding.

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-bas

Re: [rfbproto] [PATCH 4/5]: Describe the Tight Encoding.

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 -

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

Re: [rfbproto] [PATCH 5/5]: Describe the Tight JPEG Quality Level Pseudo-encoding.

ntioned. 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://

Re: [rfbproto] [PATCH 5/5]: Describe the Tight JPEG Quality Level Pseudo-encoding.

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

Re: [rfbproto] [PATCH 0/6] Tight: Describe various encodings. v2

t > 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-b

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 man

Re: [rfbproto] [PATCH] Describe the DesktopName pseudo-encoding. v2

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:

[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

Re: [rfbproto] [PATCH] Specify UTF-8 for strings

re 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 AB

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 mo

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:

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

Re: [rfbproto] [PATCH] Specify UTF-8 for strings

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

[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

Re: [rfbproto] [PATCH] Specify UTF-8 for strings (v2)

gs, 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 Oss

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://ww

Re: [rfbproto] TRLE Encoding

=== -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

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

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.

Re: [rfbproto] FYI: new proposed Tight encoding using PNG instead of JPEG

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. Rgd

Re: [rfbproto] QEMU protocol extensions

ank 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

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 OssmanO

Re: [rfbproto] Provisional new XZ encoding

ent 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-base

[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: rf

Re: [rfbproto] New SecType request, call for reviews

``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: +4

Re: [rfbproto] Fwd: pseudo encoding request

NC 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 Cli

Re: [rfbproto] Fwd: pseudo encoding request

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 Tec

[rfbproto] Fixing RFB latency sensitivity

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 Rg

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 e

[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

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 laten

[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 Posit

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: Beca

  1   2   >