[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Qemu Guest Tools

From: Oliver Gerlich
Subject: Re: [Qemu-devel] Qemu Guest Tools
Date: Wed, 02 Mar 2005 13:44:35 +0100

Jim C. Brown wrote:
On Wed, Mar 02, 2005 at 12:07:44AM +0100, address@hidden wrote:

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]