An X server and a Spice server. Yes, the idea that X is not a good enough networking protocol for WAN has been investigated already many times. Why yet another one? In the end because it seemed like a cool thing to do. And it’s easier to test the qxl driver without the guest/host split.
What I think would be really useful is to be able to use it side by side with an existing X server, i.e. having two drivers both receiving all X operations (vnc doesn’t have this problem because it isn’t implemented as a driver). Sadly this is not yet doable. But happily it is being worked on, mainly due to the relatively-new dual GPU laptops (I don’t know the ETA. I think it’s called sharding, or at least is related to that).
So right now, if you are tired of Xvnc, or Xrdp, or NX, or just want to compare and tell us again that we need to improve SPICE (*) (**)
Building requires the same dependencies as any X video driver, plus spice-server. See README.xspice for details.
XSpice installation as a normal user is a bit of a hassle, since it requires one to build their own X server. If you want to do it, see README.xspice for details. On the other hand, installing as root requires just three things:
* spiceqxl_drv.so -> with all other xorg video drivers.
* xspice -> /usr/bin
* spiceqxl.xorg.conf.example -> /etc/X11/spiceqxl.xorg.conf (this is the default config file xspice looks for, you can change that with –config)
sudo make install will do the first two for you (assuming you did ./configure –prefix=/usr). The third you’ll have to do by hand.
To summarize, this should get you going:
sudo make install
sudo cp examples/spiceqxl.xorg.conf.example /etc/X11/spiceqxl.xorg.conf
Alternatively, somewhere in the near future I hope this will be enough
yum install xspice
Running is easier:
xspice --disable-ticketing --port 5900 --tls-port 0 :1.0 2>&1 > /dev/null &
spicy -h localhost -p 5900
DISPLAY=:1.0 favorite-window-manager-that-doesnt-need-dbus # i.e. icewm
Note: you don’t have to redirect, there is just a lot of spew, so you might want to run spicec/spicy in another terminal.
Note 2: that –tls-port 0 is weird, right? bug. But I already used one paper bag (0.0.15 never saw daylight), so I’ll just leave this for the next release.
Most of the options familiar from qemu’s -spice option are there, with some exceptions: no sound yet (do a pulseaudio proxy? not sure), no agent implementation (probably a good idea to reuse spice-vdagent for this), and no per channel secure/unsecure port selection (just laziness). The internal mechanism for passing those options is a bit of a hack – XSPICE_* environment variables are set by xspice and read by spiceqxl_drv.so.
I hope someone finds this useful, if you do, do let me know!
*) we know! but thanks for telling us! no, really! 🙂
**) Compared to VNC I don’t think there is a question that Spice is a better (***) protocol. Compared to the rest, it has it’s shortcomings. But it will be 😉
***) ok, I can’t write “better” without saying that it is a function of the optimization criteria. But you know what I mean.
p.s. also, we already had spice-x, so xspice was inevitable. Next, ispice!