[Top][All Lists]
[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