From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=56902 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OGoIg-0006I8-Vm for qemu-devel@nongnu.org; Tue, 25 May 2010 03:11:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OGoIf-0007Iq-0P for qemu-devel@nongnu.org; Tue, 25 May 2010 03:11:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:62021) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OGoIe-0007Ia-Kz for qemu-devel@nongnu.org; Tue, 25 May 2010 03:11:40 -0400 Message-ID: <4BFB7814.7040107@redhat.com> Date: Tue, 25 May 2010 09:11:16 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1274386823-6153-1-git-send-email-kraxel@redhat.com> <4BF6DFC9.6010000@citrix.com> In-Reply-To: <4BF6DFC9.6010000@citrix.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [[RfC PATCH]] linux fbdev display driver prototype. List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Julian Pidancet Cc: "qemu-devel@nongnu.org" , Stefano Stabellini > This looks very promissing. > > I just got a couple of observations: > > - Your patch does not work on my machine with the vesafb driver. It > reports "can't handle 8 bpp frame buffers". It turns out that the > vesafb driver seems to initialize the framebuffer in PSEUDOCOLOR > mode. Depends on the video mode you ask for via vga=$nr, there are also 32bpp modes. > I think we should add a piece of code which tries reinitialize > the framebuffer with the suitable parametters (32bpp/TRUECOLOR). With vesafb it wouldn't work anyway, you can't switch these parameters at runtime. I think the *drmfb fbdev interface is quite limited too in what it allows to change. > - You should register a Display Allocator and override the > create_displaysurface() method like I did in the DirectFB driver. > This way you save qemu a data copy. fbdev_render_32() should only be > used when the guest framebuffer is not compatible with the physical > framebuffer (guest_bpp != physical_bbp || guest_linesize != > physical_linesize). Isn't a trivial move though. If the console is switched you must stop drawing on the framebuffer. Right now this is easy: just stop copying. Likewise restoring the screen when switching back is easy: just copy everything. If we give out pointers to the framebuffer to other qemu code which doesn't know anything about console switching we have to be quite careful get things right ... > - A cool feature would be to be able to stretch the guest display in > fullscreen. My DirectFB driver implements a fullscreen toggle command > by pressing the Ctrl-Alt-Return keys. I think Stefano added a SDL > zoom feature a while ago which we could reuse for this. The actual stretching is done by SDL I think. For that kind of stuff a rendering library is actually helpful ... > - I'm not very familiar with the scancode stuff, but I think that if > you set your VT fd in the K_RAW keyboard mode, you'll be able to get > true keyboard scancodes that you can directly give to the guest using > the kbd_put_keycode() function. I'm not sure this is really portable. What do you get in K_RAW mode on !x86 platforms? K_MEDIUMRAW gives you linux input layer key codes no matter what. Also the translation to keysyms (for text consoles) is easier with mediumraw. cheers, Gerd