[PATCH] Embed QEmu screen on a custom window

[Miguel Angel Fraile]

Hi,

I'm the author of QGui, a windows frontend for QEmu available at
http://perso.wanadoo.es/comike.

I've been trying to attach the QEmu screen to my frontend, but I
finally realized I needed to modify QEmu source to get it.

So I've attached a patch that adds a "-hwnd <handle>" argument to QEmu.

<handle> refers to the window handle where QEmu should be embedded (it
can be any control like a groupbox, form, etc).

Then, QEmu creates a new window that has the window specified at
command-line as parent. If QEmu screen size changes, parent and child
windows are resized automatically.

I hope the patch can be applied to CVS, as it would be very useful for
frontend authors.

PS: Please, add my mail address on CC, as I'm not subscribed to this list.

------------------------------------
--- vl.c Thu May 26 11:04:04 2005
+++ vl.c.new Thu May 26 11:03:34 2005
@@ -150,6 +150,9 @@
#ifdef TARGET_I386
int win2k_install_hack = 0;
#endif
+#ifdef _WIN32
+HWND fend_hwnd, qemu_hwnd;
+#endif

/***********************************************************/
/* x86 ISA bus support */
@@ -2785,6 +2788,9 @@
"-serial dev redirect the serial port to char device 'dev'\n"
"-parallel dev redirect the parallel port to char device 'dev'\n"
"-pidfile file Write PID to 'file'\n"
+#ifdef _WIN32
+ "-hwnd handle embed QEmu inside a custom window"
+#endif
"-S freeze CPU at startup (use 'c' to start
execution)\n"
"-s wait gdb connection to port %d\n"
"-p port change gdb connection port\n"
@@ -2883,6 +2889,7 @@
QEMU_OPTION_loadvm,
QEMU_OPTION_full_screen,
QEMU_OPTION_pidfile,
+ QEMU_OPTION_hwnd,
QEMU_OPTION_no_kqemu,
QEMU_OPTION_win2k_hack,
};
@@ -2953,6 +2960,9 @@
{ "loadvm", HAS_ARG, QEMU_OPTION_loadvm },
{ "full-screen", 0, QEMU_OPTION_full_screen },
{ "pidfile", HAS_ARG, QEMU_OPTION_pidfile },
+#ifdef _WIN32
+ { "hwnd", HAS_ARG, QEMU_OPTION_hwnd },
+#endif
{ "win2k-hack", 0, QEMU_OPTION_win2k_hack },

/* temporary options */
@@ -3036,7 +3046,13 @@
char parallel_devices[MAX_PARALLEL_PORTS][128];
int parallel_device_index;
const char *loadvm = NULL;
-
+
+#ifdef _WIN32
+ char widbuf[24];
+ fend_hwnd=NULL;
+ qemu_hwnd=NULL;
+#endif
+
#if !defined(CONFIG_SOFTMMU)
/* we never want that malloc() uses mmap() */
mallopt(M_MMAP_THRESHOLD, 4096 * 1024);
@@ -3405,6 +3421,16 @@
case QEMU_OPTION_pidfile:
create_pidfile(optarg);
break;
+#ifdef _WIN32
+ case QEMU_OPTION_hwnd:
+ fend_hwnd=(HWND)atoi(optarg);
+ qemu_hwnd=CreateWindow("BUTTON",NULL,BS_OWNERDRAW | WS_CHILD |
+ WS_VISIBLE,0,0,700,420,fend_hwnd,NULL,
+ GetModuleHandle(NULL),NULL);
+ sprintf(widbuf,"SDL_WINDOWID=%#x",(long)qemu_hwnd);
+ putenv(widbuf);
+ break;
+#endif
#ifdef TARGET_I386
case QEMU_OPTION_win2k_hack:
win2k_install_hack = 1;
--- sdl.c Thu May 26 11:03:50 2005
+++ sdl.c.new Thu May 26 11:03:44 2005
@@ -27,6 +27,9 @@

#ifndef _WIN32
#include <signal.h>
+#else
+#include <windows.h>
+extern HWND fend_hwnd,qemu_hwnd;
#endif

static SDL_Surface *screen;
@@ -66,6 +69,12 @@
ds->depth = screen->format->BitsPerPixel;
ds->width = w;
ds->height = h;
+#ifdef _WIN32
+ SetWindowPos(qemu_hwnd,NULL,0,0,w,h,SWP_NOMOVE |
+ SWP_NOREPOSITION | SWP_NOZORDER);
+ SetWindowPos(fend_hwnd,NULL,0,0,w,h,SWP_NOMOVE |
+ SWP_NOREPOSITION | SWP_NOZORDER);
+#endif
}

