On Wed, 2013-07-31 at 17:53 +0200, Hans de Goede wrote: > 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 :) The reason for not using uinput directly was to avoid having the agent have the permissions required to do that. But as you suggested in real life I can just skip agent mouse and use usb tablet for the client mouse goodness. > > Regards, > > Hans _______________________________________________ Spice-devel mailing list Spice-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/spice-devel