Re: vnc clipboard support

[Christophe de Dinechin]

> On 29 Jan 2021, at 09:03, Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
>  Hi,
> 
>>> (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.
> 
> Well, if you run Xvnc in the guest anyway why use the qemu vnc server
> in the first place?

I assume that if you use the qemu VNC, it's because you you don't want to
run Xvnc on some external network, or care about accessing the guest
before Xvnc can be launched. There can be many reasons.

Again, I want to make it clear that my suggestion is _not_ simply to access
the existing Xvnc as is, but rather to stick with some VNC server code to handle
the clipboard if / when possible.

Let me try to imagine a scenario, where I'll use a macOS guest intentionally
to clarify what I was thinking about.

- During early boot, there is no in-guest VNC server, so to address that,
you connect to the qemu VNC. At this stage, all screen refresh is handled
by the qemu VNC, and the best you can do if you want to support any
kind of copy-paste is to convert it to virtual keystrokes. The same would
be true for Linux on a text console.

- Then comes up you macOS guest, and it still has no VNC port open,
so you are stuck with qemu-vnc doing all the work. But now you can
enable screen sharing, and that launches the Apple-maintained macOS
VNC server.

- Let's assume for illustration that this listens on some private network
that qemu can access, but that is not visible externally. In this case,
you could not VNC to the guest, but you can still VNC to qemu.

- What I'm suggesting is that qemu-vnc could then switch to simply
relaying VNC traffic to that in-guest server. You'd get the smart update
algorithm that Apple has put in place to deal with transparency and the
like, as well as a level of guest OS integration that would otherwise be
much harder to replicate.

I believe that the same holds true with X as well. If you can activate or
detect an Xvnc, you are much better off using _that_ to deal with the
idiosyncrasies of Xclipboard rather than try to convert keycodes.

If you don't have it, you fallback to virtual keystrokes, which you can't
dispense with because of the early boot case, but which will at best
deal with simple ASCII (making that work with a clipboard containing
tabs and Control-C/Control-V characters is left as an exercise for the
reader  ;-)

Finally, an optimization I alluded to is to have an agent which is basically
a stripped-down VNC server dealing with only the clipboard aspect, and
that is your agent. In other words, you don't' invent yet another protocol,
but you furiously copy-paste the existing VNC code.


Hope this sounds a bit less crazy explained that way…
Thanks
Christophe