/* generic keyboard conversion */
@@ -258,6 +267,9 @@
if (gui_grab) {
strcat(buf, " - Press Ctrl-Alt to exit grab");
}
+#ifdef _WIN32
+ if (qemu_hwnd!=NULL)
+#endif
SDL_WM_SetCaption(buf, "QEMU");
}
-----------------------------------

Best regards.
Míguel

[Christian MICHON]

yes, but this is only for windows hosts, and you must install
visual basic.

wouldnt' it be better to add an extra sdl "console" (today we've
main window, control, serial, parallel) where we could set parameters
graphically ? or at least as a text form to read a cfg file ?

this would pay more than to have 1 frontend for windows, 1 for linux,
1 for sparc, 1 for mac, etc...

what's your opinion on this ?

Christian

Post by Miguel Angel Fraile
Hi,
I'm the author of QGui, a windows frontend for QEmu available at
http://perso.wanadoo.es/comike.

[Oliver Gerlich]

Post by Christian MICHON
yes, but this is only for windows hosts, and you must install
visual basic.
wouldnt' it be better to add an extra sdl "console" (today we've
main window, control, serial, parallel) where we could set parameters
graphically ? or at least as a text form to read a cfg file ?
this would pay more than to have 1 frontend for windows, 1 for linux,
1 for sparc, 1 for mac, etc...
what's your opinion on this ?
Christian

Post by Miguel Angel Fraile
Hi,
I'm the author of QGui, a windows frontend for QEmu available at
http://perso.wanadoo.es/comike.

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

I think Miguels patch is quite useful. It makes it possible to use
native Windows controls and Windows API calls to display a nice GUI for
Qemu, without adding much code to Qemu itself. Actually I've been
working on something similar for XFree (with XEmbed) to embed Qemu into
a GUI written with Perl and GTK :) (it partially works already, but
focusing and mouse grabbing doesn't work quite well yet). Btw. I
remember at least two people working on this XEmbed thing as well.
IMHO adding a GUI built with SDL would be much more difficult than using
native GUI toolkits. And doesn't the Cocoa patch aim at a native MacOsX
GUI in the end?
However, the disadvantage of the "native GUI" approach might be that
lots of different GUIs appear, instead of a graphical interface which is
basically consistent on all platforms (like VMWare for Linux is
basically consistent with VMWare for Windows, although both use
different GUI toolkits).

My conclusion is that there should be a discussion (or simply a
decision) on how to build a GUI for Qemu, and that embedding Qemu into
native GUIs could be a good way :)

Oliver Gerlich

[Christian MICHON]

Post by Oliver Gerlich
I think Miguels patch is quite useful. It makes it possible to use
native Windows controls and Windows API calls to display a nice GUI for
Qemu, without adding much code to Qemu itself. Actually I've been
working on something similar for XFree (with XEmbed) to embed Qemu into
a GUI written with Perl and GTK :) (it partially works already, but
focusing and mouse grabbing doesn't work quite well yet). Btw. I
remember at least two people working on this XEmbed thing as well.
IMHO adding a GUI built with SDL would be much more difficult than using
native GUI toolkits. And doesn't the Cocoa patch aim at a native MacOsX
GUI in the end?

All of these are very useful patches indeed. But there's at least 4 gui toolkit
available for SDL, which could ensure:

- a single developpement and a uniform look
- no need for a bigger space on screen (the controls could be like OSD)
- independent of hw/os architecture (the original aim somehow of qemu?)

I agree this is poking inside qemu itself, which can be considered
"a bad thing" (tm). I'm looking at the 4 gui toolkits I mentionned.

- http://www.paragui.org/
- http://guichan.sourceforge.net/
- http://agar.csoft.org/index.html.en
- http://aedgui.sourceforge.net/

Let's open the discussion in a separate thread.

Christian

[Fabrice Bellard]

Post by Christian MICHON
yes, but this is only for windows hosts, and you must install
visual basic.
wouldnt' it be better to add an extra sdl "console" (today we've
main window, control, serial, parallel) where we could set parameters
graphically ? or at least as a text form to read a cfg file ?
this would pay more than to have 1 frontend for windows, 1 for linux,
1 for sparc, 1 for mac, etc...
what's your opinion on this ?

As I said earlier, I would prefer to integrate the GUI in QEMU like the
cocoa.m implementation. GTK for Linux is the best option. For Windows,
either GTK or a native GUI usage would be possible, depending on the
reliability of the GTK port for Windows.

Fabrice.

[Jim C. Brown]

