From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1KZ0we-0007VO-Pz
	for qemu-devel@nongnu.org; Fri, 29 Aug 2008 06:11:08 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1KZ0wc-0007Uy-U1
	for qemu-devel@nongnu.org; Fri, 29 Aug 2008 06:11:08 -0400
Received: from [199.232.76.173] (port=60727 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1KZ0wc-0007Ur-El
	for qemu-devel@nongnu.org; Fri, 29 Aug 2008 06:11:06 -0400
Received: from smtp.eu.citrix.com ([62.200.22.115]:40477)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <Stefano.Stabellini@eu.citrix.com>)
	id 1KZ0wb-0004ND-Du
	for qemu-devel@nongnu.org; Fri, 29 Aug 2008 06:11:06 -0400
Message-ID: <48B7CB8C.6090507@eu.citrix.com>
Date: Fri, 29 Aug 2008 11:12:28 +0100
From: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH 0 of 3] vnc and vga improvements
References: <48B6C8FB.9090106@eu.citrix.com> <48B7057B.2050203@codemonkey.ws>
	<48B7C6A7.2050706@redhat.com>
In-Reply-To: <48B7C6A7.2050706@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

Gerd Hoffmann wrote:

> And maybe the buffer sharing can be implemented in a way that we can
> turn it on and off at runtime?  So the common case of at most one client
> can run with buffer sharing, otherwise we copy to per-client buffers?
> I'm not a vnc protocol expert though.
> 
> Looking at the patches, it seems buffer sharing is optional already
> (usage depending on the color depth right now it seems).
> 

Yes, it is optional already: every time the guest changes colour depth
vga.c calls dpy_resize_shared (if implemented); dpy_resize_shared checks
the new colour depth and if vnc can support it, then switches the vnc
server internel colour depth to the new one and set shared_buf to 1.
If the vnc server cannot support the new colour depth (for example the
vnc protocol doesn't support 24 bit depth with 24 bpp, only 24 bit depth
with 32 bpp) then set shared_buf to 0 and we are back to the old colour
conversion code.