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