From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KiKbs-0000uc-9W for qemu-devel@nongnu.org; Tue, 23 Sep 2008 23:00:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KiKbq-0000uP-QD for qemu-devel@nongnu.org; Tue, 23 Sep 2008 23:00:11 -0400 Received: from [199.232.76.173] (port=60543 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KiKbq-0000uM-Jt for qemu-devel@nongnu.org; Tue, 23 Sep 2008 23:00:10 -0400 Received: from rv-out-0708.google.com ([209.85.198.247]:56455) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KiKbq-0006If-2U for qemu-devel@nongnu.org; Tue, 23 Sep 2008 23:00:10 -0400 Received: by rv-out-0708.google.com with SMTP id f25so2117741rvb.22 for ; Tue, 23 Sep 2008 20:00:08 -0700 (PDT) Message-ID: Date: Wed, 24 Sep 2008 05:00:08 +0200 From: "andrzej zaborowski" Subject: Re: [Qemu-devel] [PATCH 3 of 6] vga shared buffer In-Reply-To: <48CE8819.8070204@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <48CA51E6.1010305@eu.citrix.com> <48CE8819.8070204@codemonkey.ws> 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 2008/9/15 Anthony Liguori : > Stefano Stabellini wrote: >> >> Signed-off-by: Stefano Stabellini >> > > I need to carve out some time to test this series and think about whether it > can be done without adding a new DisplayState hook. I should be able to > respond or apply within a few days. Any news? I think this change makes sense and it can help remove the DIRECT_VRAM hack from vmware_vga.c. > > I'm concerned about the complexity this adds to back-ends. It's not clear > to me whether the performance justifies the added complexity. One way to simplify this and everything else is use Stefano's code to stop the backends (SDL, VNC) from managing the framebuffer altogether and only support what these patches call shared buffer. Then if the given backed doesn't support given colorspace conversion in hardware, it's its call to implement this, it could unify the color conversion in qemu more generally. The drawback is it's hard to support weird colorspaces like those supported by OMAP2 display susbsystem, and even harder to do features like overlaid framebuffers with different colorspaces (but it's not currently implemented anyway). Regards