From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1HSK9c-00043e-Kr
	for qemu-devel@nongnu.org; Fri, 16 Mar 2007 17:40:04 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1HSK9b-00042i-8J
	for qemu-devel@nongnu.org; Fri, 16 Mar 2007 17:40:04 -0400
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1HSK9a-00042G-OL
	for qemu-devel@nongnu.org; Fri, 16 Mar 2007 16:40:02 -0500
Received: from mail.codesourcery.com ([65.74.133.4])
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1HSK8Q-0003MB-6i
	for qemu-devel@nongnu.org; Fri, 16 Mar 2007 17:38:51 -0400
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [PATCH] Reducing X communication bandwidth, take 2
Date: Fri, 16 Mar 2007 21:38:34 +0000
References: <200703140152.01319.jseward@acm.org>
	<200703162053.02198.jseward@acm.org>
	<45FB077A.3080407@codemonkey.ws>
In-Reply-To: <45FB077A.3080407@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200703162138.35410.paul@codesourcery.com>
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

> > Will this work also for the CL542x adaptor?  (Does that fall in the
> > category of vga?)  My current hack works for with/without -std-vga and I
> > think that's because it lives "underneath" both, in the connection to
> > SDL.
>
> Each adapter will have to do it's own minimization but that's sort of
> the write thing anyway IMHO.  How granular each update is really only
> depends on the adapter.  For instance, the VMware adapter really
> shouldn't need to do any minimization at all.

It would be nice if we could share the framebuffer blitting routines. We've 
currently got 3 different implementations (vga/cirrus, tcx and pl110) of 
basically the same framebuffer rendering routines.

Paul