I also had recently some thoughts about how to implement clipboard sharing
in a more general way for QEMU.
I admit I like Christophe's suggestion ("it's somebody else problem"), but
it falls short to me as I don't know of a common open-source remoting
solution for various operating systems, and I don't see how it could
integrate well with our UI and remote protocols. Or look at reusing some
VirtualBox code perhaps?
Some things I keep in mind:
- the spice protocol had a number of iterations to fix some races. It would
be great not to repeat the same mistakes, and I don't know if VNC have the
same flaws or not.
- the spice agent design isn't great: the system agent proxies messages to
the active session. It would be nice if the new solution didn't have such a
middle-man.
- with wayland, clipboard sharing isn't really possible. Or not in a
seamless way at least. Today it kinda works with some X11 compatibility
extensions, but this will eventually go away or change behaviour.
- the GNOME desktop is working on remoting using RDP, and they are
implementing a DBus interface for it (
https://gitlab.gnome.org/jadahl/mutter/-/commits/wip/remote-desktop-clipboard
)
- it's not just about clipboard. We would also want to have some kind of
drag and drop (even if limited to files like Spice atm). We may want some
windowing integration. We may also want to have access to some desktop
services: apps, documents etc.. And what's not.
That leads me to think that virtio-serial is not very well suited, as it
doesn't allow various services / processes to come and go. I see vsock as a
much better alternative. (I also wonder if it handles control flow any
better btw)
I think we shoud work on getting the free desktops our best-class support.
To me, this means we need to speak the lingua franca, which is DBus. The
great thing is that DBus is also equipped to handle services that come and
go, handling discovery, introspection etc. Various services are already
available. As mentioned earlier, that's what the GNOME desktop will offer
for clipboard sharing. There are good chances other desktops will follow if
that design works, as it should be easy for them to implement the same
service. That means good reuse of existing desktop code. Speaking DBus on
Windows, MacOS or Android isn't an issue. However, vsock support may be a
bit tricky atm.
Fwiw, DBus doesn't yet officially support vsock connections:
https://gitlab.freedesktop.org/dbus/dbus/-/merge_requests/200. This a minor
detail, as once you give it a fd for transport, it doesn't really care (I
also took care of glib!1892 and Rust zbus)
Oh and of course, since this is a new daemon, it would be really a shame
not to write it in a modern language (hint! ;-).
Hope that helps,