[Qemu-devel] Re: [[RfC PATCH]] linux fbdev display driver prototype.

[Julian Pidancet <julian.pidancet@citrix.com>]

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<nr>  -> host console switching.
>   Ctrl-Alt-<nr>   -> 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<nr>).
> 
> 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