From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel P. Berrange" Subject: Re: Re: [PATCH] qemu vnc updates Date: Tue, 26 Feb 2008 16:22:24 +0000 Message-ID: <20080226162224.GI30568@redhat.com> References: <47C3F6FA.6080506@eu.citrix.com> <47C43B37.1010209@codemonkey.ws> Reply-To: "Daniel P. Berrange" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <47C43B37.1010209@codemonkey.ws> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Anthony Liguori Cc: xen-devel@lists.xensource.com, Stefano Stabellini List-Id: xen-devel@lists.xenproject.org On Tue, Feb 26, 2008 at 10:15:51AM -0600, Anthony Liguori wrote: > Stefano Stabellini wrote: > >Hi all, > >reading qemu code I realized that the qemu vnc server sometimes sends > >framebuffer updates even if the client didn't request any. > >This is not consistent with the RFB protocol spec and can break some > >clients. > > > It's actually consistent with the RFB spec. Have you seen any clients > break? > > The RFB spec states pretty clearly that a single > FramebufferUpdateRequest may generate 0 or more FramebufferUpdate > events. Once a client has sent a single FramebufferUpdate request, it > should expect to continue to receive more FramebufferUpdates for an > indefinite period of time according to the specification. The reverse is true too - the server may coallese multiple FramebufferUpdateRequest into a single FramebufferUpdate reply. There is no 1-to-1 mapping between request & reply as this patch attempts to enforce. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|