Post by Fabrice Bellard

Post by Christian MICHON
this would pay more than to have 1 frontend for windows, 1 for linux,
1 for sparc, 1 for mac, etc...
what's your opinion on this ?

As I said earlier, I would prefer to integrate the GUI in QEMU like the
cocoa.m implementation. GTK for Linux is the best option.

Out of curiosity, would you accept an intergrated GUI for Linux if it was based
on Xlib or an updated QtC (which was a Qt wrapper that enabled Qt to be used in
C programs) ?

The main advantage, that I can see, with using GTK is that you can run it on
the framebuffer (without X) - provided you have the proper GTK/GDK libs.

Post by Fabrice Bellard
Fabrice.

[Christian MICHON]

SDL can also run directly inside a linux framebuffer :)
Qemu does work already with it. I tried a few months back.
But mouse and keyboard need tuning.

Christian

Post by Jim C. Brown
Out of curiosity, would you accept an intergrated GUI for Linux if it was based
on Xlib or an updated QtC (which was a Qt wrapper that enabled Qt to be used in
C programs) ?
The main advantage, that I can see, with using GTK is that you can run it on
the framebuffer (without X) - provided you have the proper GTK/GDK libs.

[Mark Williamson]

Post by Christian MICHON
SDL can also run directly inside a linux framebuffer :)
Qemu does work already with it. I tried a few months back.
But mouse and keyboard need tuning.

And (Embedded) QT can also render to the framebuffer I believe. Don't know if
that'll work with QtC, tho...

Cheers,
Mark

Post by Christian MICHON
Christian

Post by Jim C. Brown
Out of curiosity, would you accept an intergrated GUI for Linux if it was
based on Xlib or an updated QtC (which was a Qt wrapper that enabled Qt
to be used in C programs) ?
The main advantage, that I can see, with using GTK is that you can run it
on the framebuffer (without X) - provided you have the proper GTK/GDK
libs.

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

[Jim C. Brown]

Post by Jim C. Brown
Out of curiosity, would you accept an intergrated GUI for Linux if it was based
on Xlib or an updated QtC (which was a Qt wrapper that enabled Qt to be used in
C programs) ?
The main advantage, that I can see, with using GTK is that you can run it on
the framebuffer (without X) - provided you have the proper GTK/GDK libs.

Post by Fabrice Bellard
Fabrice.

Just for the curious - I have written a patch for qemu so that you can GTK2
instead of SDL. Its not a full gui, only provides the functions that SDL does,
and it is not stable yet (segfaults consistently when attempting to change the
graphics mode). Email me privately if you wish to look at it.

Once the code becomes stable, I do plan on abstracting it quite a bit more -
eventually to the point where user can dynamically change GUIs. But that is
far off.

[Sebastien Bechet]

Hello Jim,

As fabrice know, i have done some work about it, but no time to debug.
Nevertheless, I think the code is near to work.

Maybe it can help you or someone to finish gtk2 driver...
(you can apply it directly on CVS, see TODO on gtk.c top for bugs)

Bye.

[Jim C. Brown]

Post by Sebastien Bechet
Hello Jim,
As fabrice know, i have done some work about it, but no time to debug.
Nevertheless, I think the code is near to work.
Maybe it can help you or someone to finish gtk2 driver...
(you can apply it directly on CVS, see TODO on gtk.c top for bugs)
Bye.
--
av7.net

Wow...your code looks almost identical to mine. I suppose that shouldnt be
surprising, considering that they are both based off of sdl.c ... still I wish
I had known about this before I spent 10 hours writing a gtk2.c from scratch.

I fixed the segfault, so ... the code is ready for release. Apply Makefile.diff
to the Makefile in i386-softmmu - you may need to change the include dirs or
library flags. Check 'gtk-config --cflags' and 'gtk-config --libs' to be sure.
Note that the patched Makefile compiles gtk2.c into sdl.o, I plan on fixing
that very soon. Bugs:

- kludged Makefile - I do plan to merge in your configure and Makefile patches,
but this kludge allowed me to write/debug gtkqemu a lot faster
- modifier detection isnt working, so its difficult to get a grab and not
possible to ungrab - this is why the no-sdl-grab patch is included
- it is a bad idea to resize the window manually
- you cant close the GTK window normally - must use 'quit' in qemu monitor if
the OS doesnt close qemu thru APM
- GDK grab/ungrab code untested
- full screen mode untested
- need to use "-monitor stdio" because changing virtual consoles doesnt work
- probably a few more that I haven't noticed yet

However, it boots and runs fine with Minix, Windows 98, and KNOPPIX V3.7.

