> On 29 Jan 2021, at 12:49, Gerd Hoffmann <kra...@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
>
