[Qemu-devel] QEMU 0.7.2

[Qemu-devel] QEMU 0.7.2

[Fabrice Bellard]

Hi,

QEMU version 0.7.2 is now available. As usual, you can download it at 
http://bellard.org/qemu .

Fabrice.

[Qemu-devel] Re: QEMU 0.7.2

[Christian Walther]

> QEMU version 0.7.2 is now available.

I see it doesn't include my patch that fixes virtual console switching 
with SDL on Mac OS X 
(http://lists.gnu.org/archive/html/qemu-devel/2005-07/msg00309.html). 
Anything wrong with it?

  -Christian

Re: [Qemu-devel] Re: QEMU 0.7.2

[Andreas Mohr]

Hi,

templated version to make mass complaints easier:

DESCRIPTION="adds missing const/static to qemu structs"
URL=http://lists.gnu.org/archive/html/qemu-devel/2005-08/msg00210.html
NAME=Andreas

I see it doesn't include my patch that $DESCRIPTION
($URL).
Anything wrong with it?

 $NAME

;-)

On Mon, Sep 05, 2005 at 11:58:43AM +0200, Christian Walther wrote:
> >QEMU version 0.7.2 is now available.
> 
> I see it doesn't include my patch that fixes virtual console switching 
> with SDL on Mac OS X 
> (http://lists.gnu.org/archive/html/qemu-devel/2005-07/msg00309.html). 
> Anything wrong with it?
> 
>  -Christian

-- 
No programming skills!? Why not help translate many Linux applications! 
https://launchpad.ubuntu.com/rosetta

Re: [Qemu-devel] Re: QEMU 0.7.2

[Christian MICHON]

> QEMU version 0.7.2 is now available.

Just to report something I noticed on both 0.7.1/0.7.2 on winXP
hosts: qemu-img doesn't convert into compressed images
anymore. qemu-img-0.7.0 is still working fine.

qemu-img.exe convert -c -f qcow hda -O qcow hdz

gives:
qemu-img: Compression not supported for this file format

Once I convert into compressed qcow/img, 0.7.2 is still able
to open and use the image.

Christian

Re: [Qemu-devel] Re: QEMU 0.7.2

[Jim C. Brown]

On Mon, Sep 05, 2005 at 11:58:43AM +0200, Christian Walther wrote:
> >QEMU version 0.7.2 is now available.
> 
> I see it doesn't include my patch that fixes virtual console switching 
> with SDL on Mac OS X 
> (http://lists.gnu.org/archive/html/qemu-devel/2005-07/msg00309.html). 
> Anything wrong with it?
> 
>  -Christian

SDL is obsolete for OS X since qemu includes a native cocoa layer. IIRC there
were multiple issues with using SDL on OS X, so qemu was ported to use cocoa
instead.

(SDL is more-or-less considered obsolete in general, iiuc Fabrice wants the
windows port of qemu to use the Win32API natively to handle graphics, while
on *nix systems an X toolkit (such as Qt or GTK) is preferred.)

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] Re: QEMU 0.7.2

[Karl Magdsick]

> (SDL is more-or-less considered obsolete in general, iiuc Fabrice wants the
> windows port of qemu to use the Win32API natively to handle graphics, while
> on *nix systems an X toolkit (such as Qt or GTK) is preferred.)

Out of curiosity, has GTK on Win32 been considered?


-Karl

Re: [Qemu-devel] Re: QEMU 0.7.2

[Anthony Liguori]

Karl Magdsick wrote:

>>(SDL is more-or-less considered obsolete in general, iiuc Fabrice wants the
>>windows port of qemu to use the Win32API natively to handle graphics, while
>>on *nix systems an X toolkit (such as Qt or GTK) is preferred.)
>>    
>>
>
>Out of curiosity, has GTK on Win32 been considered?
>  
>
Something I've been experimenting with recently is using XEmbed.  XEmbed 
allows you to have manage a widget in one process and display the widget 
in another process.  It's designed to be Toolkit agnostic so you can 
embed QT widgets within GTK and vice versa.

In the GTK world, instead of having qemu create a GtkWindow, it would 
create a GtkPlug.

Then another application (running as a separate process) can use a 
GtkSocket to embed the QEMU vga device within a larger GUI.

There can then be separate GTK/QT guis without QEMU having to support 
both widget sets.  What's more, it seems like the easiest way, given the 
way QEMU currently works, to have an advanced GUI that can manage 
multiple instances of QEMU (using tabs or something like that).

Regards,

Anthony Liguori

>-Karl
>
>
>_______________________________________________
>Qemu-devel mailing list
>Qemu-devel@nongnu.org
>http://lists.nongnu.org/mailman/listinfo/qemu-devel
>
>  
>

Re: [Qemu-devel] Re: QEMU 0.7.2

[Jim C. Brown]

On Mon, Sep 12, 2005 at 06:55:14PM -0400, Karl Magdsick wrote:
> > (SDL is more-or-less considered obsolete in general, iiuc Fabrice wants the
> > windows port of qemu to use the Win32API natively to handle graphics, while
> > on *nix systems an X toolkit (such as Qt or GTK) is preferred.)
> 
> Out of curiosity, has GTK on Win32 been considered?
> 
> 
> -Karl
> 

Yes, but many primary Windows users (those who use Windows as their main OS)
have objections. Things such as: GTK libs and friends are too large just for qemu,
that having to install them would confuse a newbie user, using the native win32
GUI will look more natural, etc. I believe that Fabrice prefers a native win32
GUI but he is ok with using a GTK GUI on Windows. (Basically, he just wants
something that is functional.)

The GTK code I wrote should work equally well when compiled on Windows, though I
currently don't know anyone who uses it there. (My one tester reported that the
computer he had installed qemu on had some sort of hard disk failure iirc.)

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] Re: QEMU 0.7.2

