I've spent some time this past week relearning some of the details of the way Xspice interacts with the Spice server; I thought I'd share my questions and thoughts, and potential plans for the future. First, I have a big, naive, question: http://lists.x.org/archives/xorg-devel/2012-August/033174.html Essentially, why UXA, and is there a 'modern' equivalent? I ask that question because part of me thinks that Xspice should be completely separate from the qxl driver. There isn't that much common code, and uxa is a big part of the common code. Additionally, I wonder if there is a benefit to using a 'modern' xorg frame buffer driver construct for Xspice. In fact, if a modern fb driver had performance equal to qxl, you could potentially write an x11vnc style replacement for xspice and do away with the xspice/xorg driver altogether. Of course, rewriting code from scratch as the primary answer to complaints is the refuge of the young and foolish. At least I'm not young anymore <grin>. Setting that aside, my mental 'yuck' list for Xspice is: 1. Semantics Xspice is awkwardly shoe horned into the qxl driver. So, for example, the function that wakes up a red_worker thread is 'ioport_write', but there is absolutely no ioport involved. As another example, qxl_screen_init() calls qxl_save_state(). For Xspice, that's just a noop. To me, it would be more correct to have a xspice_screen_init that does not call qxl_save_state at all. And, I think, the naming convention (spiceqxl_xxxx === xspice, qxl_xxx is mostly qxl, but sometimes shared) is confusing :-(. I've never felt that the benefit of refactoring this code ever justified the potential for instability. And, again, I still have the question lingering in my mind as to whether we should scrap the approach altogether. 2. RAM inefficiency Xspice uses the semantics of a vga driver; allocating large fixed blocks of ram to hold ring buffers, which are used to push commands across. Since Xspice is in the same process as the spice server, this is unnecessary. Simplifying this would likely lead to some modest cpu utilization gains. It should also make it completely unnecessary to preallocate large buffers. That would save some configuration hassles, and should make a server hosting multiple Xspice sessions do so more efficiently. 3. Incomplete Xspice utility The Xspice utility does not completely present all of the options available, and isn't quite as user friendly as we might like. It could also do a better job of helping with audio transmission and a few other areas. I'd really like to get to the point where the latest Fedora spin can have nice Xspice/xdmcp behavior. Ideally, someone should be able to do: yum install xspice spice-html5 httpd /usr/bin/imagined-xspice-turn-on-web-server-script and then hitting https://server/ gets you a log on screen, and you can log in and get audio and all the spice goodies. I plan to work on #2 and #3 as time allows. I may toy with an x11vnc style solution at some point as well. Cheers, Jeremy _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel