[Spice-devel] Thoughts / questions on Xspice

Christophe Fergeau cfergeau at redhat.com
Wed Jan 6 08:04:36 PST 2016


Hey,

On Fri, Dec 18, 2015 at 10:21:58AM -0600, Jeremy White wrote:
> 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.

My guess would be that as an initial experiment, reusing the X driver
was faster/seemed easier, so it stayed this way.

Christophe
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/spice-devel/attachments/20160106/f0bf7938/attachment.sig>


More information about the Spice-devel mailing list