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 _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
