Re: vnc clipboard support

[Christophe de Dinechin <cdupontd@redhat.com>]

> On 29 Jan 2021, at 12:49, Gerd Hoffmann <kraxel@redhat.com> wrote:
> 
>  Hi,
> 
>> - 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.
> 
> Ok, so basically add a vnc proxy mode and allow switching between
> internals server and proxy mode (automatically if possible, or
> manually).

Yes.

> 
>> 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  ;-)
> 
> Well, even simple ascii is tricky.  How do you send 'z', as KEY_Z or as
> KEY_Y ?

Exactly. Scancode / keymap conversions are no joke. and qemu has
very little information about the current state of the guest in that respect.

> 
>> 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.
> 
> Third mode: proxy only clipboard messages.
> 
>> Hope this sounds a bit less crazy explained that way…
> 
> Well, I can't see a way to make all that work nicely fully automatic ...

I see many aspects that are difficult, like disconnecting / reconnecting,
dealing with versions of the protocol, capability changes, and so on.

It was quite hard for SPICE to switch between console and streaming
agent, so I can understand why the prospect does not sound appealing.
Maybe that was just a bad idea.

> 
> take care,
>  Gerd
>