Re: vnc clipboard support

[Christophe de Dinechin]

> On 28 Jan 2021, at 18:12, Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
>  Hi folks,
> 
> I'm looking for a good way to implement cut+paste support for vnc.
> 
> The vnc core protocol has support for text/plain cut+paste, and there
> is an extension adding support for other formats.  That'll cover one
> part of the problem, exchanging cut+paste data between vnc client and
> qemu vnc server.
> 
> The tricky part is the second: the guest <=> qemu communication.
> I see basically two possible approaches here:
> 
>  (1) Have some guest agent (spice does it that way).
>      Advantage: more flexible, allows more features.
>      Disadvantage: requires agent in the guest.

What about running the option to relay data to a VNC server in the
guest if there is one running? In other words, using an existing
VNC server as an agent, with the option of having a stripped-down,
clipboard only VNC server as a later optimization.

The benefit I see is that the work of adjusting between the VNC
clipboard protocol and the local OS clipboard is something that is
likely already done when porting VNC, so you leverage that, even
for exotic operating systems. And in many cases, VNC may already
be part of the distro / OS, or at least easy to find.

Then it's a matter of choice whether you want to talk to some
real guest network, or use a character device and route data
through some other non-network path.

> 
>  (2) Send text as key events.
>      Advantage: no guest agent needed.
>      Disadvantage: is translated by guests keyboard map, so qemu
>      needs to know the map for proper char -> key event translation.
>      Only works for text/plain and only for chars you can easily
>      type, anything needing input methods (emoji 😊 for example)
>      isn't going to fly.


> 
> I think that (1) is clearly the better way.  Given that the agent
> would need to run in user wayland/xorg session context the existing
> qemu-guest-agent will not work.  Also linking against some UI library
> like gtk3 for clipboard handling is not something we want for the
> qemu-guest-agent.  So we need another one, I'll name it
> qemu-clipboard-agent for the rest of this mail.  And we need a
> communication channel.
> 
> I'd tend to model the qemu-clipboard-agent simliar to the
> qemu-guest-agent, i.e. have some stream as communication path and run
> some stream protocol over it.
> 
> Stream options I see are (in order of personal preference):
> 
>  (1) New virtio-serial port.  virtio-serial likely is there anyway
>      for the qemu-guest-agent ...
> 
>  (2) Have qemu-clipboard-agent and qemu-guest-agent share the agent
>      channel, i.e. qemu-clipboard-agent will proxy everything through
>      qemu-guest-agent (spice does it that way).
> 
> Protocol options I see are (not sure yet which to prefer, need to have
> a closer look at the candidates):
> 
>  (1) Add clipboard commands to QMP and use these.
> 
>  (2) Reuse the clipboard bits of the vnc protocol (forward
>      VNC_MSG_CLIENT_CUT_TEXT messages to the guest agent)
> 
>  (3) Reuse the clipboard bits of the spice-agent protocol.
> 
>  (4) Reuse the clipboard bits of the wayland protocol.
> 
> Once we have sorted the qemu <-> guest communication path it should be
> possible to also hook up other UIs (specifically gtk) without too much
> effort.  Which probably makes (2) a rather poor choice.
> 
> Comments?
> Suggestions?
> Other ideas?
> 
> take care,
>  Gerd
> 
>