[Spice-devel] XSpice status report / todo list

[Jeremy White]

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.

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>

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

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.

Finally, I haven't done any thinking about fun things like Wayland.
That could be a useful task as well.

Cheers,

Jeremy