[Spice-devel] Spice agent for XSpice
Hans de Goede
hdegoede at redhat.com
Fri Mar 9 01:46:50 PST 2012
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.
Regards,
Hans
More information about the Spice-devel
mailing list