Re: [Qemu-devel] Re: Spice project is now open

[Anthony Liguori]

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