[Spice-devel] XSpice status report / todo list

[Frediano Ziglio]

On 28/07/15 17:50, Jeremy White wrote:
> Frediano Ziglio indicated he was hoping to do some work on XSpice, and
> asked me to share my todo list or thoughts on ways it could improve.
>
> Made me feel like a kid in a candy store <grin>.
>
> We had an irc chat; I thought I'd restate some of the items and share
> them for posterity.
>
> A brief history:  XSpice includes spiceqxl_drv.so; an Xorg driver, and
> XSpice, a script that helps launch X as a virtual frame buffer server
> that speaks Spice.
>
> It shares code and DNA with the qxl_drv.so used inside a qemu vm/Xorg
> system to provide better Spice integration.
>
> It was created by Alon Levy initially.  I and a few others have spent
> time improving it so that it has near feature parity with qemu (e.g.
> audio, smartcard, agent support, etc).
>
> It uses the same interface with the spice server that the qxl_drv uses,
> which is less than ideal.  That is, it pretends to have a VGA rom and an
> mmapped region of memory, and pushes instructions in through a ring
> buffer.  Frediano rightly deduced that improving that interface would be
> a good starting point for refactoring/improving it.

To sum up the spice usage is something like

qxl <-> qemu <-> spice-server <-> client

while Xspice driver (spiceqxl) is something like

spiceqxl <-> spice-server <-> client

so basically qxl+qemu == spiceqxl however the implementation is too much 
coupled with Qemu. For instance there is an I/O layer emulation (which 
I'm removing right now!), ram/rom emulation, the rings are not optimized 
for thread communications and still using copy to/from some shared 
memory and memory are still managed by a separate pool (malloc/free 
could be used instead).

> It is still somewhat awkward to use; the XSpice script makes it easier,
> but it would be really nice to have a bit of glue to connect it to gdm
> via xdmcp, and even more glue to make the spice-html5 client connect
> automatically.  For a while, gdm was broken wrt xdmcp; I believe those
> bugs are now all fixed, so I hope to return to look at that and make a
> more polished experience in Fedora rawhide.
>
> A nice feature to add, which I hope to get to someday, is to implement a
> parallel to x11vnc.  That should enable session shadowing, or access to
> your own desktop.
>
> One of the features it has that I think is compelling, which I keep
> meaning to make a stronger case for, is the 'Deferred Frames Per Second'
> mode, or essentially, a render and send approach.  We render into our
> frame buffer, and then periodically (at the configured fps) we send the
> changed regions over the wire.  This is the approach used by vnc.
>
> I realize this is heresy, but I did a fair amount of bandwidth and cpu
> usage analysis, and with typical Linux desktop usages, the dfps mode was
> dramatically better.  Further, in some cases (*cough* fluxbox *cough*),
> 'regular' Spice is virtually unusable; the dfps approach was the only
> choice.  I have to work much harder to find a use case where dfps is
> worse than the 'regular' protocol.  I had an experimental patch that
> enabled dfps for qemu/qxl, but it was buggy, and I never found the time
> to fix it up and try to make the argument.
>
> But with dfps on, I'm able to get slightly better bandwidth usage than
> vnc, and my (arguably biased) sense is that the user experience is
> better as well, at least for typical Linux desktop work loads.
>
> </heresy>
Well, spice has some bad corner cases. Actually it lack a continuous 
bandwidth analysis and there are some implementation of the protocol 
that make latency affect badly on some conditions.
Just an example of extreme case think about if interface was designed 
pixel by pixel it could happen that each pixel is transformed into a 1x1 
image drawing (there is no "PutPixel" call on the protocol).
spice should try better to balance CPU usage and bandwidth also 
considering that a lot of small drawing tend to cost quite lot of CPU too.
Well... this adaptive protocol would solve lot of problems possibly 
making a full DFPS useless.
> Another todo is profiling; XSpice cpu usage, particularly for the spice
> server, is substantially higher than that of vnc.  I'm hoping that as we
> refactor some of the red_*, it may be possible to carve out simpler code
> paths for XSpice (or at least to profile and understand the pain).
Do you have some profiling data?
> Just trying to be rigorous:  the Xorg driver bits were really done as a
> proof of concept.  I've tried to clean them up, but some rigorous
> thought around making them 'correct' would be helpful.  Notably, it
> would be nice to eliminate the whole set of errors generated at Xorg
> start time about the keyboard and mouse (although that work may be in
> Xorg, not XSpice).
>
> And, of course, we share the pain around 3D desktop effects that the
> qxl_drv has.  Hopefully the solution imagined for that will work for us
> as well.
>
> In a similar vein, there is a proliferation of xorg.conf options; it
> would be nice to reduce or eliminate those.
Eliminating the memory allocation emulation would probably remove some 
of them.
> Finally, I haven't done any thinking about fun things like Wayland.
> That could be a useful task as well.
Never worked with Wayland. But probably 3D would be even more fun. But 
looks like a much bigger project. For now let's focus on making Xspice 
driver into a better shape!
> Cheers,
>
> Jeremy
Frediano