Re: [Qemu-devel] Qemu Guest Tools

[Oliver Gerlich <olig9@gmx.de>]

Jim C. Brown wrote:
> On Wed, Mar 02, 2005 at 12:07:44AM +0100, olig9@gmx.de wrote:
> 
>>Hello,
>>to enable copying of text between Qemu host and guest, I've started to write
>>some small apps called QGT (Qemu Guest Tools). A very early version is
>>available at http://www.oliver-gerlich.de/qemu/ . Please have a look at it
>>and tell me your opinion.
>>
>>Oliver Gerlich
>>
>>-- 
>>DSL Komplett von GMX +++ Superg?nstig und stressfrei einsteigen!
>>AKTION "Kein Einrichtungspreis" nutzen: http://www.gmx.net/de/go/dsl
>>
> 
> 
> This is promising, but I think it is badly named. This looks likes that it could,
> in theory, work across actual networks. There is another program which can be
> used to share clipboards across networks, and it can be used from within qemu.
> It can support multple workstations at once and it supports more OSes.
> 
> Looks good for a first version though. What other features are you planning
> to add?

Planned features are:
-Notification of guest when it is loaded with loadvm
-Time synchronisation between host and guest (currently guest time is 
wrong when loadvm is used)
-drag and drop (Mark mentioned it, and it was also posted on the forum 
some days ago)
-make mouse grabbing more comfortable

Copy/paste and time sync could be done by external programs (Joshua 
mentioned mpcb; ntp, ...). But drag and drop requires access to the Qemu 
window, and loadvm notification requires some kind of integration with 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).

> 
> The project shouldn't be called Qemu Guest Tools unless it requires qemu, IMHO.
> (Guest tools have been discussed before, some ideas for communication to qemu
> itself would be via 'special' qemu specific instructions or alloting an io port
> to give commands to qemu (this is what VMware does). Some ideas that have been
> proposed to use this communication for: host-guest clipboard, accelerated
> graphics support (such as 3d), a sort of two-way user-net (allow the host and
> other workstations to see the guest w/o going thru tuntap ... not sure how
> this would work). The list can get quite fancy.)
> 

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

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.

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


Thanks for your input,
Oliver Gerlich