From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fa3Tv-00088m-OY for qemu-devel@nongnu.org; Sun, 30 Apr 2006 00:24:27 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fa3Tu-00088R-8i for qemu-devel@nongnu.org; Sun, 30 Apr 2006 00:24:27 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fa3Tu-00088O-3c for qemu-devel@nongnu.org; Sun, 30 Apr 2006 00:24:26 -0400 Received: from [70.116.9.243] (helo=localhost.localdomain) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1Fa3XP-0003Vt-JU for qemu-devel@nongnu.org; Sun, 30 Apr 2006 00:28:03 -0400 Received: from [192.168.1.101] (helo=[192.168.1.101]) by localhost.localdomain with esmtp (Exim 4.52) id 1Fa3Tl-0008Vr-V9 for qemu-devel@nongnu.org; Sat, 29 Apr 2006 23:24:18 -0500 Message-ID: <44543BF1.60304@codemonkey.ws> Date: Sat, 29 Apr 2006 23:24:17 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] VNC display support for QEMU References: <4453DBDE.8020306@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi Johannes, Johannes Schindelin wrote: > Hi, > > On Sat, 29 Apr 2006, Anthony Liguori wrote: > > >> One thing you may notice is that RealVNC has some issues with being >> disconnected. This is because it likes to switch from 8bit to 32bit depths >> automatically at startup. Unfortunately, there is a race condition in the VNC >> protocol and since this implementation is asynchronous, we seem to be much >> more prone to exposing this. >> > > This, along with other problems, has been solved with LibVNCServer. But of > course, you are welcome to solve them again. > I should mention, the majority of the "smarts" of this patch are QEMU specific optimizations. The first one maintains a separate copy of the client's framebuffer to use to reduce the size of the updates generated by the VGA code. The second one hooks the Cirrus 2d video-to-video copy to generate VNC CopyRect updates. The actual VNC side of the code is pretty trivial. I would have been more inclined to use LibVNCServer if it wasn't based on threading. I really wanted an asynchronous implementation of a VNC server that didn't depend on threads. Regards, Anthony Liguori > Ciao, > Dscho > > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel >