Re: [Qemu-devel] VirtualBox PC virtualization released as Open Source
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Oliver Gerlich schrieb: Hello, as I was just reading this on german newsticker heise.de: http://www.heise.de/open/news/meldung/83680 Also on Slashdot: http://it.slashdot.org/it/07/01/15/1631234.shtml And the original news: http://www.virtualbox.org/wiki/News Anyone knows more about this? How is it in direct comparison with Qemu? Just installed the Etch .deb (went well, even kernel module compilation; though it didn't get the permissions of /dev/vboxdrv quite right). The GUI is really good; it was easy to configure a new VM. For testing, I started Ubuntu Edgy Desktop CD in VB and Qemu (0.8.2, taken from CVS in Nov. 2006), both without hard disk, with audio, with 192 MB, with normal kqemu (no kernel emulation). Both systems start in reasonable time (didn't measure it, though). It seems like the VB graphics emulation is snappier: in Qemu, it always feels (and always felt) somewhat laggy and slow, while in VB it felt faster. Note: I tried Qemu with and without -std-vga; in VB I didn't install any guest stuff. In general, graphics in VB seem faster; while in Qemu I could notice how the menus were displayed (first the frame, then the interior), in VB the menus were immediately there. I think that's a very important thing, because currently Qemu _feels_ slow on the desktop, even though it's CPU performance is probably as fast as VBs or VMWares! Hopefully the VB devs will give some of their improvements back to Qemu (apparently their graphics emulation is based on Qemu's). Afterthought: using Qemu with -kernel-kqemu makes the menu drawing as fast as with VB, but mouse still feels laggy. What else: VB sound was choppy when playing a video, while in Qemu the same video was with good sound, bad choppy display. It seems like VB doesn't use something like -kernel-kqemu; during Ubuntu boot, host CPU was only used by userland apps, while with Qemu with - -kernel-kqemu 80% of host CPU was used by kernel. VB offers some guest tools (didn't try them), but without guest tools there is smooth mouse-transition (Qemu does this nicely with tablet emulation). All in all I like VB for its easy GUI and good responsiveness; hopefully this can be combined with Qemus broad host arch support :-) Regards, Oliver ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFFrABTTFOM6DcNJ6cRAs9hAKDkcCWl+QLgvKHExT7fP4sBzWFIhgCgu3Jf U4GFShn4GnpKGBoxMa5LNpg= =pfoh -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Linux Kernel to Include KVM Virtualization
Ricardo Almeida wrote: Hi, Just saw this on slashdot (http://linux.slashdot.org/article.pl?sid=06/12/12/0135240). From the news: In a fashion comparable to that of Xen a modified QEMU is used for the supportive emulation of typical PC components of the virtual machines So, when it will run with a non-modified QEMU? ;) I've looked at KVM homepage (http://kvm.sourceforge.net/) and it's a kernel module, so I think this can be some kind of replacement for KQEmu, no? Will QEmu/KQEmu support this? Isn't KVM more like a kqemu which uses VT/Pacifica so that it runs processes a bit more native? That's how I understood it... Though I'm wondering why this project apparently didn't announce itself on this list, at least for general information. Or, this can also be seen as a hint that Qemu is _so_ well-structured and well-documented that people are able to use its code without any questions ;-) Thanks for the great work, Ricardo Almeida ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Regards, Oliver Gerlich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Anyone knows why some mails get stuck at lists.gnu.org?
Hello, apparently today another load of delayed mails appeared on the qemu-devel list... I have experienced this delay myself with some mails I sent (OTOH the last mail I sent appeared after just 20 minutes). So I wonder if anyone knows why some mails are delayed so much? The mail headers look like this: ... Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GgCp2-0007R5-Cz for [EMAIL PROTECTED]; Fri, 03 Nov 2006 23:07:56 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GeYNY-0007fP-0O for qemu-devel@nongnu.org; Mon, 30 Oct 2006 09:44:44 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GeYNS-0007f4-1o for qemu-devel@nongnu.org; Mon, 30 Oct 2006 09:44:42 -0500 ... So it seems the mails are stuck at lists.gnu.org . Any idea what's causing this or how to get rid of the delay? Thanks, Oliver Gerlich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Broken forum links on qemu.org
Hello, at qemu.org, there are two links (at http://qemu.org/download.html and http://qemu.org/lists.html ) which still point to the old forum server (Hetz, thanks for hosting it for so long!). According to http://lists.gnu.org/archive/html/qemu-devel/2006-10/msg00030.html the forum is now at http://qemu-forum.ipi.fi , and CVS snapshots are at http://qemu-forum.ipi.fi/qemu-snapshots/ . Could someone who has write access to qemu.org update the two pages there? It seems the new forum location is only available from the mailing list (I didn't find any other link). Thanks, Oliver Gerlich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Re: [RFC] qemu-gui based on wxWidgets and libvncclient
Here's a partial translation/explanation of the link that Johannes sent some days ago, concerning remote sound in VNC. The final documentation (in german) can be found at http://www.ks.uni-freiburg.de/download/studienarbeit/SS05/08-05-TonSpur-DRichter/Dokumentation/Dokumentation.pdf According to that PDF, sound is transmitted by capturing it with a Java application, then converting it using JMF (Java Media Framework) and sending it out as RTP stream. A Java client receives the RTP stream and plays it. As far as I understand, handshaking is done with an own TCP connection, while actual RTP packets are sent via UDP. During handshaking, connection speed is measured (see 6.1.2) to decide on the encoding (see 6.2.2). There's also an older document at http://www.ks.uni-freiburg.de/download/studienarbeit/WS03/Ton-Spur-VNC.pdf which indeed describes a way to use ESD for remote sound. Regards, Oliver Anthony Liguori wrote: Johannes Schindelin wrote: Hi, On Tue, 17 Oct 2006, Fabrice Bellard wrote: Another point is that you should consider adding audio support. I can help you on that (maybe malc would be interested too !). A simple format could be 4 bit ADPCM at fixed frequency. Optionally A more advanced codec such as Vorbis could be used. Please, please not _another_ vnc hack! The RFB protocol loses all of its appeal if everybody has proprietary, incompatible extensions! If you bother to search Google for prior art, here is a link: http://www.ks.uni-freiburg.de/php_arbeitdet.php?id=75 Yes, it is in German, but it already works. No need to add yet another obscure extension. My German is not very good, but from what I was able to read, it seems like they are just using VNC to transmit the port information for doing esd forwarding. Presumably this saved a lot of work because no server side code was needed. Regards, Anthony Liguori Ciao, Dscho ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] ?off? ide/code editor under linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 NyOS schrieb: Hi! I think it might be a bit offtopic here, but I'm already on the list, and I'm interested in some experienced users' opinion. I can find ads on google, but not experience. I'm looking for a good IDE (or just a good code editor) under linux. My first try was kdevelop approx. 3 years ago (2.2.2 version). It was too complicated. 3.x.x is a bit unstable. Vi is unconfortable for me, I prefer using pico and gnu nano, but it's too stupid for some tasks. kdevelop is quite nice, but has some bugs, and shortcomings. If you're looking just for an editor, I would recommend kate (which I use for daily work, whenever I don't need a big IDE). It can be extended with plugins and scripts, so maybe you could write a script to do the template stuff. Also, AFAIK Gnome's gedit can be extended with Python scripts, which might be even better than the shell script / C++ plugin solution of kate. Regards, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFE1hb7TFOM6DcNJ6cRAu4QAJ9Xu2TKuri9Uv//p+3kj1zrLEFsQgCgjQnH y8FFrBhPJw4gFGk7E3YgCCc= =Z+Bp -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] What can qemu do that vmware/virtual pc can't...article idea
Udo 'Robos' Puetz wrote: Hi List. I'm in contact with one of the writers for the german (large) computer magazine c't (computer and technology) defending qemu (he neglected some features qemu has in one of his articles). Now he asks me for an article about what the average user would benefit from when he would use qemu instead of virtual pc/vmware (their free products, like player, ESX ...). The examples I named up to now where qemu -nographic -hda linux.img -kernel linux-2.6.17.6/arch/i386/boot/bzImage -append console=ttyS0 root=/dev/hda ide2=noprobe ide3=noprobe ide4=noprobe ide5=noprobe -hdb fat:/mnt/data/Projekte/qemu/linux-test/bla doing a little linux kernel driver development learning this way. (Good free pdf over at oreilly) Also, when testing OCFS2 (Oracle cluster fs 2) and not having a SAN/iSCSI system at hand I tried this: qemu -hda breezy.img -hdb ocsf2.img mounting that image once qemu -hda breezy.img -hdb ocsf2.img and now mounting it again in a second instance of qemu with slightly different network setup. That works with qemu, vmware desktop wouldn't take the image a second time. Also, a demonstration LiveCD could be made to boot on a system but also to be played with qemu/qvm86 under win and linux (kqemu can't be re-distributed). There would be statically built qemu's on the CD with bat/bash skripts to start them (automatically). Also, qemu can run happily on the server awaiting connects via vnc. But some of the free products can do that too. Soo, do you have any more ideas what qemu can what the (free) alternatives from M$/VMWare can't? Virtual PC can't handle USB _at_all_, what's the status of USB2.0 with qemu ( I think VMWare is still stuck on USB 1.1 )? VMWare Desktop (not free) has unlimited snapshots IIRC, ESX just recently got one snapshot functionality. I can't say if I would do the article or the writer for the magazine but at least it would make qemu more visible to (more technical inclined) people - good in my eyes. Thanks for your suggestions Cheers Udo Maybe qemu is not of so much use for the desktop user, but has its strength more in the direction of a generic computer emulator platform where other projects can build upon (see Argos or Free Live OS Zoo). I'm not sure if Qemu really can compete with VMWare for a desktop virtualization software. In my opinion the big advantage of Qemu is that it's open source. That makes it possible to use it as a basis for other projects; that also makes it possible to build the Live CD you mentioned. Another point is that an open source software is more likely to be shipped with Linux distros (OTOH VMPlayer is already available in some Ubuntu package repository, so this depends more on the distro maintainers). And if one wants to have a reliable platform to run legacy applications, an open source software has the advantage that you're not dependent on some company that might not exist in twenty years. Another point is the support of many host and guest platforms. But I think all this doesn't really help the desktop user. What I think is quite nice is the USB tablet emulation. At least VMware requires that the VMWare tools are installed for mouse switching between host and guest. It's quite astounding that in Qemu this works (at least with Windows guest) without installing additional software. So, IMHO you shouldn't try to praise Qemu as an end-user desktop virtualization software; presenting it to more technical users seems like a better idea. Regards, Oliver ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI
Linas Žvirblis wrote: Jason Gress wrote: I know this is a lot different than the discussion so far, but has anyone considered keeping SDL and using an SDL GUI similar to ZSNES? I did not check the source code, but it looks just like any other self-made bitmap-based SDL menu I have seen. It is like inventing yet another GUI toolkit. I am new around here, so I am a bit confused. What is this GUI all about? Is it about (a) replacing SDL with something else for drawing the contents of the window, or (b) providing GUI for configuring virtual machine options, just like numerous front-ends already do? I assume this is (a), as it is beyond me why would anyone want to do (b), when there already are front-ends for Windows, KDE, GTK+, Java, MacOS, etc. Personally, I'd be interested to have a GUI for controlling a running Qemu instance: change CD-ROM, add/remove USB devices, save/restore VM snapshots (though this would also require to save/restore disk snapshots), and eg. provide buttons to switch between guest Virtual Terminals. Furthermore, I'd like to get information like guest CPU usage and guest hard disk access; this would probably require that the GUI is integrated into Qemu. Whether actual graphics output is done via SDL or GTK or something else is probably not that important. Configuration could still be done with the current command line flags, but if one of the many config GUIs could be integrated into Qemu, that might be useful as well. Regards, Oliver ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: wxWidgets and C: was Re: [Qemu-devel] QEMU GUI
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim C. Brown schrieb: For the record, we can use wxWidgets in qemu even though we can not use C++ in qemu (something that I would be strongly against). http://wxc.sourceforge.net/ Requiring this as a dependency would make it easier to deal with issues such as C++ ABI compatibility by avoiding the direct use of C++. There's a QtC that I considered using for a Qt GUI for qemu. Is wxC still under active development? The CVS version seems to be quite old, and I also couldn't find any documentation. Generally it might be quite difficult to find a GUI toolkit with C bindings (besides GTK), as most toolkits seem to be targeted at an object-oriented language, and many go into the direction of script languages and rapid application development. So I think we should either just use GTK, or make Qemu ready for integration of C++ GUI code (and use one of the common GUI toolkits), or add an interface for external GUIs (and run the GUI as an external process, written in Python or Perl or the like). Regards, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEsCLoTFOM6DcNJ6cRAp4dAJwPa7JW7JJzBkg3GnsP+XskTVtAPwCgzpr1 W9RuT6XdO66GtD8evBXfDKc= =inA8 -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
Christian MICHON wrote: you're putting c++ inside the qemu source tree when it is not needed (yet). if SDL is common to most guest screens: I agree with you that the gui/toolkit should overlay the SDL. Yet Fabrice mentionned months ago this was not his intention, so we should respect it and (hopefully) close this long thread. Close the thread? Please not - I think it's good that many people posted their ideas about a GUI, and maybe there will finally come some agreement about the techniques and libraries that should be used. And if Fabrice doesn't want C++ in the tree (seems a bit reasonable), then there's still GTK. And if it is too difficult to install and run a GTK GUI under Windows, then a native Windows GUI is still possible (after all, the Mac OS X version uses a native GUI toolkit as well, so why not do the same under Windows, and use the GTK frontend under all other platforms). Btw. it would be interesting to know what features would be required to get a GUI into the Qemu tree, and what would be a total showstopper... Maybe the people with commit permission could comment on this :) Regards, Oliver ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
Joe Lee wrote: Some of us appriciate the fact that qemu has no GUI per se. ;0) Your right! the keyword is some but not all. I think if QEMU is to be adopted by the masses it will need to come up with a quality GUI-Frontend. However the CLI can always be in place for those who want and prefer to use it. Otherwise, I think most users will prefer to stay with VMware and especially that there VMware player AND VMware server edition is now FREE. I appreciate the effort that some are making to develop a GUI for QEMU - There's a few project I see that trying to achieve this. But, I wish they all could come together and work together to develop a nice GUI. I would like to see a sub-project exist in the QEMU site so all can come and contribute to that effort. IIRC Fabrice has (quite some time ago) stated that he'd like to see a Qemu GUI that is integrated into the app (ie. not an external application that only captures the Qemu window), and also that the GUI should be done in GTK (though I'm not sure about the exact wording, so I might be spreading false rumours here ;) This would mean that the next steps for a GUI would be to migrate input event handling and graphics output from SDL to a GUI toolkit like GTK. Incidentally, that is more or less what the patches do which are floating around on the mailing list. I guess the reason why they were not integrated in CVS is that they are quite big and intrusive, and that Fabrice waits for some more feedback and testing of the patches. So, in the end, testing is probably something that anyone can do who has enough spare time and wants to put that time into developing a GUI for Qemu :) Regards, Oliver ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Johannes Schindelin schrieb: Hi, On Thu, 15 Jun 2006, Joe Lee wrote: BTW, I am curious to know how much would it cost to develop a good GUI-Frontend for QEMU that would be comparable to VMware. How much man hours would this likely take? I do not know VMware. Anybody? I would be interested, too, to know how complicated that frontend is... There are some screenshots of VMware Workstation at http://www.vmware.com (see Products menu). Didn't find screenshots of VMware Player there, but Google image search shows a few for VMplayer. Should not be too difficult to reproduce it in Tcl/Tk (with a proper Tcl script as config format). If you are familiar with Tcl/Tk, maybe you could give some hints on how to embed the Qemu window into such an app? I think there are only two ways for making a GUI: - - embed the Qemu SDL window into another application (there seem to be various hacks that do this under X11; not sure about Win32) - - replace Qemu's SDL part with some GUI toolkit (GTK, Tcl/Tk...) I guess the second way is quite a lot of work. The first way is a bit hackish, as eg. events have to propagated from the GUI app to the Qemu window... how would this work with Tcl/Tk? Probably with the second way it would also be difficult to display real-time status info in the GUI (eg. guest CPU load, guest HDD accesses, network accesses). Regards, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEkd9lTFOM6DcNJ6cRArqJAKC5wiG3lsVMA5TmNp7EdqRa1cDbrQCeNGI2 8oVTKgDXpLo2QJN0NxQQP/U= =IACV -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Doing a Tcl/Tk based frontend
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel P. Berrange schrieb: On Thu, Jun 15, 2006 at 05:52:14PM -0500, John Morris wrote: On Thu, 2006-06-15 at 17:29, Oliver Gerlich wrote: If you are familiar with Tcl/Tk, maybe you could give some hints on how to embed the Qemu window into such an app? Embedding the emulator's window might not be the best way to attack the problem. Especially since you would need to be able to detach it to be able to go full screen. I have pondered the Tk frontend idea before so lemme dump my random thoughts on the subject and see how many holes get punched in em. With the new VNC server capability there is no need to embed the emulator's existing window. You can just have a GTK/QT widget which acts as a VNC client taking the video feed displaying directly within the GUI management app. Similarly you can redirect the QEMU monitor console to a UNIX pipe when lauching QEMU, so the management app can fully control the QEMU engine to do suspend/resume, snapshots, media changesi. I wrote an GUI app in Python which did the latter already: http://people.redhat.com/berrange/olpc/sdk/olpc-qemu-admin-demo.html At the time I wrote it there wasn't any VNC support in QEMU, so I couldn't hook up the display, but with the 0.8.1 release it wouldn't be much effort to embed the display directly in the app via VNC. So I don't think there are any changes required in QEMU itself to be able to create a fully featured QEMU frontend easily on a par with VMWare Desktop, if not better. Regards. Dan. VNC is a good idea... But isn't it a bit laggy for this purpose? I think people accept a laggy mouse cursor in a VNC window that comes over the network, but won't really accept that in virtual machine that's running directly on their desktop. OTOH, I'm no VNC expert :) and maybe there are tricks to speed this up?! Regards, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEke5ATFOM6DcNJ6cRAoRrAKCh1pM+Ig5WTv4ZeoGSvkjtT7M/mACeM1XL iH7ztKK9+HwNsnO5EA0XqBA= =gGkF -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Johannes Schindelin schrieb: Hi, On Fri, 16 Jun 2006, Oliver Gerlich wrote: Johannes Schindelin schrieb: On Thu, 15 Jun 2006, Joe Lee wrote: BTW, I am curious to know how much would it cost to develop a good GUI-Frontend for QEMU that would be comparable to VMware. How much man hours would this likely take? I do not know VMware. Anybody? I would be interested, too, to know how complicated that frontend is... There are some screenshots of VMware Workstation at http://www.vmware.com (see Products menu). Didn't find screenshots of VMware Player there, but Google image search shows a few for VMplayer. Thanks. But I would like to know if there is a developer who has experience with the GUI. It is one thing to see the GUI, another to work with it. Should not be too difficult to reproduce it in Tcl/Tk (with a proper Tcl script as config format). If you are familiar with Tcl/Tk, maybe you could give some hints on how to embed the Qemu window into such an app? I would go the easy way: just before starting QEmu, hide the Tk window... no need for embedding. Yes, I know this is a lame answer. But I am quite certain that most users would be happy about it. They do not *need* to do something fancy. They run the virtual machine, shut it down, and that's it. Heh :) that's what the current Qemu GUIs do already (many of which are mainly configuration GUIs). Thinking about it, at this point maybe an official configuration file format would be useful for all frontends and would really help unifying the GUIs (there has been a lot of talk about this already anyway). Regards, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEke9mTFOM6DcNJ6cRAkLIAKDkkPPgGVR6OHyQ6sD5h71OYO5zYgCgkb6I KzNbrMmbEBuYzPgQ5fck5BA= =e/PC -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VMware Player
Joe Lee wrote: Why on earth would we want to make a crippled version of qemu? AFAIK Creating a VMware virtual machine is just making a config file. qemu doesn't have config files, so your question makes no sense. Well, I was not thinking or suggesting of a crippled qemu version. I asked the question because there are some software appliances which are pre-built and pre-configured apps that are built on a LAMP stack and packaged as a single image type file. This image file can be downloaded and run on a product similar to VMware Player. This is used for quick demo purposes of an application with out the need to have a full virtual machine. What exactly do you mean / what is the actual use case for your idea? Maybe you mean something like this: http://www.damnsmalllinux.org/usb-qemu.html Btw. regarding your earlier question about a Qemu GUI similar to VMware: AFAIK at least two people have posted GUI patches for Qemu (look in the mailing list archive); so far there has been little response to that, and I suppose that these patches just need testing and some feedback (as they seem to be pretty intrusive, with changing the video output and the input handling stuff). Regards, Oliver ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [Patch] Publish VNC display with zeroconf
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
here's a little gimmick for VNC support :-)
The patch makes Qemu publish its VNC display via zeroconf if it is
called with -vnc option. The patch uses the avahi-publish helper app for
this, which comes with the Avahi suite (eg. in Debian and Ubuntu it's in
the avahi-utils package). If avahi-publish is not installed, this patch
won't do anything.
With the patch applied, you can use the service-discovery-applet under
Gnome to see all Qemu instances which use VNC. Under KDE, Krdc offers a
list of all zeroconf-published VNC displays (choose DNS-SD from the
listbox in the upper left corner in Krdc).
Regards,
Oliver
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.3 (GNU/Linux)
iD8DBQFEZ0X5TFOM6DcNJ6cRApiCAJ0dSa115JeNvXu9PfND5R+E4TqyeQCgvDlK
ROoGXIBo2gVLK104J2uKz1M=
=8tDu
-END PGP SIGNATURE-
--- qemu-0.8.1/vnc.c2006-05-03 22:32:58.0 +0200
+++ qemu-0.8.1-avahi/vnc.c 2006-05-14 16:21:05.0 +0200
@@ -64,6 +64,11 @@
size_t read_handler_expect;
};
+#ifndef _WIN32
+#include signal.h
+pid_t mdns_publish_pid = 0;
+#endif
+
/* TODO
1) Get the queue working for IO.
2) there is some weirdness when using the -S option (the screen is grey
@@ -852,6 +857,71 @@
}
}
+#ifndef _WIN32
+static void vnc_unpublish_mdns(void)
+{
+if (mdns_publish_pid != 0)
+{
+kill(mdns_publish_pid, SIGTERM);
+}
+return;
+}
+#endif
+
+/// Publish VNC display via mdns/zeroconf using the Avahi suite.
+/// See RFC 2782 and avahi-publish(1) for more info.
+void vnc_publish_mdns(int port)
+{
+#ifndef _WIN32
+// Execute avahi helper program in a child process.
+pid_t childPid = fork();
+switch(childPid)
+{
+case -1:
+// fork() failed; ignore this.
+break;
+
+case 0:
+{
+// New child process.
+char name[250];
+char portString[10];
+char *argv[10];
+int i = 0;
+
+sprintf(name, QEMU instance on port %d, port);
+sprintf(portString, %d, port);
+
+argv[i++] = avahi-publish; // avahi-publish is a helper program
from Avahi that publishes DNS-SD records.
+argv[i++] = -s;// Flag: publish a service.
+argv[i++] = name;// Name of the service
+argv[i++] = _rfb._tcp; // Service type (see
http://www.dns-sd.org/ServiceTypes.html)
+argv[i++] = portString; // TCP port
+argv[i++] = NULL;
+
+// Close stdout/stderr to suppress output from avahi-publish
+close(STDOUT_FILENO);
+close(STDERR_FILENO);
+
+// Execute avahi-publish
+execvp(argv[0], argv);
+
+// This point might be reached, eg. if avahi-publish is not
installed.
+exit(0);
+break;
+}
+
+default:
+// Parent process. Record child pid and set exit handler.
+mdns_publish_pid = childPid;
+atexit(vnc_unpublish_mdns);
+break;
+}
+#endif
+
+return;
+}
+
void vnc_display_init(DisplayState *ds, int display)
{
struct sockaddr_in addr;
@@ -918,4 +988,6 @@
memset(vs-dirty_row, 0xFF, sizeof(vs-dirty_row));
vnc_dpy_resize(vs-ds, 640, 400);
+
+vnc_publish_mdns(5900 + display);
}
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] PATCH: fix bgr color mapping on qemu on Solaris/SPARC
Dan Sandberg wrote: Paul Brook wrote: On Wednesday 10 May 2006 23:05, Fabrice Bellard wrote: In order to stop the release of incomplete BGR patches, I am implementing a more complete patch. I am just adding depth = 32 with BGR instead of RGB. If other pixel formats are wanted, you should signal it now. I don't have any paticular favourite pixel formats, but qemu now has [at least] 3 different sets of low-level pixel conversion routines (vga, tcx and pl110). If you're feeling really enthusiastic it would be nice if they could be unified :-) It's one of the things I've been meaning to look at when I've nothing better to do, but haven't got round to yet.. Paul ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Hi, some comments on your suggestions: Just curious... Are you using an OpenGL directdraw surface for the graphics emulation in Qemu? If not, then consider the benefits: 1. It is much faster than any native graphics 2D/3D primitives like Windows GDI Not sure how much faster it is on Windows; currently Qemu uses plain SDL for drawing which probably uses DirectDraw under Windows. However, AFAIK under Linux SDL is not hardware accelerated in most cases, while OpenGL could give hardware acceleration. 2: It gives full control over things like window or fullscreen mode in any (almost) resolution and color depth. AFAIK the windowing/fullscreen stuff is not done by OpenGL itself, but by some external library; SDL offers this functionality, GLUT is another possibility, and apparently the GlScene lib you mentioned does this as well. 3. It is operating system independent. 4. It handles things like RGB, BGR, 24bit, 15bit, 16bit, 8bit, alpha channel etc in hardware, all you have to do is select the pixelformat you like to use for the buffer and OpenGL does the rest - lightning fast, minimum CPU-load. Basically, that sounds like a good idea to me. My suggestion would be to write a frontend similar to VMware's for Qemu in Lazarus. Why Lazarus? 1. The fantastic GLscene is available for Lazarus making OpenGL-programming easy. Try: http://www.skinhat.com/3dpack/ 2. With Lazarus a RAD graphic frontend based on OpenGL can be made and directly compileable for most operating systems without need for modifications. Hope someone likes the idea, otherwise I will have to do it myself if I can find some spare time. Dan Before you start working on this, I have some suggestions as well: Is the drawing part really a performance bottleneck? And will this really be improved by changing the drawing functions, or wouldn't a better graphics card emulation give much more improvements? What does a profiler say about this? I seem to recall that in most cases, SDL doesn't slow down performance in Qemu. It might be interesting to see how much the new RGB-BGR conversions costs, though. Another thing that I think is important is that not all computers have OpenGL acceleration. And at least on Linux, software OpenGL rendering is quite slow, so a port to OpenGL would probably be a huge drawback for some people. If OpenGL is really worth the trouble, one could add OpenGL rendering so that people can still use the old way of drawing if no hardware acceleration is available. A GUI frontend would be quite nice, I think. So far several people have submitted (quite useful) patches for this, but nothing more has happened in that direction. Not sure what is required for a GUI that will be integrated into Qemu finally... Thanks, Oliver ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] bug reports and suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim C. Brown schrieb: On Sat, May 06, 2006 at 01:12:50AM +0200, Oliver Gerlich wrote: Don Kitchen schrieb: Next, it seems the *one* thing QEMU lacks that you-know-who does correctly is networking, specifically bridged mode. I know about creating a tap device and sticking it into a bridge (really hasn't worked for me, but that's the subject for a different day.) I realize that it's a complicated issue requiring kernel modules, etc, and exponentially more complicated with cross platform, but I wonder if anyone has considered trying to tie into the vmware-player's kernel modules and use them? There has to be some sort of de-facto API for interaction between the modules and the player. Too rife with IP problems? Someone wrote a kernel module some months ago which exposes some special kernel function via /proc ... IIUC this was intended to allow easier networking... Does anyone know more about it (or did anyone understand my confusing description ;) ? I'm the author. It is called vde-inject, and it requires vdeqemu to work atm (though adding native support in qemu itself is trivial). Thanks! That's the module I meant :) Currently I'm working on a version that doesn't require a kernel module to do this - it will have the limitation of only supporting tcp/ip packets when talking between host/guest. Are you sure that limitation is not too heavy? How would eg. UDP, ICMP or Multicast DNS work with the non-kernel-solution? And wouldn't an ethernet-level emulation be cleaner and also easier to explain to other users? Another interesting thing concerning networking: I use a little script to set up a bridge between eth0 and tap0; but I have give the new bridge interface (eg. br0) an IP address and such stuff, because eth0 doesn't work. This is with Linux 2.6, but I read that with Linux 2.4 it was not necessary to configure br0, as eth0 would still be accessible. Does anyone know why this changed? I think it would be much easier if an interface used in a bridge was still usable. eth0 is still usable. It is just slightly cleaner to use br0 directly. This is what I tried: brctl addbr br0 brctl addif br0 eth0 After this, a ping to the IP of eth0 (192.168.0.10) still worked. But a ping to the gateway (192.168.0.1) didn't. Running `ifconfig br0 up` didn't help either. Do you have a hint how to make this work? Thanks, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFEX3pLTFOM6DcNJ6cRAsTuAKCvN0b68WV/dFsznXWhv+tfaxvZZgCfdYLp VKEpNiUYKchHgRswHIL/BGo= =cTW3 -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] bug reports and suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Don Kitchen schrieb: Next, it seems the *one* thing QEMU lacks that you-know-who does correctly is networking, specifically bridged mode. I know about creating a tap device and sticking it into a bridge (really hasn't worked for me, but that's the subject for a different day.) I realize that it's a complicated issue requiring kernel modules, etc, and exponentially more complicated with cross platform, but I wonder if anyone has considered trying to tie into the vmware-player's kernel modules and use them? There has to be some sort of de-facto API for interaction between the modules and the player. Too rife with IP problems? Someone wrote a kernel module some months ago which exposes some special kernel function via /proc ... IIUC this was intended to allow easier networking... Does anyone know more about it (or did anyone understand my confusing description ;) ? Another interesting thing concerning networking: I use a little script to set up a bridge between eth0 and tap0; but I have give the new bridge interface (eg. br0) an IP address and such stuff, because eth0 doesn't work. This is with Linux 2.6, but I read that with Linux 2.4 it was not necessary to configure br0, as eth0 would still be accessible. Does anyone know why this changed? I think it would be much easier if an interface used in a bridge was still usable. Thanks, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEW9vwTFOM6DcNJ6cRApc8AJ9qYCEBHJqu/TsWilH5ztnx+PF8wACffVTp 2AbeG8IcGxMz3lO1BUeZ3gY= =a4mn -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] kqemu-1.3.0pre6 doesn't work with Win98
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, after switching from kqemu-1.3.0pre5 to kqemu-1.3.0pre6, Win98 guest stops during boot with Windows protection fault. Qemu is started with qemu -hda win98/win98-new.img -boot c (I used the same command line successfully with old kqemu). Any idea what could cause the regression? Thanks, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQFEWnATTFOM6DcNJ6cRAqTFAJ9XoR77j1MkA853zGS02Vl6uohrkACgrRA1 uQkBC0wBdxgyikD4+EDbMZA= =D7i0 -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] [Patch] configure: check if specified compiler exists
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
the attached patch adds a check to configure to see whether the compiler
really exists. If configure is called with --cc , but the given compiler
doesn't exist, configure currently fails without giving a good reason.
(In my case I ran ./configure --cc=gcc-3.4 but gcc-3.4 doesn't exist
on the system; configure then told me that it couldn't find SDL, without
hinting at the real reason. The little notice that the endian check
failed as well escaped my eyes :-)
Regards,
Oliver Gerlich
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFESiVaTFOM6DcNJ6cRAo0uAJ0TJF7sFxTg54uh6yHUt83CsusIugCg0GX6
AmFu4u1SAAT3DIl3vwmIvfY=
=3dbm
-END PGP SIGNATURE-
--- configure-old 2006-04-17 15:57:12.0 +0200
+++ configure 2006-04-22 14:37:43.0 +0200
@@ -283,6 +283,11 @@
ar=${cross_prefix}${ar}
strip=${cross_prefix}${strip}
+if [ -z `which $cc` ] ; then
+echo Compiler $cc could not be found
+exit
+fi
+
if test $mingw32 = yes ; then
linux=no
EXESUF=.exe
___
Qemu-devel mailing list
Qemu-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] VLAN inside qemu
octane indice wrote: Hello, I'm trying to experiment VLAN networking with qemu but the doc doesn't help me at all. I want to setup a LAN composed by qemu host, each guest communicating with each other. It's for testing etherboot. I want to have a host e.g. 172.16.12.1 acting as a DHCP/TFTP/nfs server and several clients (at least 2) connecting with it. What could be the command line to launch these qemu? Is tun/tap unavoidable? Thanks Ce Caillou-là un conte en téléchargement gratuit sur http://www.Manuscrit.com ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Maybe the -net socket option helps in this case - see the QEMU doc for an exact description. There are also some threads about this option in the forum (search for net socket). Regards, Oliver Gerlich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Remote console access though socket
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Veillard schrieb: Hi, enclosed is a first version of a patch to allow remote access and control for QEmu instances, I'm not suggesting to apply it as is (though it seems to work in my limited testing) but would rather like to get comments back for choices I'm facing. [...] There is a number of open questions which would need to be resolved before applying any such patch: - First one is the unix socket, we could as easilly start normal port based access but: + I would really like to be able to list the current running instance without checking all process on the OS, and mapping in the file system seems the easiest way Just an idea: how about using Multicast DNS (see multicastdns.org)? IIUC it provides a generic way to find services on a net; and it's supported at least by MacOSX and with eg. Avahi (see avahi.org) also on Linux. Not sure about Windows, though... Regards, Oliver Gerlich -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEEvnHTFOM6DcNJ6cRAhe4AJ9LAQwIb25gCuIHKiRoIMLwJzkt4wCgoEXh kjk2Gejn8X+p1tyCeryHqYA= =z3wY -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Remote console access though socket
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Veillard schrieb: On Sat, Mar 11, 2006 at 05:24:40PM +0100, Oliver Gerlich wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Daniel Veillard schrieb: Hi, enclosed is a first version of a patch to allow remote access and control for QEmu instances, I'm not suggesting to apply it as is (though it seems to work in my limited testing) but would rather like to get comments back for choices I'm facing. [...] There is a number of open questions which would need to be resolved before applying any such patch: - First one is the unix socket, we could as easilly start normal port based access but: + I would really like to be able to list the current running instance without checking all process on the OS, and mapping in the file system seems the easiest way Just an idea: how about using Multicast DNS (see multicastdns.org)? IIUC it provides a generic way to find services on a net; and it's supported at least by MacOSX and with eg. Avahi (see avahi.org) also on Linux. Not sure about Windows, though... It's rather LAN oriented, Yes, that's a bit ugly. I need first to find the ports of the QEmu instances (plural, if you limit to one per box, then you can block the default port number and there would be no problem) on a local machine. I don't think that Multicast DNS/RendezVous works with random port numbers, all it does over normal TCP is scan for local hosts without using DNS resolution. Again I don't think it's really the problem I'm trying to solve, maybe I just didn't expressed myself clearly :-) Daniel After experimenting with the avahi apps a bit, I think mDNS can indeed advertise several services on the same host with different ports! I ran avahi-publish -s -H localhost myserver1 _http._tcp 80 in one terminal, then avahi-publish -s -H localhost myserver2 _http._tcp 12345 in another terminal. This advertised two HTTP servers which were running on my local host, on ports 80 and 12345, under the names myserver1 and myserver2. avahi-discover then displayed these two services, with their names and the correct port numbers. And in konqueror, browsing to zeroconf:/ also showed the two WWW servers correctly. So, this could provide the functionality you were looking for... But it still has the drawback that zeroconf seems to be quite a big framework, and it requires multicast DNS in the kernel and such stuff... Regards, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEE02jTFOM6DcNJ6cRAtgLAJ9e8YlWFi6Is9+w2yDcOTIJFr9h8QCgvz18 hXvZb+16P1W5QDhnkac1ywc= =d+pp -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Qemu - where will it go?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, that's an interesting topic you bring up there :D It looks like there are many different groups which all have quite different uses of qemu on their mind... Jürgen, you think about a _really_ stable hardware platform; other people think about a honeypot framework; even other people want to have lots of different system architectures for software development and testing; I myself just want a way to have a Windows available on my Linux PC, for gaming and running Windows apps. Not to mention the various toy-like uses, like the Linux screensaver. And if I got that correctly, one of the original uses of qemu was to run wine on PPC - ironically, this is probably not such an issue now, with Apple switching to x86 :) So, to me it seems like the many different uses of qemu indeed need a very different qemu each; and though I'm not a qemu developer at all (and hence can't demand any specific direction of development), I'd be glad if qemu wouldn't just go into one direction. Maybe it is indeed about time to think about the main uses that qemu should satisfy. For me, that would be the Windows-sandbox on my Desktop Linux: with a nice GUI, an assistant to help with the creation of a new image, with some guest-side tools for more convenience, with not too slow graphics, and without big ties to the host system. Jürgen has stated his desired functionality already. What other main uses are there? (Asked in the hope of further sparking the discussion ;) To summarize what in my opinion are the most important advantages of qemu: Over eg. VMware and VPC, it has these advantages: - -small - -easy to install; VMware requires a kernel module from the start, and requires running of an installation script (*yuck* and that in times of RPM and APT). - -Open Source (= possibility to meddle with it by myself; and no dependency on a self-centered, not-to-be-trusted company) Over Wine, qemu has the advantage that it runs guest apps without any worrying whether the emulation is complete enough for that app. Over Xen and UML, it has the advantage that it runs Windows, even without special hardware. Over Bochs, it has the advantage that qemu runs fast yet still reliable enough. What other product did I miss that might compete with qemu? What advantages of qemu did I miss? Thanks in advance for your replies, Oliver Juergen Pfennig schrieb: Hello dear readers, as I found out qemu is quite stable and has acceptable performance. Using it you could freeze legacy applications using a legacy OS like win 2003 or win XP. I am talking of periods from 5 to 20 years! In a commercial environment it happens frequently that you would like to access old data but cannot do so because the hardware is gone or the old software does not work with the current OS. Commercial vm solutions cannot really do that - as they are not open source you only move the dependecies from hardware to a software vendor. Both usually become unavailable over time. Hardware vitualization (xen, vanderpool) is also not an ideal long-term solution, you become again hard-ware depending... This is what makes qemu so interesting for industry and business. But a lot of work would have to be done. The next steps of development would probably include: - run qemu as a service (on Windows or on Linux using xinetd) - make rdp (Win Terminal Server) work when qemu started via xinetd - improve disk image format, better snapshot handling - make a plugin architecture for the host side device implementation - allow 'remote' host side devices (sound, usb, serial ...) - define a protocol to use qemu over a network (should multiplex video, sound, usb, serial and so on). So you see: in a commercial and or industrial application one would like to run the qemus on a server. At least the MS remote desktop protocol should work well. A qemu specific client would be nicer. Please do not try to make the current qemu program a better GUI application - do it the other way: move SDL out of qemu and write an extra client app! I did not find any information concerning the plans that the maintainers of qemu have. - currently it is simple and easy to understand. It has supringly few lines of code. - the concept would allow for better performance (dynamic code generation could use optimization to eliminate inter module function calls, see some of the java jit propaganda). - currently the code translation cache is a problem for old-style windows apps. Word and friends run slowly as the cache runs full and gets rebuilt too often. The current implementation may lead to degeneration, e.g. a very low cache hit ratio. - obviously a generational code translation cache should be used, e.g. frequently executed code would not be lost but would be promoted to the next generation cache. See the .net gc propaganda. - Finally one could take some ReactOS drivers to get better
Re: [Qemu-devel] Parallel Port Support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Trev Jackson schrieb: Hi everyone I looked at the code (vl.c) and I don't know if I am missing something, but as far as I can see unless the parameter passed to -parallel is either vc null pty or stdio the function qemu_chr_open function that is called returns null, which sets parallel_hds[0] to null, which in turn causes the error message qemu: could not open parallel device to print and exit the program. Sorry, I guess I overlooked in the forum thread that you use the binary version :( The host parallel port support is at the moment only available in the CVS version (the CVS log message is at http://lists.gnu.org/archive/html/qemu-devel/2005-11/msg00185.html). So, if you want to use the host parallel port with qemu, you should upgrade to the current CVS version. Daily CVS snapshots are available at http://qemu.dad-answers.com/download/qemu/ Regards, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDn0AGTFOM6DcNJ6cRAsJJAJ9uWg65F93tbPnlPeXd+uXRiCy4EACfbkmc IbMxcTVJU0iZSBHWxwf2E+s= =k8KL -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Parallel Port Support
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Trev Jackson schrieb: Sorry, I guess I overlooked in the forum thread that you use the binary version :( The host parallel port support is at the moment only available in the CVS version (the CVS log message is at http://lists.gnu.org/archive/html/qemu-devel/2005-11/msg00185.html). So, if you want to use the host parallel port with qemu, you should upgrade to the current CVS version. Daily CVS snapshots are available at http://qemu.dad-answers.com/download/qemu/ Regards, Oliver Thanks for the answer The snapshot appears to be 46 bytes in size. Wow... looks like Fabrice stripped down Qemu to its bare minimum during the past days ;) Seriously, probably the script which downloads the CVS version every day broke somehow... But I can confirm that it still worked on 2005-12-07, though. I would be grateful if you would let me know how to download from CVS or how to download the snapshot without it downloading only 46 bytes. On the Qemu website, on the links page, there's a link to the page which also hosts the Qemu CVS. The quick link to the relevant page is probably http://savannah.nongnu.org/cvs/?group=qemu Regards, Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDn0qTTFOM6DcNJ6cRAsSxAKCyfV0X6ZRCm/+aDK8OAgZJMeAqvgCfVY7X K0np1HEIogexFKEmn3HqfRI= =JnFD -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] GTK GUI for QEmu
Jim C. Brown wrote: - -the software scaler is maybe a good idea, but for fullscreen mode, I'd better like to have screen resolution switched to qemu guest resolution (as it is with normal qemu now) The problem is that is really hard to do. Especially in a cross platform manner. I couldn't figure out how to scale it for full screen, but that was my original plan. Another benefit of scaling is that you can resize the window without harm: if the text is too small to read then just make the window bigger. - -sometimes the mouse can't be moved beyond some point on the guest screen... But I don't know when that happens and cannot really reproduce it I think I know what you're talking about. I had this problem with my gtk code as well. This is because the host and guest pointers are not 'sync'ed, so when the host mouse hits the edge of the screen, the guest pointer also halts (even if it's not at the edge). GTK provides no way to fix this - basically you need to test when the pointer is at the edge and warp it to the opposite side. But this requires platform specific code (however I did write up the X and Windows versions). The cause of the problem becomes quite obvious if you don't make the host pointer invisible when you grab the mouse. Wouldn't these two things be solved by using SDL inside the GTK window? In current qemu, there are neither fullscreen nor mouse moving problems. Fabrice mentioned some time ago that SDL isn't the best choice on Windows because of keyboard issues... Is that still the case? Oliver PS: Arrg... no need to wonder why the mail doesn't appear on the list - I replied to Jim only. Here it is again. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Batch mode via Scripts for Qemu?
Dave Feustel wrote: Is there any way to control Qemu with a script? (e.g. start Qemu with Qemu -S -hda disk.img then feed the commands loadvm vm state file c ... stop savevm vm state file q to the monitor console) Thanks, Dave Feustel You can redirect the monitor to stdio and then send your commands over that connection. IIRC the monitor can also be redirected to a pty - maybe that's even better than stdio. Oliver ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] GTK GUI for QEmu
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Anthony Liguori schrieb: Howdy, I started working last week on a GTK GUI for QEmu. I've made enough progress that I wanted to share the results with everyone and collect feedback--especially any feedback regarding what should be added/changed for inclusion in Fabrice's tree. Here's a rough overview of the features: o XShmImage based display widget--initial performance tests indicate it has identical overhead to the SDL GUI. o GUI-based pause/save/restore/eject o Screenshot (supporting all formats of GdkPixbuf--png, jpg, bmp, etc.) o Video Capture (based on ffmpeg--currently uses mpeg1) o Fullscreen mode with autohiding toolbar (thanks to libview--http://view.sf.net) o Software scaling (so there's no black bars in full screen mode like with SDL) o XEmbed support (a pygtk based POC tabbed GUI is available at http://qemu.codemonkey.ws/qemu-tabbed.py) You can grab a tarball at: http://qemu.codemonkey.ws/tarballs/qemu-gtk-20051109.tar.gz Or you can clone my hg tree with: hg clone http://qemu.codemonkey.ws/hg/gtk A couple screenshots are available at: http://qemu.codemonkey.ws/screenshots/ Any feedback is greatly appreciated. A bunch of stuff is not there yet (there's barely any accelerator support so you can't get to the monitor yet) and I haven't tested on non true color X servers so your results may vary. Regards, Anthony Liguori ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel Hi, just a short feedback on your qemu gui: - -looks nice so far :) - -does it require a new(er) GTK? I only have 2.6.10 installed here, maybe that's why it doesn't find GTK_STOCK_LEAVE_FULLSCREEN - -make install misses camera.png - -the toolbar functions are useful (would be bad if they wouldn't ;) - -the toolbar hiding in fullscreen mode is really cool - -the software scaler is maybe a good idea, but for fullscreen mode, I'd better like to have screen resolution switched to qemu guest resolution (as it is with normal qemu now) - -sometimes the mouse can't be moved beyond some point on the guest screen... But I don't know when that happens and cannot really reproduce it - -mouse button up events seem to be delayed somewhat: when clicking on an icon on the desktop of a Windows guest and releasing the mouse button, then dragging the mouse will drag the icon a bit - -the windows key doesn't seem to work Apart from these (minor) glitches I quite liked the GUI. Btw. for the fullscreen mode you might want to have a look at the thread about Jim's GTK GUI - these issues have already been talked about there. Oliver -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDc9ifTFOM6DcNJ6cRAv+GAKCO2H5ygQZ/EaqONKEJlfcgeBUhYwCfSs3N 1W4s9lCI2EijvwnptDQrkMM= =zEgy -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Audio cd's in guest OS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Lars Roland schrieb: On 11/4/05, Mike Swanson [EMAIL PROTECTED] wrote: I've found on systems where traditional rippers don't work (eg, cdparanoia), CDFS has a greater chance of ripping the CDs (by default into WAV, but you can enable an option to rip it in the pure CDDA format if you want). Thanks - I should have known that someone had made a file system for this. However I still think it would be great to be able to pass the actual /dev/cdrom on to the guest OS, but I must admit that I have not grasped the complexity yet on doing this, so I am going to do some Qemu code reading before continuing - I am not even sure if it can be done in VMWare although I seam to remember that Windows as a host OS running VMWare allows the guest access to a audio cdrom. Not sure how VMware does that; but actually I didn't even succeed accessing /dev/cdrom on the host when an audio cd is inserted: dd if=/dev/hdc of=/dev/null bs=2352 count=1 dd: reading `/dev/hdc': Input/output error 0+0 records in 0+0 records out 0 bytes transferred in 0.077570 seconds (0 bytes/sec) I used a blocksize of 2352 because I've read that's the size for audio cds... It didn't work with bs=1 either. So maybe Qemu would have to access the cd drive on a lower level than via /dev/cdrom? Just my 2 cents, Oliver Gerlich -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDbJjvTFOM6DcNJ6cRAvMxAKChRu5Hs2CMtRcKdygnbKwBl5GoigCeL7XM XLYxM01N6If3A+9hCbF5wUQ= =edig -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Graphic card
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Swanson schrieb: 4. It sounds reasonable, but it undermines one of QEMU's goals: running guest operating system without modification (and drivers certainly count as one). Also, it'll possibly limit the number of operating systems you'd run in QEMU with fancy graphics... implementing Cirrus makes it possible to run many OSes with no (or few) video problems, including Windows 95, Win NT 4, almost every GNU/Linux, almost every BSD, Solaris, Darwin, Plan 9, QNX, DOS, BeOS, etc. I agree that it's good that Qemu emulates such a wide-spread graphics card... But I also think it's some kind of dead end. Not only does eg. BeOS not support that Cirrus card (last time I tried BeOS inside Qemu, it complained that the Cirrus card is too old :-) . Also I'm not sure whether the Cirrus card will ever be fast enough for that. Do real Cirrus 5446 cards offer hardware video acceleration? And do they offer 2d acceleration that can be used by DirectDraw? They certainly don't have 3d support, so if Qemu should have fast 3d graphics one day, it will certainly not work with the current graphics emulation. So, I think we shouldn't dismiss the possibility of a special Qemu graphics card (and driver). The Cirrus card (and -std-vga) should still be available for those systems where the Qemu graphics driver is not available, while the users who run a wide-spread, recent system as guest can have faster graphics. Just my two cents, Oliver Gerlich -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDZLY+TFOM6DcNJ6cRAoCxAJ9yAC8Th6DfuXnPQJ1m7mn85RvPoQCeKj6D 2XyhMcUQQ+lsy5bQn1IOuHY= =LoQ7 -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Qemu and Synergy?
John R. Hogerhuis wrote: On Sat, 2005-10-22 at 18:09 +0200, Oliver Gerlich wrote: So, any ideas here on how to easily use Qemu and Synergy? IMHO, Qemu would greatly benefit from these features. But I don't see a way to integrate the two programs. Do you? Very cool. Have you talked to the developers of this software? They probably have already given some thought to working with windowed virtual machines, and if they haven't I bet they would be interested in the concept. -- John. ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel So far, I've opened a thread in the Synergy forum at sf.net (see http://sourceforge.net/forum/forum.php?thread_id=1371199forum_id=199579), but there are no replies yet. Actually, I have no idea how to approach this, so I just posted it in their forum and on this list, hoping that people think about it and have some ideas... Regards, Oliver ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Qemu and Synergy?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, is anyone here using Synergy (see synergy2.sf.net) to make the mouse go smoothly from host to guest? At first glance, I'd say Synergy offers much of the stuff that's necessary for easing the use of Qemu: it can transport mouse and keyboard commands to another machine (to the Qemu guest), and it offers clipboard sharing. At second glance, Synergy moves the mouse pointer only when it reaches a screen border (for good interaction with Qemu, it should move the pointer whenever the Qemu windows is clicked or something like that). Also, communication is done over TCP/IP, which might not be available in all Qemu guests. So, any ideas here on how to easily use Qemu and Synergy? IMHO, Qemu would greatly benefit from these features. But I don't see a way to integrate the two programs. Do you? Regards, Oliver Gerlich -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDWmQdTFOM6DcNJ6cRAvDPAKDFRKTWa7QvagXXLSV0bIn6S+tbmQCglLRm T3deLbl6cLbtsILaXQEjaOs= =597v -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] tun/tap networking
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim C. Brown schrieb: On Fri, Sep 30, 2005 at 03:13:21PM -0700, Don Kitchen wrote: [...] I'm interested in the handling of ethernet frames because I haven't been able to get the bridge to pass packets between added interfaces (yes, they're all up and promisc) and I'm not too thrilled with networking being bridged anyway, Do you mean the kernel bridge, br0? Or are you talking about some sort of user space bridge, like bridged (which uses a series of packet sockets to bridge between multiple ethernet (ethX) devices) ? and it seems to me that if an fd were hooked up to a BPF capturing everything from the real ethernet device in promiscuous mode, and pushing out any raw frames it receives, that I could bypass the bridge and make it as if the emulator's virtual ethernet device is a real one. Or is there some reason this won't work? (after all, other products don't have this, there must be a reason right?) Ah, you're talking about using a packet socket, right? That works fine for the most part. There is one thing that you have missed though: guest-host communication doesn't work when you do that. When you push out a raw frame, it leaves the real ethernet device before the host sees it. So guest-host doesn't work. You need to find another way to send packets from the guest to the host. Most host OSes will not let you do this at all. (Windows seems to be the exception, winpcap's pcap_sendpacket() appears to work fine for that job.) That means it would work if the host NIC is connected to a switch? Then the switch would send packets from the guest which are meant for the host back to the host NIC and everything's fine! Or did I misunderstand that now? Regards, Oliver Gerlich -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDPnM2TFOM6DcNJ6cRAlTaAJ9gxN9CUnSEeKl5lPbURTEh33Rl8QCgpmNV cUuiGGOkpPVYxzeo9ZoksWM= =tEkV -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Connecting vde and LAN
Henrik Nordstrom wrote: On Wed, 10 Aug 2005, Jim C. Brown wrote: [...] The above should work for most situations where the host is a just a host on the LAN, but if the host is a LAN server for broadcast Ethernet protocols such as DHCP some additional configuration of each such service may be required to also listen on the tap0 device if the guest should be able to use these services. Quite likely also applies to some other protocols such as IPX or AppleTalk as these frames almost certainly will be ignored by the host on the tap0 device unless configured proper for each protocol. Couldn't we avoid these incompatibilities if we would route packets only on the Ethernet level? If the Qemu networking setup on the host involves IP addresses or such things, we're already on the wrong OSI layer I think... I'm not very experienced in networking, but IMHO the network should be set up like this: (eth0 on Host OS) / ( LAN ) (real eth0) - VDE \ (NIC on Guest OS) (substitute eth0 by the LAN network interface of your computer) So VDE acts as an Ethernet switch between LAN, Host OS and Guest OS. This would limit VDE action to the Ethernet layer. To connect to the LAN, VDE would use the real (physical) eth0 of the host system. When packets arrive from Host OS or Guest OS, they would be sent to the LAN with the source MAC addresses preserved. The connection to the Qemu guests should be easy as well (every guest has a MAC address anyway). The host part is really difficult: VDE would have to provide a faked eth0 to the host OS, so that programs on the host could still use eth0 as Ethernet interface. This faked eth0 would be connected to VDE just like the Guests are. I guess this means that VDE would have to provide a kernel-layer component which grabs the packets from eth0 and provides the faked eth0 for the Host OS... Although IMHO this is the cleanest way to set up networking, it's probably not possible to implement this :-) But maybe we could use it as a starting point for the networking. So this is a summary of what I think we should try to achieve (sorted by priority): -provide Ethernet-layer access from the Guest to the LAN (so that it's transparent for IP traffic) -allow using a LAN-wide DHCP server for the Guest -the host should be able to set up his LAN interface over the LAN-wide DHCP server. -the host networking still works as before (at least on the layers above Ethernet) -the whole thing is easy to set up -the whole thing can be started by any user at any time (so it's not started at boot time, but whenever a user starts Qemu). If we could achieve all of these requirements, it would be fantastic :-) But maybe we could at least reach some of them. What are your comments on this? Regards, Oliver Gerlich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Connecting vde and LAN
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, what is the best solution to connect the vde switch to my real LAN so that Qemu guests get IPs from my LAN-wide DHCP server? So far I've experimented with bridging tap0 and eth0 so that the Qemu guests are transparently on my LAN and get IPs from the LAN-wide DHCP server. But this has the drawback that my host network interface is now br0 instead of eth0 (that causes confusion at least for samba). Also I tried to set up IP forwarding between tap0 and eth0, but then the Qemu guests aren't transparently on my LAN (and don't get the correct config from the DHCP server). So, are there other solutions that offer the power of bridging with the simpleness of IP forwarding? What do you recommend to establish a LAN with real hosts and Qemu instances side by side? Such a setup could be interesting for all users who want more than user-net and who have a SOHO router at home which provides DHCP and Dynamic DNS! Thanks in advance, Oliver Gerlich -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFC0RQUTFOM6DcNJ6cRAgFJAJ9gfaQmw9E06h9Mr1C2Ugin/PcFagCfTh39 kc0bKVpqT4YFfx9FptEQaN8= =hHCt -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] Timing problems
Alexander Toresson wrote: I'm running windows 2000 in qemu 0.7.0 with kqemu 0.6.2-1 on i386 debian linux. First thing I tried to do was to run a benchmark program (qemu w/o kqemu vs qemu w/ kqemu). I got strange results, and I also noted that timing didn't seem to be that good, so I re-tried to run the benchmark program, but with the date clock settings window in the background. This is the result: The more cpu that is used in the virtual cpu, the faster time flies by. For example, when it's nearly idle, time is too slow. If it goes from idle to 100% cpu-use, time flies by at 5x the speed it should. This is true both when I use kqemu and when I don't. This cpu is capable of speedstep, but I have disabled it while doing this test. I think I would get even more weird results if I enabled it. This makes it impossible to run a benchmark and get any useful results out of it. Also, trying to run a game on qemu would be a disaster. Not necessarily, Age of Empires 2 runs quite well under Qemu + Win98SE (on an Athlon 2600+, host: Debian Linux, kernel 2.6.9). However, running normal programs aren't any problem. Except that I have to be very quick when changing resolution in w2k (it should wait 15s, now time flies away and those 15 becomes 2s :)). Before compiling qemu 0.7.0 with kqemu 0.6.2-1, I ran qemu 0.6.something, taken from the debian testing repository, and it had the same problem. Regards, Alexander Toresson PS. I'm susprised nobody has seen this problem before. Is it just me who experience it? Although I use Visual Studio 5 and Age of Empires 2 inside Qemu (with Win98SE and Win2k), I never noticed such problems, and the Windows clock always seemed quite right (and VC++ stresses the CPU quite a lot!). But admittedly I never ran benchmarks or had a closer look at the guest system time. Regards, Oliver Gerlich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Mac OS X at native speed...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Could this: http://apple.slashdot.org/apple/05/06/06/1752234.shtml?tid=118tid=179tid=3 help to run Mac OS X at near-native speed on x86? I'd really like to try OS X myself, but money-wise Qemu will most likely be the only way for me... So maybe this switch to x86 could eliminate any byte ordering slowdowns and make it run as fast as x86-on-x86? Curious about comments from insiders, Oliver Gerlich -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFCpJ5tTFOM6DcNJ6cRAmPqAJ4vpF8B8KETNVd3hPhC6MEpa13DiQCgmM4t uNq6QoDKyFyMiZia3hYdllI= =VOCw -END PGP SIGNATURE- ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
Christian MICHON wrote: 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 Qemu-devel@nongnu.org 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 ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
Re: [Qemu-devel] [PATCH] Embed QEmu screen on a custom window
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 [EMAIL PROTECTED] wrote: Hi, I'm the author of QGui, a windows frontend for QEmu available at http://perso.wanadoo.es/comike. ___ Qemu-devel mailing list Qemu-devel@nongnu.org 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 Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
[Qemu-devel] Re: [Patch] Release mouse at window edges
Ryan Rempel wrote: I've been using your patch for releasing the mouse at window edges (the -autograb path) successfully with a Windows 98 guest. However, I'm now trying to set up a Windows 2000 guest, and the mouse isn't releasing -- things work as they would without the patch. Is this a known issue, or is it working for you with a Windows 2000 guest? This is a known issue. I think the standard Cirrus graphics driver in Win2k doesn't support hardware cursors, so autograb doesn't work out-of-the-box. There's a newer graphics driver for Win2k at http://www.hofnet.com/fire/browse.asp?target=%5CCIRRUS%20LOGIC%5CCL-GD5446%5CDRIVERS%5CWIN2000 This driver supports hardware cursors; but you still have to use non-colored mouse cursors and disable mouse shadow. It then works nicely for me. Btw. you should always be able to release mouse by pressing CTRL+ALT. If this doesn't work with my patch, it's a bug... Oliver Gerlich ___ Qemu-devel mailing list Qemu-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/qemu-devel