The major difference between your code and mine is that you use GdkPixbuf
while I paint a GdkImage directly on the window. I decided against GdkPixbuf
because it was too high level, and I wasn't sure how to convert the pixel
buffer into the format needed by vga.c

Personally, I think GTK is a bad way to go for something like this (SDL is a
better choice but ideally you'd want something like OpenGL). I only wrote this
because A) Fabrice continues to insist on GTK for linux but wont explain why
B) I wanted to see if it was possible and how it could be done and C) I had
a day off.

[Jim C. Brown]

Post by Jim C. Brown
- modifier detection isnt working, so its difficult to get a grab and not
possible to ungrab - this is why the no-sdl-grab patch is included
- need to use "-monitor stdio" because changing virtual consoles doesnt work

Fixed. It should work perfectly now. New gtk2.c attached.

[Jim C. Brown]

Here is a modified gtk2.c with a patch to allow you to choose gtk thru configure
(from Sebastien Bechet's patch). If you choose to build both sdl and gtk,
then by default qemu will use SDL but you can tell it to use the gtk interface
by passing it the "-use-gtk" switch on the command line.

Post by Jim C. Brown

Post by Jim C. Brown
- modifier detection isnt working, so its difficult to get a grab and not
possible to ungrab - this is why the no-sdl-grab patch is included
- need to use "-monitor stdio" because changing virtual consoles doesnt work

Fixed. It should work perfectly now. New gtk2.c attached.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

[Christian MICHON]

Hi Fabrice,

I understand your point clearly, and I still remembered it.
But adding whichever toolkit would be adding pixels around the
qemu instance, and it would have to interact with SDL.

My simple logic here is why not do it in SDL itself, like an
OSD you'd call by bindkey, like a TV remote control ?

I do not know what cocoa.m implementation is, but I've seen
screenshots. It does require space, and if you go full-screen,
you can't do modifications. Hence the suggestion to go
full SDL.

I'll still look into the 4 SDL-guitoolkits I mentionned. Interesting
stuff they can do... :)

Post by Fabrice Bellard
As I said earlier, I would prefer to integrate the GUI in QEMU like the
cocoa.m implementation. GTK for Linux is the best option. For Windows,
either GTK or a native GUI usage would be possible, depending on the
reliability of the GTK port for Windows.
Fabrice.

[Fabrice Bellard]

Post by Christian MICHON
Hi Fabrice,
I understand your point clearly, and I still remembered it.
But adding whichever toolkit would be adding pixels around the
qemu instance, and it would have to interact with SDL.
My simple logic here is why not do it in SDL itself, like an
OSD you'd call by bindkey, like a TV remote control ?
I do not know what cocoa.m implementation is, but I've seen
screenshots. It does require space, and if you go full-screen,
you can't do modifications. Hence the suggestion to go
full SDL.
I'll still look into the 4 SDL-guitoolkits I mentionned. Interesting
stuff they can do... :)

Improving the SDL interface is a waste of time as SDL has some annoying
bugs and cannot give a good GUI for the end user. Doing a native GTK or
Windows GUI is not complicated and would bring much more confort to the
end user.

Fabrice.

