[PATCH] Embed QEmu screen on a custom window

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
26 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[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


_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] Embed QEmu screen on a custom window

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

On 5/26/05, Miguel Angel Fraile <[hidden email]> wrote:
> Hi,
>
> I'm the author of QGui, a windows frontend for QEmu available at
> http://perso.wanadoo.es/comike.
>


_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] Embed QEmu screen on a custom window

olig9 (Bugzilla)
Christian MICHON wrote:

> 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
>
> On 5/26/05, Miguel Angel Fraile <[hidden email]> wrote:
>
>>Hi,
>>
>>I'm the author of QGui, a windows frontend for QEmu available at
>>http://perso.wanadoo.es/comike.
>>
>
>
>
> _______________________________________________
> Qemu-devel mailing list
> [hidden email]
> 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


_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] Embed QEmu screen on a custom window

Christian MICHON
> 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


_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] Embed QEmu screen on a custom window

Christian Bourque
In reply to this post by Miguel Angel Fraile
Christian MICHON wrote:
>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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] Embed QEmu screen on a custom window

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

On 5/26/05, Christian Bourque <[hidden email]> wrote:

> Christian MICHON wrote:
> >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
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
>


--
Christian


_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] Embed QEmu screen on a custom window

Fabrice Bellard
In reply to this post by Christian MICHON
Christian MICHON wrote:

> 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.


_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

gtk [was Re: [PATCH] Embed QEmu screen on a custom window]

Jim C. Brown
On Thu, May 26, 2005 at 10:03:31PM +0200, Fabrice Bellard wrote:
> >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.

> Fabrice.
>

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


_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] Embed QEmu screen on a custom window

Christian MICHON
In reply to this post by Fabrice Bellard
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... :)

> 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.
>


--
Christian


_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gtk [was Re: [PATCH] Embed QEmu screen on a custom window]

Christian MICHON
In reply to this post by Jim C. Brown
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

> 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
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] Embed QEmu screen on a custom window

Jernej Simončič
In reply to this post by Fabrice Bellard
On Thursday, May 26, 2005, 22:03:31, Fabrice Bellard wrote:

> 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).

--
< Jernej Simoncic ><><><><>< http://deepthought.ena.si/ >

It won't work.
       -- Jenkinson's Law



_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] Embed QEmu screen on a custom window

Fabrice Bellard
In reply to this post by Christian MICHON
Christian MICHON wrote:

> 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.


_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gtk [was Re: [PATCH] Embed QEmu screen on a custom window]

Mark Williamson
In reply to this 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


> Christian
>
> > 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
> [hidden email]
> http://lists.nongnu.org/mailman/listinfo/qemu-devel


_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] Embed QEmu screen on a custom window

Garth Dahlstrom
In reply to this 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

--
Northern.CA ===--
http://www.northern.ca/
Canada's Search Engine


_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gtk [was Re: [PATCH] Embed QEmu screen on a custom window]

Jim C. Brown
In reply to this post by Jim C. Brown
On Thu, May 26, 2005 at 04:32:52PM -0400, Jim C. Brown wrote:
> 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.
>
> > 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.

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


_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] Embed QEmu screen on a custom window

Miguel Angel Fraile
In reply to this post by Miguel Angel Fraile
Christian MICHON wrote:
> 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 ).

> 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.

> 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


_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

gtk2 driver

Sebastien Bechet
In reply to this post by Jim C. Brown
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.

--
Sebastien Bechet <[hidden email]>
av7.net

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

qemu-gtk-diff1.txt (7K) Download Attachment
gtk_keysym.h (8K) Download Attachment
gtk.c (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [PATCH] Embed QEmu screen on a custom window

Pierre d'Herbemont
In reply to this post by Christian MICHON

On 26 mai 05, at 23:07, Christian MICHON wrote:
> 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.

> 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.)

> 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.


_______________________________________________
Qemu-devel mailing list
[hidden email]
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: gtk2 driver

Jim C. Brown
In reply to this post by Sebastien Bechet
On Fri, May 27, 2005 at 12:59:32PM +0200, Sebastien Bechet wrote:

> 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.
>
> --
> Sebastien Bechet <[hidden email]>
> 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.


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

gtk2.c (20K) Download Attachment
gdk_keysym.h (8K) Download Attachment
Makefile.diff (994 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Re: gtk2 driver

Jim C. Brown
On Fri, May 27, 2005 at 11:28:33AM -0400, Jim C. Brown wrote:
> - 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.

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

gtk2.c (20K) Download Attachment
12
Loading...