qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] qemu usage


From: K D
Subject: [Qemu-devel] qemu usage
Date: Mon, 17 May 2010 17:26:30 -0700 (PDT)

Hi

I am able to boot my custom kernel off of bare hardware, but when I try to boot this with qemu it hangs after first two lines of print about BIOS. i tried booting through qemu image and also via '-kernel' arg. same result in both cases. i verified that with same qeumu-system-x86_64 i could boot ubuntu kernel/initrd in qemu image and also with -kernel arg but not my kernel.

i'm using pc-bios dir as is with all its subdirs and using it as "-L path_to_pc-bios". can someone help me understand what could be going on.
 
appreciate your help.
kd



From: Anthony Liguori <address@hidden>
To: Alexander Graf <address@hidden>
Cc: address@hidden; Paul Brook <address@hidden>; Julian Pidancet <address@hidden>; Gerd Hoffmann <address@hidden>
Sent: Mon, May 17, 2010 3:46:14 PM
Subject: Re: [Qemu-devel] [PATCH] Add QEMU DirectFB display driver

On 05/17/2010 05:26 PM, Alexander Graf wrote:
> I'm trying to think of a project where the clean separation between multiple video outputs implemented in the backend and a separate frontend worked out. So far the only case that has a strikingly similar architecture coming to my mind is mplayer. And I wouldn't call mplayer's GUI story a huge success.
>
> In fact, couldn't we rather keep all graphic output out of qemu and just expose VNC, possibly with self-made additions to the protocol to speed up local rendering (thinking an SHM extension here)?

I think the whole reason this has failed is that if the GUI is a separate project, the path of least resistance is to use existing interfaces instead of inventing new ones.  That means these GUIs tend to be restricted by whatever management interface exists which isn't actually good enough.

You really need to have the GUI as part of the main project such that when it needs a new interface, it can be added very easily.

>  Then we could still offer a separate SDL based viewer that could do the same things it does now. But we'd also open up the gate for a whole new integration level with possible GUIs.
>   

You could, but I think it introduces more complexity which just is going to get in the way of building a good GUI.

Regards,

Anthony Liguori

> Alex
>
>   




reply via email to

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