From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D6VGl-0004Iw-9q for qemu-devel@nongnu.org; Wed, 02 Mar 2005 09:56:12 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D6VGZ-0004Ay-5R for qemu-devel@nongnu.org; Wed, 02 Mar 2005 09:56:02 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D6VGY-000494-R8 for qemu-devel@nongnu.org; Wed, 02 Mar 2005 09:55:58 -0500 Received: from [128.8.10.162] (helo=po0.wam.umd.edu) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D6V05-0007Ko-Qt for qemu-devel@nongnu.org; Wed, 02 Mar 2005 09:38:57 -0500 Received: from jbrown.mylinuxbox.org (jma-box.student.umd.edu [129.2.237.180]) by po0.wam.umd.edu (8.12.10/8.12.10) with ESMTP id j22EcuJq011072 for ; Wed, 2 Mar 2005 09:38:57 -0500 (EST) Date: Wed, 2 Mar 2005 09:38:56 -0500 From: "Jim C. Brown" Subject: Re: [Qemu-devel] Qemu Guest Tools Message-ID: <20050302143856.GA4688@jbrown.mylinuxbox.org> References: <4912.1109718464@www32.gmx.net> <20050302013220.GA28323@jbrown.mylinuxbox.org> <4225B533.2030801@gmx.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4225B533.2030801@gmx.de> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Wed, Mar 02, 2005 at 01:44:35PM +0100, Oliver Gerlich wrote: > Planned features are: > -Notification of guest when it is loaded with loadvm Why? > -Time synchronisation between host and guest (currently guest time is > wrong when loadvm is used) Technically this is a qemu bug and should be fixed in qemu. Of course, any way to set the time in qemu guest w/o having to patch qemu source is welcome. > -drag and drop (Mark mentioned it, and it was also posted on the forum > some days ago) > -make mouse grabbing more comfortable I am against mouse grabbing myself. I just use the no-sdl-grab patch and deal with a desyncing guest mouse pointer (sometimes I can work around it by turning mouse acceleration off in the guest). > > Copy/paste and time sync could be done by external programs (Joshua > mentioned mpcb; ntp, ...). I'm not sure if ntp would work for qemu guest. The way qemu works, guest changes to the RTC are overridden by qemu. Of course if the guest kept its own time independent of the hardware clock, that wouldn't be a problem. > But drag and drop requires access to the Qemu > window, and loadvm notification requires some kind of integration with Qemu. Both of which can not be done reliably through TCP/IP. (What if the guest has no network support? Or you are running Windows 98 in safe mode?) Futhermore, how will the guest tools know that they are really running under qemu? > Currently it's indeed only a bad version of mpcb :) but I hope it will > evolve in another direction (copy and paste being just a small part of > its features). > Agreed. That would benefit everyone. > > I've decided against some special i/o port or such because I don't know > anything about these things :) and because it would require a driver on > the guest side (is that correct?). Unfortuantly, yes. However, the magic instruction set would not. (You would probably need to reimplement a new one for each arch qemu supports/will be ported to though.) > TCP/IP drivers are available for many > platforms, and I think if an OS doesn't support TCP/IP it doesn't really > matter if copy/paste doesn't work. > I disagree here (not about the copy/paste specificly, but for guest tools in general). Drag&drop would have no meaning for an OS that doesn't support a mouse, let alone a GUI, but certain things such as time sync and loadvm notification could be accessed and used universally. > Accelerated graphics would be nice indeed, but shouldn't that be done in > a separate driver? Not sure if such an optional user-space application > is the right place for this. You are probably right about that. I was simply saying that an accelerated graphics driver for a qemu guest would need to talk to qemu directly in the same way the qemu guest tools would (send qemu little messages telling it to open an opengl window and draw this guy here, this other guy there, this gun up there, etc). On the other hand, they probably should not share the same channel, as that would be too slow. > > After all, QGT should just be a collection of those features that cannot > be integrated into a hardware+driver (which is generally a cleaner way). > Agreed. > > Thanks for your input, > Oliver Gerlich > > > > _______________________________________________ > Qemu-devel mailing list > Qemu-devel@nongnu.org > http://lists.nongnu.org/mailman/listinfo/qemu-devel > -- Infinite complexity begets infinite beauty. Infinite precision begets infinite perfection.