qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org
Subject: Re: vnc clipboard support
Date: Thu, 28 Jan 2021 17:35:04 +0000	[thread overview]
Message-ID: <20210128173504.GS3832029@redhat.com> (raw)
In-Reply-To: <20210128171224.exbklnwtyb232oe2@sirius.home.kraxel.org>

On Thu, Jan 28, 2021 at 06:12:24PM +0100, Gerd Hoffmann wrote:
>   Hi folks,
> 
> I'm looking for a good way to implement cut+paste support for vnc.
> 
> The vnc core protocol has support for text/plain cut+paste, and there
> is an extension adding support for other formats.  That'll cover one
> part of the problem, exchanging cut+paste data between vnc client and
> qemu vnc server.

NB the VNC cut+paste impl is technically undefined  for non-7-bit ascii
data. In reality though I'd assume most servers/clients and up sending
UTF8. 

> The tricky part is the second: the guest <=> qemu communication.
> I see basically two possible approaches here:
> 
>   (1) Have some guest agent (spice does it that way).
>       Advantage: more flexible, allows more features.
>       Disadvantage: requires agent in the guest.



>   
>   (2) Send text as key events.
>       Advantage: no guest agent needed.
>       Disadvantage: is translated by guests keyboard map, so qemu
>       needs to know the map for proper char -> key event translation.
>       Only works for text/plain and only for chars you can easily
>       type, anything needing input methods (emoji 😊 for example)
>       isn't going to fly.
> 
> I think that (1) is clearly the better way.

I agree - the agent based approach also lets you have a bi-directional
solution. ie copy in the guest, paste in the host, which you can't
do by simulating key presses.  Simulating keypress is insanely slow
too, so useless for more than 100 bytes of text really.

>                                              Given that the agent
> would need to run in user wayland/xorg session context the existing
> qemu-guest-agent will not work.  Also linking against some UI library
> like gtk3 for clipboard handling is not something we want for the
> qemu-guest-agent.  So we need another one, I'll name it
> qemu-clipboard-agent for the rest of this mail.  And we need a
> communication channel.

I've never looked at the spice-guest-agent code, but I wonder if there
is any scope for re-using it with VNC, or is it too closely tangled
up with SPICE ?  The advantage of reuse is that all existing guest
OS with spice-guest-agent installed will "just work".

> I'd tend to model the qemu-clipboard-agent simliar to the
> qemu-guest-agent, i.e. have some stream as communication path and run
> some stream protocol over it.
> 
> Stream options I see are (in order of personal preference):
> 
>   (1) New virtio-serial port.  virtio-serial likely is there anyway
>       for the qemu-guest-agent ...
> 
>   (2) Have qemu-clipboard-agent and qemu-guest-agent share the agent
>       channel, i.e. qemu-clipboard-agent will proxy everything through
>       qemu-guest-agent (spice does it that way).
> 
> Protocol options I see are (not sure yet which to prefer, need to have
> a closer look at the candidates):
> 
>   (1) Add clipboard commands to QMP and use these.
> 
>   (2) Reuse the clipboard bits of the vnc protocol (forward
>       VNC_MSG_CLIENT_CUT_TEXT messages to the guest agent)
> 
>   (3) Reuse the clipboard bits of the spice-agent protocol.
> 
>   (4) Reuse the clipboard bits of the wayland protocol.
> 
> Once we have sorted the qemu <-> guest communication path it should be
> possible to also hook up other UIs (specifically gtk) without too much
> effort.  Which probably makes (2) a rather poor choice.

I think the VNC clipboard stuff is too crude to base a long term
design on. I figure we'll want to be at least inspired by (3) or
(4).

> Comments?
> Suggestions?
> Other ideas?

The QEMU guest agent is a single system level agent. IIUC, with SPICE
you have a single system level agent, and then zero or more session
level agents - one per desktop login basically. I assume we'll want
to support the latter too, at least from a design level, even if we
don't implemnet multi session straight away.

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 :|



  reply	other threads:[~2021-01-28 17:42 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-28 17:12 vnc clipboard support Gerd Hoffmann
2021-01-28 17:35 ` Daniel P. Berrangé [this message]
2021-01-29  7:59   ` Gerd Hoffmann
2021-01-28 17:38 ` Christophe de Dinechin
2021-01-29  8:03   ` Gerd Hoffmann
2021-01-29 10:50     ` Christophe de Dinechin
2021-01-29 11:08       ` Daniel P. Berrangé
2021-01-29 14:19         ` Christophe de Dinechin
2021-01-29 14:32           ` Daniel P. Berrangé
2021-02-01 15:27             ` Christophe de Dinechin
2021-02-01 15:51               ` Daniel P. Berrangé
2021-02-01 16:31                 ` Christophe de Dinechin
2021-02-01 16:56                   ` Daniel P. Berrangé
2021-02-01 17:28                     ` Christophe de Dinechin
2021-02-01 17:40                       ` Daniel P. Berrangé
2021-02-01 18:45                         ` BALATON Zoltan
2021-02-02 11:31                           ` Gerd Hoffmann
2021-02-02 12:31                             ` BALATON Zoltan
2021-02-02 12:38                               ` Daniel P. Berrangé
2021-02-02 13:35                                 ` Gerd Hoffmann
2021-02-02 16:36                                   ` Gerd Hoffmann
2021-02-02 21:00                                     ` Marc-André Lureau
2021-02-03  9:40                                       ` Gerd Hoffmann
2021-02-02 11:10                         ` Gerd Hoffmann
2021-02-02 11:17                           ` Daniel P. Berrangé
2021-02-02 11:44                             ` Gerd Hoffmann
2021-01-29 15:04           ` Gerd Hoffmann
2021-02-01 17:07             ` Christophe de Dinechin
2021-01-29 11:49       ` Gerd Hoffmann
2021-01-29 13:28         ` Christophe de Dinechin
2021-01-28 17:57 ` Laszlo Ersek
2021-01-29  8:09   ` Gerd Hoffmann
2021-01-29 10:02   ` Daniel P. Berrangé
2021-01-28 20:18 ` Marc-André Lureau
2021-01-28 20:47   ` BALATON Zoltan
2021-01-29  7:59   ` Christophe de Dinechin
2021-01-29  8:27   ` Gerd Hoffmann
2021-01-29  8:34     ` Marc-André Lureau
2021-01-29 10:33       ` Gerd Hoffmann
2021-01-29 11:10       ` Daniel P. Berrangé
2021-01-29 11:24   ` Daniel P. Berrangé
2021-01-29 11:58     ` Marc-André Lureau
2021-01-29 12:21       ` Daniel P. Berrangé
2021-01-29 12:02   ` Gerd Hoffmann
2021-01-29 12:10     ` Marc-André Lureau
     [not found] <CWLP265MB5209050A121EB63FE07F9BD5A8689@CWLP265MB5209.GBRP265.PROD.OUTLOOK.COM>
2023-04-30 16:20 ` VNC " Philipp Hahn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210128173504.GS3832029@redhat.com \
    --to=berrange@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).