[Pierre d'Herbemont]

Post by Christian MICHON
I do not know what cocoa.m implementation is, but I've seen
screenshots.

cocoa.m is just a qemu video driver which uses natives Mac OS X UI
Libraries.

Post by Christian MICHON
It does require space, and if you go full-screen,
you can't do modifications.

I am not sure that you speak about the cocoa driver. The cocoa video
driver is lighter than the SDL one, since it doesn't require the SDL
dependencies. And I don't get the full-screen point: cocoa.m still
need much work, and that is why it doesn't support fullscreen (yet).
(BTW Mike has been doing some great improvements which will be
hopefully soon committed in the head cvs repository.)

Post by Christian MICHON
Hence the suggestion to go
full SDL.

Fabrice would like to see the native GTK, or Win32 qemu video coded.
Because then a decent UI could be added to qemu. The front ends will
always be limited, and the previous hack seems a bit crazy, and
nearly nasty: you can do that directly via a video driver for qemu,
and moreover it will let you far more control over qemu.

Pierre.

[Christian MICHON]

ok, maybe this needs clarifications. I do not have a Mac, therefore anything
related to cocoa is unknow to me. sorry :(

Let's take an instance of i386-softmmu qemu, which has switched internally
into a 1024x768 graphical mode. To have any gui toolkit AROUND it, the
whole apps, inclusive of the window manager decoration, would need more
than 1024x768 pixels.

When going full screen, as if the qemu machine was the host, we should see
1024x768 pixels only on the screen. The gui toolkit would not be
drawn, therefore
useless unless you switch back to non-fullscreen.

Having the gui toolkit around the instance is ok, provided your native screen
resolution is big enough. But if it's not, you'll need scrollbars, or reduce the
internal graphical mode.

Let's take another concrete example. I have on my desktop a PC with XP
and a LCD 15 inches which support at most 1024x768. When I launch a qemu
instance and the internal softmmu graphical mode is 800x600, how much space
is left on screen, considering the taskbar at the botton and the qemu titlebar ?

100 pixels in height and 200 pixels in x. Not much to integrate a gtk2 toolbars
and a menu, right ? Actually, it will be just nice. only for 800x600
qemu graphic
mode.

My point is: what it the controls could be drawn inside the qemu
graphic windows,
like an On-Screen-Display. You would call a menu, overlapping the
current session,
and you could select the controls you want to change (mostly fda and cdrom, or
load/save vm). The advantage of this being inside the main graphic
window is that
even inside a full-screen mode, we could access it.

But I understand Fabrice's point. After all, this is his "baby". :)
Christian

Post by Pierre d'Herbemont

Post by Christian MICHON
I do not know what cocoa.m implementation is, but I've seen
screenshots.

cocoa.m is just a qemu video driver which uses natives Mac OS X UI
Libraries.

Post by Christian MICHON
It does require space, and if you go full-screen,
you can't do modifications.

I am not sure that you speak about the cocoa driver. The cocoa video
driver is lighter than the SDL one, since it doesn't require the SDL
dependencies. And I don't get the full-screen point: cocoa.m still
need much work, and that is why it doesn't support fullscreen (yet).
(BTW Mike has been doing some great improvements which will be
hopefully soon committed in the head cvs repository.)

Post by Christian MICHON
Hence the suggestion to go
full SDL.

Fabrice would like to see the native GTK, or Win32 qemu video coded.
Because then a decent UI could be added to qemu. The front ends will
always be limited, and the previous hack seems a bit crazy, and
nearly nasty: you can do that directly via a video driver for qemu,
and moreover it will let you far more control over qemu.
Pierre.

[Oliver Gerlich]

Post by Christian MICHON
ok, maybe this needs clarifications. I do not have a Mac, therefore anything
related to cocoa is unknow to me. sorry :(
Let's take an instance of i386-softmmu qemu, which has switched internally
into a 1024x768 graphical mode. To have any gui toolkit AROUND it, the
whole apps, inclusive of the window manager decoration, would need more
than 1024x768 pixels.
When going full screen, as if the qemu machine was the host, we should see
1024x768 pixels only on the screen. The gui toolkit would not be
drawn, therefore
useless unless you switch back to non-fullscreen.
Having the gui toolkit around the instance is ok, provided your native screen
resolution is big enough. But if it's not, you'll need scrollbars, or reduce the
internal graphical mode.
Let's take another concrete example. I have on my desktop a PC with XP
and a LCD 15 inches which support at most 1024x768. When I launch a qemu
instance and the internal softmmu graphical mode is 800x600, how much space
is left on screen, considering the taskbar at the botton and the qemu titlebar ?
100 pixels in height and 200 pixels in x. Not much to integrate a gtk2 toolbars
and a menu, right ? Actually, it will be just nice. only for 800x600
qemu graphic
mode.
My point is: what it the controls could be drawn inside the qemu
graphic windows,
like an On-Screen-Display. You would call a menu, overlapping the
current session,
and you could select the controls you want to change (mostly fda and cdrom, or
load/save vm). The advantage of this being inside the main graphic
window is that
even inside a full-screen mode, we could access it.
But I understand Fabrice's point. After all, this is his "baby". :)
Christian
_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel

Coming to think of it, I happen to like the idea of an OSD :) . Although
I use Qemu mostly in windowed mode with 1024x786 on a 1280x1024 screen
(windowed mode is nice for having Visual Studio in Qemu and Mozilla
Browser with MSDN under Linux), there are situations where fullscreen
mode is better. And in these cases a little OSD would be nice, with
buttons to change CDs, suspend the guest, stop the guest, and maybe
seeing the current guest CPU load and guest HDD activity. Maybe the OSD
should be similar to the little top bar in Windows Terminal Server
connections (IIRC it makes it possible to get out of from fullscreen mode).
As such, an OSD in addition to the GUI would be really useful I think.

Just my two cents,
Oliver Gerlich

[Joe Batt]

...

Coming to think of it, I happen to like the idea of an OSD :) ...

For reference, I work 30 hrs/wk in a VMWare VM running w2k on a Linux
workstation. I keep my left screen in X for local apps, but the right
screen is in "Quick Switch" mode, which is essentially full screen mode,
but when I push the top of the screen, I get the VMWare menu. I really
like this mode.

I would switch to qemu (even pay for it), if supported multiple CPUs and
IO performance was better. I am an application developer and run
Eclipse (sucks memory) and compilers (uses lots of IO).

(For reference, VMWare doesn't support multiple CPUs for a reasonable
price and IO is better than qemu, but is still bad.)

[Jernej Simončič]

Post by Fabrice Bellard
As I said earlier, I would prefer to integrate the GUI in QEMU like the
cocoa.m implementation. GTK for Linux is the best option. For Windows,
either GTK or a native GUI usage would be possible, depending on the
reliability of the GTK port for Windows.

GTK+ on Windows is stable, and even though it doesn't officially support the
Win98/ME anymore, it works on those OSes, too (recently, some bugs that
prevented it working there were fixed; it doesn't work on Windows 95
though).

[Christian Bourque]

Post by Christian MICHON
this would pay more than to have 1 frontend for windows, 1 for linux,
1 for sparc, 1 for mac, etc...
what's your opinion on this ?

You could also use my frontend JQEMU which works on any Java enabled platform :)

