[Spice-devel] Spice agent for XSpice

[Hans de Goede]

Hi,

On 03/09/2012 11:57 AM, Alon Levy wrote:
> 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?)

I don't think there is much in there to split into a library. The only
re-usable part is udscs.c / udscs.h which stands for unix domain socket
client server. Which does the low-level uds handling. Everything else
is not really suitable for re-use (ie assumes a virtio serial port,
rather then spice-servers chardev interface).

I think the only thing which you should copy 1 on 1 is vdagentd-proto*.h
which defines the protocol over the unix domainsocket.h and maybe udscs.?

Regards,

Hans