Bug 29210 - X Server as SPICE Protocol Server
Summary: X Server as SPICE Protocol Server
Status: RESOLVED FIXED
Alias: None
Product: Spice
Classification: Unclassified
Component: server (show other bugs)
Version: unspecified
Hardware: All All
: medium enhancement
Assignee: Spice Bug List
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-21 23:52 UTC by john.francis
Modified: 2014-11-03 01:53 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description john.francis 2010-07-21 23:52:57 UTC
Desktop virtualisation through machine virtualisation is a great idea, especially for desktop operating systems that do not easily lend themselves to a multi-user desktop scenario.

Linux and Unix lend themselves very well to supporting multiple concurrent desktop users on a single operating system instance. Oracle know this and have taken advantage of this with their Sun Ray Server software. In a nutshell, they have their own X server, Xnewt, that talks to the Sun Ray thin clients using their proprietary Appliance Link Protocol.

You will also note that there exists an X server, Xvnc, that talks to VNC clients.

It would be great to have an X server that can speak native SPICE. Does anyone else think so?
Comment 1 Alexander Larsson 2010-07-22 05:12:27 UTC
Spice is more than what X does though, it has audio, agent support, usb, etc.
Comment 2 john.francis 2010-07-22 22:28:16 UTC
You're absolutely right Alexander. This is the beauty of it.

The way Sun Ray delivers a complete Linux or Solaris desktop virtualisation is by using a custom X server as the basis, and also including components to support audio and USB. The result is seamless as far as audio goes. USB is a bit more kludgy. However, a fantastic desktop experience for the majority of cases only requires good, responsive video, and audio.

So to address audio, one would need to provide a kernel module that can offer pseudo audio devices that belong to individual user sessions. I say pseudo devices because the all the kernel mode driver does is shuffle data to and from a user mode SPICE-speaking audio service. Most Linux software knows how to use an arbitrary audio device, usually by honouring the $AUDIODEV environment variable.

So in essence, for each user session on a single Linux instance you would need one X server (maybe called Xspice), a couple of device nodes for audio (e.g. /tmp/spiceaudio/dev/dsp-1, /tmp/spiceaudio/dev/mixer-1), and a user mode service for handling audio one per user.

If you're only interested in delivering desktop Linux sessions, then you can achieve greater desktops per server with fewer layers of indirection. Also, admins already know how to easily administer a server like this.

I'm giving some serious thought to freeing up some time and working on this concept. What are your thoughts?
Comment 3 Alon Levy 2011-02-28 07:03:41 UTC
> I'm giving some serious thought to freeing up some time and working on this
> concept. What are your thoughts?

I'd be happy if you take a look at http://www.spice-space.org/page/Features/XSpice and the code at http://cgit.freedesktop.org/~alon/xspice.

It's currently implemented as a fork of the xf86-video-qxl driver, planned to be reincorporated somehow (probably just use the same repository, and have a configure flag, will see what soren prefers).

Feature wise it has a mouse and keyboard that appear as "xspice" from xinput list pov, somewhat buggy (try shift-pageup, and also run xev and notice an extra event on clicks that needs fixing). video wise it's basically identical to what xf86-video-qxl does already. It's missing configuration bits, so right now it opens a port at 5912, no ssl. But it's basically working - I did manage to make it crash a few times on oom once and on lack of drawables another time. Debugging it will really take you through the whole thing - since it's basically a mashup of the driver+device+spice server (really the device does about nothing now, but the ring buffers for coordination between driver and spice server are still used).

Alon


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.