Christian

[Christian MICHON]

how much disk space is needed for qemu itself, and for a basic JRE.
The size difference is around 30x to 50x.

But I'll try the JQEMU tomorrow :)

Christian

Post by Christian Bourque

Post by Christian MICHON
this would pay more than to have 1 frontend for windows, 1 for linux,
1 for sparc, 1 for mac, etc...
what's your opinion on this ?

You could also use my frontend JQEMU which works on any Java enabled platform :)
Christian
_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Jerome Warnier]

Post by Christian Bourque

Post by Christian MICHON
this would pay more than to have 1 frontend for windows, 1 for linux,
1 for sparc, 1 for mac, etc...
what's your opinion on this ?

You could also use my frontend JQEMU which works on any Java enabled platform :)

Is it available somewhere?

Post by Christian Bourque
Christian

[Garth Dahlstrom]

Post by Miguel Angel Fraile
I've been trying to attach the QEmu screen to my frontend, but I
finally realized I needed to modify QEmu source to get it.
So I've attached a patch that adds a "-hwnd <handle>" argument to QEmu.

I've been pondering ways to wrap a Win32 gui (mostly likely written in
Delphi or Python, no VB.dll) and thought a patch something like this
would be helpful for managing multiple instances of QEMU similar in
the way VMWare is able to manage multiple VM consoles in 1 tabbed
control Window.

So while I understand the inclination towards embedded gui's also...
I think the more gui/management choices the better (spur innovation
for a while)...

So I'd like to offer my support for inclusion of Miguel's patch...
for what it's worth... :)

Cheers,

-Garth

[Miguel Angel Fraile]

Post by Christian MICHON
yes, but this is only for windows hosts, and you must install
visual basic.

Yes, this is only for windows hosts, but you don't need VB at all, as
there are other frontend not written on VB that would benefit from
this patch (like QEMU Manager: http://www.davereyn.co.uk/qemu ).

Post by Christian MICHON
wouldnt' it be better to add an extra sdl "console" (today we've
main window, control, serial, parallel) where we could set parameters
graphically ? or at least as a text form to read a cfg file ?

I would like to see an integrated frontend, but there are some
problems as written on this thread.

Post by Christian MICHON
this would pay more than to have 1 frontend for windows, 1 for linux,
1 for sparc, 1 for mac, etc...
what's your opinion on this ?

I would add a modular frontend on QEmu. I mean, there should be one
general module that creates the GUI itself (frontend.c) using
functions written on a system-specific module (frontend-<system>.h).

In example:
frontend.c
frontend-windows.h
frontend-linux.h
frontend-macos.h

[Sylvain Petreolle]

Post by Christian Bourque

Post by Christian MICHON
this would pay more than to have 1 frontend for windows, 1 for linux,
1 for sparc, 1 for mac, etc...
what's your opinion on this ?

You could also use my frontend JQEMU which works on any Java enabled platform :)
Christian

If you want to say its "totally free and distributed under the terms of the GPL",
PLEASE provide the sources anywhere you can...

Kind regards,

Usurp (aka Sylvain Petreolle)

humans are like computers,
yesterday the BIOS was all
- today its just a word

[Jim C. Brown]

Mouse grabbing works now (cursor will go invisible and strange "bumping"
problems). Also you can grab the mouse just by clicking the left mouse
button again.

