[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