Gerd Hoffmann wrote:
On 12/12/09 23:35, Dor Laor wrote:
2. VDI (Virtual Desktop Interface)
http://www.spice-space.org/vdi.html
It's an abstraction layer for graphics/keyboard/mouse/sound
/usb/serial.
We need it anyway regardless of spice. What is our user like to
switch from vnc to SDL on runtime? It's good for usb-over-ip for
remoting, for various mouse modes, etc.
What does spice need which isn't present in qemu today?
You can start qemu with both sdl and vnc enabled. Graphic output is
sent to both. Keyboard and mouse input is accepted from both. Sound
via vnc works too.
What doesn't work: usb + chardevs (i.e. serial console), so we need
some interface here. For graphics spice probably needs a different
interface than the existing for a stupid framebuffer with copyrect
op. I don't see a need for new keyboard/mouse/sound interfaces though.
(Looking at spice-space.org), VDI seems to be a whole lot more than just
a graphics thing. It looks a plugin interface for qemu as it
incorporates things like fd registration, timer registration, etc.
I don't think it's really needed verses just integrating spice support
directly. I don't quite understand the relationship between spice and
vdi though. If libspice implements a VDI interface directly and that's
what it expects people to write against verses vdi existing solely for
interaction with qemu. If the later is the case, then it's probably an
unnecessary abstraction. If the former is the case, then it's just the
api we have to live with.
Of course, you could use something like VDI to separate out the vnc
server into a more well defined module. However, I'd suggest separating
that modularity effort from the integration of spice. Either do that
starting with the vnc server, then add spice, or add spice with tight
integration, and then build a common interface.
The later is probably better since it gives you more clear requirements
for the interface.
Regards,
Anthony Liguori
