From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34201 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OF0F8-0003BR-B3 for qemu-devel@nongnu.org; Thu, 20 May 2010 03:32:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OF0F4-0004B2-7r for qemu-devel@nongnu.org; Thu, 20 May 2010 03:32:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:20479) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OF0Eu-00049h-3D for qemu-devel@nongnu.org; Thu, 20 May 2010 03:32:25 -0400 Message-ID: <4BF4E574.4010807@redhat.com> Date: Thu, 20 May 2010 09:32:04 +0200 From: Gerd Hoffmann MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver References: <1273766038-16808-1-git-send-email-julian.pidancet@citrix.com> <4BF30E15.6040505@redhat.com> <4BF3E9C9.1080100@redhat.com> <4BF40C6B.1060306@citrix.com> <20100519163039.GD1693@shareable.org> In-Reply-To: <20100519163039.GD1693@shareable.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: "qemu-devel@nongnu.org" , g@shareable.org, Julian Pidancet , Stefano Stabellini On 05/19/10 18:30, Jamie Lokier wrote: > Julian Pidancet wrote: >> So after all, why not implementing our own VT switching and using >> directly the fbdev interface. > > It's a good idea. VT switching isn't hard to track reliably. Indeed, only problem is that the fbdev libs usually want to do that too. > Being able to tell qemu, through the monitor, to attach/detach from a > particular VT might be a nice easy bonus too. Yes, should be doable without too much effort. >> I just checked the linux fbdev code to >> find out if it provides with a blitting method that could perform >> the pixel color conversion automatically for Qemu. >> >> Unfortunately, from what I have read from the >> drivers/video/cfbimgblt.c file in the linux tree, there's no such >> thing, and it also means that we cannot take advantage of any kind >> of hardware pixel format conversion. > > I'm not sure if DirectFB provides that particular operation, but I > have the impression it's the sort of thing DirectFB is intended for: A > framebuffer, plus a variety of 2d acceleration methods (and other > things like multi-buffering, video and alpha channel overlay). As far I know acceleration depends on the directfb kernel drivers though, i.e. in 99% of the cases (standard distro installs) those are not available and software fallbacks are active anyway. So from a performance point of view directfb doesn't buy us much. And for the pixel conversion I'd prefer see some reorganization of the existing qemu code which is spread all over the place now ... cheers, Gerd