The user can no longer manually resize the qemu gtk window.

Now when you close the GTK window, it signals qemu to shutdown (as if you had
typed "quit" from the monitor).

Fullscreen mode is still broken (the window will resize, but the image on the
window will not). This will be tricky to fix as software scaling will be
necessary to get the image to be the right size/shape. Unlike SDL or OpenGL,
which could alter the video resolution of the X server. Perhaps the best
solution is to use an embedded GTK GLX widget to render the image. What do
you think Fabrice?

New gtk2.c attached.

[Lionel Ulmer]

Post by Jim C. Brown
Fullscreen mode is still broken (the window will resize, but the image on the
window will not). This will be tricky to fix as software scaling will be
necessary to get the image to be the right size/shape. Unlike SDL or OpenGL,
which could alter the video resolution of the X server. Perhaps the best
solution is to use an embedded GTK GLX widget to render the image. What do
you think Fabrice?

Why not switch to SDL output when the user requests going 'full-screen' ? It
would be a bit of a hack, but well, it could work :-)

Otherwise, just use plain X11 calls to change resolution (via XRandr or via
Xvidmode). The problem being always to properly 'align' this window to be
the only one on screen.

Lionel

[Jim C. Brown]

Post by Lionel Ulmer

Post by Jim C. Brown
Fullscreen mode is still broken (the window will resize, but the image on the
window will not). This will be tricky to fix as software scaling will be
necessary to get the image to be the right size/shape. Unlike SDL or OpenGL,
which could alter the video resolution of the X server. Perhaps the best
solution is to use an embedded GTK GLX widget to render the image. What do
you think Fabrice?

Why not switch to SDL output when the user requests going 'full-screen' ? It
would be a bit of a hack, but well, it could work :-)

It's a very easy hack to write, and it wouldnt be very difficult to get to work.

There is a gtksdl widget for gtk2 that I could use just for this purpose -
that way you could still have say a drop down menubar to use (for the GUI).
Or the gtk code could simply call upon the SDL driver when it goes into
fullscreen mode.

Post by Lionel Ulmer
Otherwise, just use plain X11 calls to change resolution (via XRandr or via
Xvidmode). The problem being always to properly 'align' this window to be
the only one on screen.

This is also doable, but it is less portable (e.g. it wouldnt work on Windows).

Either of these approaches mean moving away from pure GTK/GDK. Fabrice hasn't
explained why, but he has made it clear that he wants the Linux to use GTK.
Also, I'd prefer not to use X11 in the gtk driver in the hopes of keeping it
Windows compatible.

Post by Lionel Ulmer
Lionel
--
Lionel Ulmer - http://www.bbrox.org/
_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Fabrice Bellard]

Post by Jim C. Brown

Post by Lionel Ulmer
Otherwise, just use plain X11 calls to change resolution (via XRandr or via
Xvidmode). The problem being always to properly 'align' this window to be
the only one on screen.

This is also doable, but it is less portable (e.g. it wouldnt work on Windows).
Either of these approaches mean moving away from pure GTK/GDK. Fabrice hasn't
explained why, but he has made it clear that he wants the Linux to use GTK.
Also, I'd prefer not to use X11 in the gtk driver in the hopes of keeping it
Windows compatible.

If GTK cannot support correct full screen output, then it is perfectly
acceptable to do direct X11 calls thru DGA/Xvidmode for example. Using
SDL for full screen is possible too, but I think it will be a source of
problems (see the keyboard bugs we have with SDL/Windows).

Fabrice.

[Jim C. Brown]

Post by Fabrice Bellard

Post by Jim C. Brown

Post by Lionel Ulmer
Otherwise, just use plain X11 calls to change resolution (via XRandr or via
Xvidmode). The problem being always to properly 'align' this window to be
the only one on screen.

If GTK cannot support correct full screen output, then it is perfectly
acceptable to do direct X11 calls thru DGA/Xvidmode for example.
Fabrice.

Post by Jim C. Brown
This is also doable, but it is less portable (e.g. it wouldnt work on Windows).

Ok this is what I've decided to do. In order to ensure that gtk2.c will work on
windows, I have decided to keep the fullscreen code separate.

There will be a fullscreen.h that defines the 4 functions that gtk2.c depends
on, and there will be a fullscreen "driver" of the name <library>_fs.c that
implements these functions.

I've written an xvid_fs.c which implements fullscreen mode via the Xvidmode
extension as well as a null_fs.c which doesn't do anything.

