On Mon, 1 Feb 2021, Daniel P. Berrangé wrote:
IMHO keyboard injection is only barely better than no clipboard
at all, and I don't think we should settle for that as a solution.
From this discussion it looks like doing keyboard injection is not a good
solution as it has more problems than what it can solve so we can conclude
to drop that idea which then means there needs to be some kind of guest
agent.
My preferred solution is to have QEMU leverage the existing SPICE
guest agent if at all possible, because that's already widely
available in existing guest OS.
I think spice is not as widely available as VNC (or even Synergy) so the
idea to strip one of those down to just a guest clipboard agent would help
to get support to the most guests. QEMU already knows about VNC so might
be the simplest way and you could reuse all kinds of VNC client and server
code for the guest agent and also make it easy for others to add support
for their guests. Using spice may not be that easi as it's less widespread
so probably only works on the guests that already have support for it. And
then why not just use spice instead of VNC on those guests and then you
don't have the clipboard problem either.
What is the use case for single-directional text-only clipboard?
It is better no clipboard at all.... but only just.
I think the use case Gerd mentioned as a first target: paste a link to the
guest browser to download your data. But that's very limited and not that
much useful so I agree more complete support should be targeted than that.
Well, to me, the trick is that you got a VNC server in qemu that
receives VNC clipboard data. The question is how you transfer
that to the guest. Indeed, the protocol is simplistic, but you still
need a new data path, e.g. a character device that your in-guest
agent listens to, a bit like the SPICE agent. So the picture becomes:
Normal VNC
Client --> (guest network) --> In-guest VNC server
QEMU VNC:
Client --> (host network) --> qemu-VNC server --> char device --> in-guest VNC
clipboard server
Only the data path changes, but the protocol can remain
essentially the same.
We should not be relying on the guest OS using VNC at all. On Windows
it is much more common to use RDP and GNOME looks to be going the same
way for Linux. We none the less want to be able to still use VNC from
the host side.
We need something to be running in the guest, and that should be
agnostic of whatever other software the guest chooses to use for
remote desktop, and should not assume the guest even has remote
desktop setup.
As I understood, the idea is not to run a full VNC server on the guest OS
but to make it easy to write the guest agent that you'll need to run is to
reuse parts of a VNC server which is already available on almost all
platforms. So basing the guest agent protocol on that allows you to not
needing to write a guest agent but just extract the code from an already
available VNC server that hopefully already solves the guest OS
integration problems which is the most problematic part. At least where
open source versions are available but for most platforms there's probably
a few. This just avoids writing a guest agent for all kinds of guests from
scratch or pulling in too much unneeded dependencies just to make
clipboard work (as a full spice guest agent may be overkill for this).
Regards,
BALATON Zoltan
