On Mon, Feb 01, 2021 at 06:28:38PM +0100, Christophe de Dinechin wrote: > > > > On 1 Feb 2021, at 17:56, Daniel P. Berrangé <berra...@redhat.com> wrote: > > > > On Mon, Feb 01, 2021 at 05:31:52PM +0100, Christophe de Dinechin wrote: > >> > >> > >> > >> But the VNC clipboard protocol is not scancode based. So where > >> would the clipboard->scancode conversion happen? > > > > If using keyboard injection there's not really much point in > > using the VNC clipboard protocol at all. It just complicates > > life since now we have to configure QEMU with a keymap so that > > it can turn text back into scancodes. We went through alot of > > effort precisely to *stop* telling QEMU about keymaps, so that > > is not an viable option. > > How do you get rid of keymaps for local input in qemu?
Don't look at the RFC spec for the RFB protocol. Instead look at the community spec which defines all the extensions that clients and servers have implemented. In this case, QEMU defined an extension for scancodes: https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#qemu-extended-key-event-message this is since implemented by alot of VNC clients and severs. > > IOW, if we want to use keyboard injection to fake the clipboard > > then the VNC Clients should just implemnet this natively and > > use the VNC keyboard protocol messages instead, so scancode > > conversion is client side. It is still painful, because text > > to scancode is inherantly a lossy conversion, but it is better > > than doing it on the QEMU code. > > How many brands of VNC clients are there? > > What happens if qemu receives clipboard messages from an old client? > > Do you plan some new VNC capability to tell the client "I want scancodes"? The ability to send keyboard events as scancodes has already existed since 2008 :-) > What would prevent a client from sending dangerous scancodes, > like Control C or Alt TAB? Nothing, but then this is largely a case of a user shooting themselves in the foot, not a security issue. > How would you prevent the user from typing something in the middle? You can't. > How do you rate-limit intelligently to avoid overflowing the guest keyboard > buffers? Like I said earlier in this thread, this is a big problem with keyboard injection. IMHO keyboard injection is only barely better than no clipboard at all, and I don't think we should settle for that as a solution. My preferred solution is to have QEMU leverage the existing SPICE guest agent if at all possible, because that's already widely available in existing guest OS. > >> Also, any idea how to copy from the guest in that case? > > > > If using keyboard injection the clipboard will be unidirectional > > only. > > > > Bi-directional clipboard needs a guest agent. > > OK. > > What is the use case for single-directional text-only clipboard? It is better no clipboard at all.... but only just. > > That's not really isolating it from VNC - that's describing a guest > > agent the host QEMU can use to support its built-in VNC server. > > Confusingly this suggested guest agent happens to use a subset of > > the VNC protocol for transferring clipboard data between QEMU and > > the guest OS. This part is rather crazy since the VNC clipboard > > protocol is incredibly simplistic. Any new guest agent should > > learn from the mistakes of VNC and SPICE wrt clipboard. > > Well, to me, the trick is that you got a VNC server in qemu that > receives VNC clipboard data. The question is how you transfer > that to the guest. Indeed, the protocol is simplistic, but you still > need a new data path, e.g. a character device that your in-guest > agent listens to, a bit like the SPICE agent. So the picture becomes: > > Normal VNC > Client --> (guest network) --> In-guest VNC server > > QEMU VNC: > Client --> (host network) --> qemu-VNC server --> char device --> in-guest > VNC clipboard server > > Only the data path changes, but the protocol can remain > essentially the same. We should not be relying on the guest OS using VNC at all. On Windows it is much more common to use RDP and GNOME looks to be going the same way for Linux. We none the less want to be able to still use VNC from the host side. We need something to be running in the guest, and that should be agnostic of whatever other software the guest chooses to use for remote desktop, and should not assume the guest even has remote desktop setup. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
