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] Clarify key autorepeat behaviour
On Fri, May 29, 2009 at 10:37:41AM +0200, Pierre Ossman wrote: On Thu, 28 May 2009 17:00:56 +0100 Daniel P. Berrange d...@berrange.com wrote: On Mon, May 11, 2009 at 01:59:51PM +0200, Pierre Ossman wrote: This thread seems to have died off. Daniel, do you feel that your concerns have been addressed, or do we need more discussion? I'm fine with the principle that key repeat should be generated client side, but I'm not convinced that clients should send a series of down-down-down events without agreeing this behaviour with the server. Servers have to deal with this anyway given that the Windows vncviewer in both version 3 and 4 of RealVNC uses this behaviour, and almost every VNC implementation derives from these. Also, given the dominance of the Windows platform, I'd say the absolute majority of all VNC sessions will already be using this method. So us stating that it is the preferred mode is only documenting reality as it already is. Reality sucks :-( I've no objection to comitting this doc though What server was it that mishandled this sequence? It was in the interaction between QEMU and the emulated guest OS' key handling Daniel -- |: http://berrange.com/ -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://freshmeat.net/~danielpb/-o- http://gtk-vnc.sourceforge.net :| -- 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
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] 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. :) I suggest just stick with xvp, which is what it's been called up to now. After all, it could be applied to systems other than virtual machines, so having a name with virtual machine in it is unnecessarily restrictive. Attached is another attempt at a patch. If anybody would like to modify it further, please just go ahead and do so. Cheers, Colin Describe the xvp extension The xvp extension allows a client to perform shutdown, reboot and reset operations on the system whose framebuffer it is displaying. Signed-off-by: Colin Dean c.c.d...@durham.ac.uk --- Index: rfbproto.rst === --- rfbproto.rst (revision 3823) +++ rfbproto.rst (working copy) @@ -788,7 +788,7 @@ 253 `gii Client Message`_ 252 tight 251 `SetDesktopSize`_ -250 Colin Dean xvp +250 `xvp Client Message`_ === === Note that before sending a message with an optional message type a @@ -1413,6 +1413,27 @@ should make every effort to preserve the fields it does not wish to modify, including any unknown *flags* bits. +xvp Client Message +-- + +A client supporting the *xvp* extension sends this to request that the +server initiate a clean shutdown, clean reboot or abrupt reset of the +system whose framebuffer the client is displaying. + +=== == === +No. of bytesType [Value]Description +=== == === +1 ``U8`` 250*message-type* +1 *padding* +1 ``U8`` 1 *xvp-extension-version* +1 ``U8`` *xvp-message-code* +=== == === + +The possible values for *xvp-message-code* are: 2 - XVP_SHUTDOWN, +3 - XVP_REBOOT, and 4 - XVP_RESET. The client must have already +established that the server supports this extension, by requesting the +`xvp Pseudo-encoding`_. + Server to Client Messages + @@ -1436,7 +1457,7 @@ 254, 127VMWare 253 `gii Server Message`_ 252 tight -250 Colin Dean xvp +250 `xvp Server Message`_ === === Note that before sending a message with an optional message type a @@ -1593,6 +1614,31 @@ communications. A *device-origin* of zero indicates device creation failure. +xvp Server Message +-- + +This has the following format: + +=== == === +No. of bytesType [Value]Description +=== == === +1 ``U8`` 250*message-type* +1 *padding* +1 ``U8`` 1 *xvp-extension-version* +1 ``U8`` *xvp-message-code* +=== == === + +The possible values for *xvp-message-code* are: 0 - XVP_FAIL and 1 - +XVP_INIT. + +A server which supports the *xvp* extension declares this by sending a +message with an XVP_INIT *xvp-message-code* when it receives a request +from the client to use the `xvp Pseudo-encoding`_. + +A server which subsequently receives an `xvp Client Message`_ requesting +an operation which it is unable to perform, informs the client of this +by sending a message with an XVP_FAIL *xvp-message-code*. + Encodings + @@ -1613,6 +1659,7 @@ -223`DesktopSize Pseudo-encoding`_ -305`gii Pseudo-encoding`_ -308`ExtendedDesktopSize Pseudo-encoding`_ +-309`xvp Pseudo-encoding`_ === === Other registered encodings are: @@ -1630,7 +1677,6 @@ -273 to -304VMWare -306popa -307Peter Astrand DesktopName --309Colin Dean xvp 0x574d5600 to 0x574d56ffVMWare === === @@ -2329,3 +2375,16 @@ need to parse the list of screens and can simply display
