Re: [Qemu-devel] Qemu Guest Tools

[Jim C. Brown]

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
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/qemu-devel
> 

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