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