Re: vnc clipboard support

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

[-- Attachment #1: Type: text/plain, Size: 6406 bytes --]



> On 29 Jan 2021, at 15:32, Daniel P. Berrangé <berrange@redhat.com> wrote:
> 
> On Fri, Jan 29, 2021 at 03:19:45PM +0100, Christophe de Dinechin wrote:
>> 
>> 
>>> On 29 Jan 2021, at 12:08, Daniel P. Berrangé <berrange@redhat.com> wrote:
>>> 
>>> On Fri, Jan 29, 2021 at 11:50:10AM +0100, Christophe de Dinechin wrote:
>>>> 
>>>> 
>>>>> 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.
>>> 
>>> IMHO that's an awful lot of complexity to add to the system
>>> that isn't especially useful and this opens up new attack
>>> vectors for the guest to exploit the host.
>>> 
>>> If people have VNC/RDP/whatever configured inside their guest
>>> OS, then there's really little to no reason for them to want
>>> to connect to the QEMU VNC server, as viewing initial bootup
>>> phase is not required in normal case. The only time such
>>> people will need to use the QEMU VNC server is if the guest
>>> OS has broken in some way before it fully booted and thus failed
>>> to start the guest VNC server. There is no guest VNC server
>>> to hand off to in this scenario.
>> 
>> It's a matter of what you want to do with that qemu vnc.
>> 
>> If it's only a backup when there's nothing in the guest to help,
>> then maybe trying to support copy-paste is not a good idea.
>> 
>> If it's a standard go-to access point for connecting to your
>> guest, then making it smart is hard, but useful.
>> 
>>> 
>>> The value of the QEMU host side VNC server is that it works
>>> for all possible guest OS, no matter whether they are running
>>> normally or broken, regardless of what the guest admin has
>>> configured in terms of guest level remote desktop.
>> 
>> Understood.
>> 
>> The downside is that there are things it can't do. It cannot correctly
>> determine the keyboard map, because that's controlled in software
>> in the guest.
> 
> There is no need for the remote desktop server to care about the
> keymap. The remote client takes scancodes and passes them to the
> server, which then passes them to the guest.

Aren't we talking about pasting clipboard data here?
I assume that clipboard data is not encoded as scancodes.


> 
> The person connected to the remote server simply has to configure
> their guest OS keymap to match the physical keyboard they currently
> have plugged in.
> 
> The only reason a remote server would need to know the keymap is
> if it was trying to translate from keycodes back into scancodes.
> This is what VNC protocol had to do originally, but VNC was since
> extended to pass raw scancodes instead of keycodes, precisely to
> avoid needing to care about keymaps.
> 
>>> IOW, if you have a guest remote desktop solution you'll just
>>> use that 99% of the time. If you don't have that, then you'll
>>> use QEMU VNC/SPICE server, and there won't be anything in the
>>> guest for that to proxy to/from.
>> 
>> If really the assumption is there is nothing in the guest to help
>> us, then I'd say "paste" should come up with a warning "do you want
>> me to try and translate that into keystrokes", and I don't see how to
>> implement copy from a graphical display without OCR…
> 
> I'm not saying we can't use stuff in the guest, just that we should be
> pragmatic about what we interact with in the guest and degrade nicely.
> I don't think that proxying from a host VNC server to a guest VNC server
> is sensible, but making use of a guest agent of some kind is not
> unreasonable, especially if we can use one that already exists.
> 
> 
> Regards,
> Daniel
> -- 
> |: https://berrange.com <https://berrange.com/>      -o-    https://www.flickr.com/photos/dberrange <https://www.flickr.com/photos/dberrange> :|
> |: https://libvirt.org <https://libvirt.org/>         -o-            https://fstop138.berrange.com <https://fstop138.berrange.com/> :|
> |: https://entangle-photo.org <https://entangle-photo.org/>    -o-    https://www.instagram.com/dberrange <https://www.instagram.com/dberrange> :|


[-- Attachment #2: Type: text/html, Size: 32410 bytes --]