From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Stabellini Subject: Re: Re: [PATCH] qemu vnc updates Date: Tue, 26 Feb 2008 17:56:12 +0000 Message-ID: <47C452BC.2030100@eu.citrix.com> References: <47C3F6FA.6080506@eu.citrix.com> <47C43B37.1010209@codemonkey.ws> <20080226162224.GI30568@redhat.com> <47C43FA0.60808@eu.citrix.com> <47C44C88.2010205@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <47C44C88.2010205@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, "Daniel P. Berrange" List-Id: xen-devel@lists.xenproject.org Anthony Liguori wrote: > You mean realvnc? The race condition is due to it's use of > SetPixelFormat. By slowing the updates, what you're really doing is > just working around that race condition. That's not a proper solution > though. > > This goes away if you set the realvnc options so that it doesn't change > the pixel format from what the server specifies. > I think that the realvnc "bug" is due to the fact that they assume that if they don't send any update requests, they shouldn't expect any. This is not a wrong assumption to make unless you are right about the 1 request -> N reply argument (I still think that this is not what the rfb spec says). Besides my patch doesn't slow down the connection so much, I cannot tell the difference on a quick connections. I'll let you know what is the behaviour on a slow connection.