This way, Linux/FreeBSD/etc users can use the xvid_fs driver to get fullscreen
mode with gtk and Windows users can use the null_fs driver to use gtk mode.

The idea is that someone could implement a win32_fs driver that would enable
fullscreen mode in Windows. I do not know enough about win32api programming to
write this myself.

If gtk mode is enabled, the configure script will select the correct driver
by default (xvid_fs on unix, null_fs for everyone else) but there will be an
option to override this.

I have a few kinks to work out (plus some configure/Makefile diffs to write)
but expect a patch and the new files in a few hours.

On a side note, has anyone tried to use the gtk2 driver on windows? If so, can
you tell me what happened?

[Jim C. Brown]

Here is the new driver. Patch is against a clean qemu directory. Once you
apply the patch, dump the attached files into the qemu root directory and
run configure with '--enable-gtk' option. The '--set-fs-driver=' option
exists but there should be no need to use it.

[Sylvain Petreolle]

Post by Jim C. Brown
Here is the new driver. Patch is against a clean qemu directory. Once you
apply the patch, dump the attached files into the qemu root directory and
run configure with '--enable-gtk' option. The '--set-fs-driver=' option
exists but there should be no need to use it.

Hunks #2 and #3 of vl.c fail to apply to a new tree checked today,
could you post an updated patch ?

Kind regards,

Usurp (aka Sylvain Petreolle)

humans are like computers,
yesterday the BIOS was all
- today its just a word

[Jim C. Brown]

Post by Sylvain Petreolle

Post by Jim C. Brown
Here is the new driver. Patch is against a clean qemu directory. Once you
apply the patch, dump the attached files into the qemu root directory and
run configure with '--enable-gtk' option. The '--set-fs-driver=' option
exists but there should be no need to use it.

Hunks #2 and #3 of vl.c fail to apply to a new tree checked today,
could you post an updated patch ?

Attached is a patch that omits the vl.c hunks and a vl.c.diff patch that
should work.

The problem was that I have the no-sdl-grab patch applied to my vl.c while
a clean tree doesn't.

Post by Sylvain Petreolle
Kind regards,
Usurp (aka Sylvain Petreolle)
humans are like computers,
yesterday the BIOS was all
- today its just a word
_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel

[Jim C. Brown]

Post by Jim C. Brown
Here is the new driver. Patch is against a clean qemu directory. Once you
apply the patch, dump the attached files into the qemu root directory and
run configure with '--enable-gtk' option. The '--set-fs-driver=' option
exists but there should be no need to use it.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Here is an updated version that partically fixes problems with moving the mouse
when in fullscreen mode (sometimes you can move the mouse anyways and screw up
alignment in spite of this).

New gtk2.c attached. Also gdk_window_set_pointer.c attached. This works for
Linux/X11, Windows code should be ok but it is untested. (This is to overcome
a deliberate oversight in the GDK library, which does not provide a way to
set the location of the mouse pointer. GTK-fb will require an even uglier
hack.)

[Jim C. Brown]

Post by Jim C. Brown

Post by Jim C. Brown
Here is the new driver. Patch is against a clean qemu directory. Once you
apply the patch, dump the attached files into the qemu root directory and
run configure with '--enable-gtk' option. The '--set-fs-driver=' option
exists but there should be no need to use it.
--
Infinite complexity begets infinite beauty.
Infinite precision begets infinite perfection.

Here is an updated version that partically fixes problems with moving the mouse
when in fullscreen mode (sometimes you can move the mouse anyways and screw up
alignment in spite of this).
New gtk2.c attached. Also gdk_window_set_pointer.c attached. This works for
Linux/X11, Windows code should be ok but it is untested. (This is to overcome
a deliberate oversight in the GDK library, which does not provide a way to
set the location of the mouse pointer. GTK-fb will require an even uglier
hack.)
_______________________________________________
Qemu-devel mailing list
http://lists.nongnu.org/mailman/listinfo/qemu-devel

This gtk2.c does a better job of fixing the bug. Mouse shouldnt be able to
affect alignment anymore. Seems to make the mouse cursor move slower, not sure
why, otherwise it has no known bugs. Requires the gdk_set_window_pointer.c that
I posted previously.

[Jim C. Brown]

Updated gtk2.c and xvid_fs.c; Fullscreen mode now works perfectly, there is no
more title bar above qemu window. "Your illusion is now complete." I may or
may not hack gdk_set_window_pointer.c to support linux framebuffer, if I do
I'll probably add a fb_fs.c to support fullscreen mode in the framebuffer as
well. Otherwise I do not plan on adding more to this - for X11 it already
fully supports everything that the SDL version did.