qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Julian Pidancet
Subject: [Qemu-devel] Re: [[RfC PATCH]] linux fbdev display driver prototype.
Date: Fri, 21 May 2010 20:32:25 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Shredder/3.0.4

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 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]