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 _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel