[Spice-devel] Spice agent for XSpice

[Alon Levy]

On Fri, Mar 09, 2012 at 10:46:50AM +0100, Hans de Goede wrote:
> Hi Eike, Alon,
> 
> On 03/08/2012 08:33 PM, Eike Hein wrote:
> >
> >Hi,
> >
> >I recently sent a mail to Marc-André Lureau, inquiring about
> >clipboard sharing support in his virt-viewer builds for Win-
> >dows. It turned out that the reason clipboard sharing doesn't
> >work is because Xspice does not yet spawn an agent.
> >
> >Marc-André subsequently got Alon Levy into the discussion,
> >who had this to say on how this might be pulled off:
> >
> >"I'm really glad to hear someone is actually using this. To implement
> >clipboard sharing is indeed just an Xspice issue. You'll need to have an
> >agent talking to spice server not via a virtio device and qemu. Looking
> >at vdagent-linux I guess there are a few questions:
> >* do we run vdagentd and vdagent as subprocesses of Xspice
> >(actually Xorg)
> >* is there a way to emulate uinput (not related to clipboard)
> >* more a statement - I think the clipboard part is relatively easy,
> >you can replace the hardcoded /dev path for the virtio-serial port
> >with a pipe.
> >
> >I guess I would try to split vdagent to a library and app, and then link
> >the library into spiceqxl_drv.so (i.e. xf86-video-qxl)."
> >
> >I'm still pretty keen on getting this to work in my Xspice-
> >based setup, and since I was encouraged to bring this topic
> >to the list here goes. Please chime in :).
> 
> Eike, in case you don't know, I'm the main author of the Linux
> spice-vdagent. I've been thinking a bit about re-using that
> for Xspice (after Alon asked me this a couple of days ago) and
> here is my 2 cents:
> 
> The linux agent consists of 2 parts, a system level daemon and
> a per user (X) session agent process.
> 
> The system level daemon (spice-vdagentd):
> -talks to the agent virtio serial port
> -handles client mouse mode through uinput
> -dispatches other messages to session process for the
>  currently active session (it uses consolekit to find out
>  which is the currently active session, think fast
>  user switching and having multiple X-session open
>  on different VTs)
> 
> The user session process (spice-vdagent):
> -sends the resolution X is currently running at to
>  spice-vdagentd, which needs this info to interpret
>  the mouse events it gets from the client and feeds to
>  the uinput device
> -receives the desired (client native) resolution from the
>  client, and uses Xrandr to switch to this
> -handles copy and paste
> 
> If we want to re-use this all for X-spice, then the choosen
> split actually comes in quite handy, with X-spice we don't
> have a agent virtio serial port, and we don't need to send
> mouse event through a uinput device either. So I suggest that
> for X-spice we simply re-use the user session agent process
> as is (making it connect to the running X-spice server), and
> "throw away" the system level daemon, replacing it with some
> functionality inside X-spice.
> 
> The user session agent process talks to the (to be removed
> in the X-spice scenario) system level agent daemon through
> the following unix domain socket:
> /var/run/spice-vdagentd/spice-vdagent-sock
> 
> So I think that if we modify X-spice to register a chardev
> with spice-server for the agent channel, and create a
> /var/run/spice-vdagentd/spice-vdagent-sock unix socket and
> forward all client agent messages between the 2 we are almost
> done. All that then needs to be done is filter out mouse
> event messages and inject those directly into the X-server.
> 
> Note that the protocol on the unix socket != the protocol
> on the virtio serial port, so you will need to lift some code
> from spice-vdagentd which does the parsing of the one and
> wrapping of the other.
> 
> Later on we should make the path of the unix domain socket
> a cmdline option for both X-spice and spice-vdagent so
> that we can run multiple X-spice sessions on the same machine,
> with each using there own socket.
> 
> Something else to worry about later is sharing the necessary
> code from spice-vdagent with X-spice, for now I simply suggest
> copying over the necessary files.
> 

Sounds like a plan. My only comment was the hardcoded /var/run.. and
multiple servers, but you forsaw that :)

I could start from the end part - spliting the system level daemon to a
library and daemon, and reusing the library for Xspice (is X-spice
really more readable?)

> Regards,
> 
> Hans