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