From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=39945 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OFXwW-0005MG-Tm for qemu-devel@nongnu.org; Fri, 21 May 2010 15:31:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OFXwU-0005sU-Ui for qemu-devel@nongnu.org; Fri, 21 May 2010 15:31:36 -0400 Received: from smtp.citrix.com ([66.165.176.89]:45026) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OFXwU-0005sE-RN for qemu-devel@nongnu.org; Fri, 21 May 2010 15:31:34 -0400 Message-ID: <4BF6DFC9.6010000@citrix.com> Date: Fri, 21 May 2010 20:32:25 +0100 From: Julian Pidancet MIME-Version: 1.0 References: <1274386823-6153-1-git-send-email-kraxel@redhat.com> In-Reply-To: <1274386823-6153-1-git-send-email-kraxel@redhat.com> Content-Type: text/plain; charset="ISO-8859-1" 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: Gerd Hoffmann Cc: "qemu-devel@nongnu.org" , Stefano Stabellini On 05/20/2010 09:20 PM, Gerd Hoffmann wrote: > Display works with 32 bpp (both host + guest) only. > Which surprisingly didn't cause much problems so far in my testing. > Host runs with kms and inteldrmfb. > > Mouse support isn't available yet. > I've cheated by passed through the hosts usb mouse for testing. > > Keyboard works. Guest screen has whatever keymap you load inside > the guest. Text windows (monitor, serial, ...) have a simple en-us > keymap. Good enougth to type monitor commands. Not goot enougth to > work seriously on a serial terminal. But the qemu terminal emulation > isn't good enougth for that anyway ;) > > Hot keys: > Ctrl-Alt-F -> host console switching. > Ctrl-Alt- -> qemu console switching. > Ctrl-Alt-ESC -> exit qemu. > > Special feature: Sane console switching. Switching away stops screen > updates. Switching back redraws the screen. When started from the > linux console qemu uses the vt you've started it from (requires just > read/write access to /dev/fb0). When starting from somewhere else qemu > tries to open a unused virtual terminal and switch to it (usually > requires root privileges to open /dev/tty). > > For some strange reason console switching from X11 to qemu doesn't work. > Anything else (including X11 -> text console -> qemu) works fine. To be > investigated ... > 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. I think we should add a piece of code which tries reinitialize the framebuffer with the suitable parametters (32bpp/TRUECOLOR). It works fine with inteldrmfb though. - 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). - 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. - 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. This way we could avoid having to define keymaps and this scancode map inside qemu. Cheers, Julian