[Jim C. Brown]

On Mon, Sep 12, 2005 at 07:33:26PM -0500, Anthony Liguori wrote:
> What's more, it seems like the easiest way, given the 
> way QEMU currently works, to have an advanced GUI that can manage 
> multiple instances of QEMU (using tabs or something like that).
> 

I'm working on something like that (though I stole the idea from Q, the Mac OS X
Cocoa GUI for qemu). The way it works, one master qemu process creates the
actual window (with full GUI and etc), as well as a VM for one guest. In order
to handle multiple guests, subprocesses are spawned (so one VM per process) but
they display to the GUI of the master process. (Actually, this is implemented
using GtkSocket and GtkPlug.) Currently you'll only be able to see one guest
at a time (though you can switch among them at any time), but I plan on adding
support for using multiple windows later (all windows would be owned and controlled by
the same master process).

> There can then be separate GTK/QT guis without QEMU having to support 
> both widget sets. 

Or either (except some minimal GDK and the GtkPlug). There are definite
advantages to going this route.

AFAIK Fabrice isn't supported of externel GUIs for qemu. He wants to have the
code as part of qemu. (He has no preference however. GTK or Qt or something else
will be fine, as long as it works, the code is simple, and it is easy to use.)

> Then another application (running as a separate process) can use a 
> GtkSocket to embed the QEMU vga device within a larger GUI.
> 

It would be nice if we could keep some sort of GUI-less mode (like what we have
now), so that we only have to run one executable/process in order to run a guest.

> Regards,
> 
> Anthony Liguori
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] Re: QEMU 0.7.2

[Mike Swanson]

I'm just wondering... is it any trouble to draw QEMU using Xlib?

I'd prefer that over any conventional toolkit. There are many
instances where I'm not running any GTK or QT applications on my
desktop, and I'd appreaciate it if I didn't have load either of them
only to run QEMU. >_>
-- 
Mike

Re: [Qemu-devel] Re: QEMU 0.7.2

[Anthony Liguori]

Jim C. Brown wrote:

>On Mon, Sep 12, 2005 at 07:33:26PM -0500, Anthony Liguori wrote:
>  
>
>>What's more, it seems like the easiest way, given the 
>>way QEMU currently works, to have an advanced GUI that can manage 
>>multiple instances of QEMU (using tabs or something like that).
>>
>>    
>>
>
>I'm working on something like that (though I stole the idea from Q, the Mac OS X
>Cocoa GUI for qemu). The way it works, one master qemu process creates the
>actual window (with full GUI and etc), as well as a VM for one guest. In order
>to handle multiple guests, subprocesses are spawned (so one VM per process) but
>they display to the GUI of the master process. (Actually, this is implemented
>using GtkSocket and GtkPlug.) Currently you'll only be able to see one guest
>at a time (though you can switch among them at any time), but I plan on adding
>support for using multiple windows later (all windows would be owned and controlled by
>the same master process).
>  
>
If I understand this correctly, you have multiple processes displaying 
to the same widget?

Seems like it would be a lot easier if each process had it's own 
Socket/Plug pair and then just make use of something like GtkNotebook.

>>There can then be separate GTK/QT guis without QEMU having to support 
>>both widget sets. 
>>    
>>
>
>Or either (except some minimal GDK and the GtkPlug). There are definite
>advantages to going this route.
>  
>
Yeah, I do like this approach quite a bit.  My only concern would be the 
performance of XShmImage vs whatever SDL is using.

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: QEMU 0.7.2

[Anthony Liguori]

Mike Swanson wrote:

>I'm just wondering... is it any trouble to draw QEMU using Xlib?
>
>I'd prefer that over any conventional toolkit. There are many
>instances where I'm not running any GTK or QT applications on my
>desktop, and I'd appreaciate it if I didn't have load either of them
>only to run QEMU. >_>
>  
>
Using a toolkit's widgets doesn't mean you have to load anything.  You 
can happily run a GTK app under blackbox or what have you.  It's just a 
higher level API to Xlibs (which are a royal PITA to code to).

Now, if we were linking to the gnome libs it would be another story...

Regards,

Anthony Liguori

Re: [Qemu-devel] Re: QEMU 0.7.2

[Jim C. Brown]

On Mon, Sep 12, 2005 at 08:37:39PM -0700, Mike Swanson wrote:
> I'm just wondering... is it any trouble to draw QEMU using Xlib?
> 

No. Somone released a file called nosdl.c which did that, though it was for a really
old version of qemu it may still work. (The way it was written was sort of a
hack, though.)

AFAIK the sole objection to using Xlib is because you can't write a GUI using it
(well technically you could, but clearly using GTK or Qt is better for that
task). Fabrice wants a fully integrated GUI into qemu, so he probably won't accept
Xlib patches.

> I'd prefer that over any conventional toolkit. There are many
> instances where I'm not running any GTK or QT applications on my
> desktop, and I'd appreaciate it if I didn't have load either of them
> only to run QEMU. >_>
> -- 
> Mike
> 

I agree with you there. (In fact, I may take the nosdl.c and write an up2date
version if I can find the time.)

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Re: [Qemu-devel] Re: QEMU 0.7.2

[Jim C. Brown]

On Mon, Sep 12, 2005 at 10:45:29PM -0500, Anthony Liguori wrote:
> Jim C. Brown wrote:
> 
> If I understand this correctly, you have multiple processes displaying 
> to the same widget?
> 

Currently, yes.

The eventual goal is to manage multiple windows as well, so you can see more
than one guest at a time.

> Seems like it would be a lot easier if each process had it's own 
> Socket/Plug pair and then just make use of something like GtkNotebook.
> 

Agreed. The reason I didn't try that was because I didn't know was GtkNotebook
was. What would be really slick would be to be able to do what gaim does, drag
and drop tabs across different windows or even drag a tab out of a window
in order to create a new one.

> >>There can then be separate GTK/QT guis without QEMU having to support 
> >>both widget sets. 
> >>   
> >>
> >
> >Or either (except some minimal GDK and the GtkPlug). There are definite
> >advantages to going this route.
> > 
> >
> Yeah, I do like this approach quite a bit.  My only concern would be the 
> performance of XShmImage vs whatever SDL is using.
> 

I did not do any benchmarks but there does not seem to be any noticable speed
differences.

> Regards,
> 
> Anthony Liguori
> 
> 
> _______________________________________________
> Qemu-devel mailing list
> Qemu-devel@nongnu.org
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

-- 
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.