[Spice-devel] Spice agent for XSpice

[Hans de Goede]

Hi,

On 07/31/2013 05:43 PM, Alon Levy wrote:
>> 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.?
>
> Hi,
>
>   I've finally sat down to do this. It turns out in practice that incorporating udscs is not such a good idea:
> 1. udscs code is GPL, driver is BSD (solvable, but see the rest)
> 2. you get a lot of duplication with vdagentd - parsing chunks and messages, basically reading all messages, passing through some, some with changes (clipboard). (~700 lines just for monitors config + mouse + untested xfer, lacking clipboard)
>
>   I have a working implementation but Uri suggested a simpler idea and I wanted your opinion:
> 1. use a named pipe provided by Xspice to vdagentd instead of virtio serial com.redhat.spice.0
> 2. use a named pipe / unix domain socket to implement a pseudo uinput device. pseudo since I can't implement any of the ioctls, so this will require a small change to vdagentd-uinput.c and a command line argument.
>
> Overall the changes to vdagentd/vdagent will be small:
> 1. vdagent option to pick a different path to udscs UDS.
> 2. same for vdagentd
> 3. vdagentd pseudio-uinput support (same packets, no ioctls - presumed device layout, i.e. 2 axis 5 buttons 2 of which are a wheel).
>
> Any comments?

Sounds like a good idea to me. Note you don't need pseudo uinput support you can just make Xspice use the uinput device created by the
agent using the xorg-x11-drv-evdev driver :)

Regards,

Hans