qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Gerd Hoffmann <kraxel@redhat.com>
To: BALATON Zoltan <balaton@eik.bme.hu>
Cc: "Daniel P. Berrangé" <berrange@redhat.com>,
	"Christophe de Dinechin" <cdupontd@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: vnc clipboard support
Date: Tue, 2 Feb 2021 12:31:44 +0100	[thread overview]
Message-ID: <20210202113144.jrmqtgllpgd2nw2h@sirius.home.kraxel.org> (raw)
In-Reply-To: <8456ae54-b737-fa7d-cac8-75cd701f9ef5@eik.bme.hu>

> > 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.
> 
> I think spice is not as widely available as VNC (or even Synergy) so the
> idea to strip one of those down to just a guest clipboard agent would help
> to get support to the most guests.

Well, we can use the spice agent as-is, then just let it talk to qemu
instead of spice client.  No need to code anything on the guest side,
and the (guest) code packaged up in distros will just work.

> QEMU already knows about VNC so might be the simplest way and you
> could reuse all kinds of VNC client and server code for the guest
> agent and also make it easy for others to add support for their
> guests.

Something vnc-ish doesn't look like a good plan to me.  When coding up
something new I'd go model the protocol after something more modern like
wayland.  When reusing something existing the spice-agent protocol looks
best as most existing linux guests already support it.

Also note that we can hook up clipboard support for the other UIs too
once we have the infrastructure in qemu, so even though there is "vnc"
in the subject line this isn't about vnc only.

> Using spice may not be that easi as it's less widespread so probably
> only works on the guests that already have support for it. And then
> why not just use spice instead of VNC on those guests and then you
> don't have the clipboard problem either.

The guest side is easy.  The spice-vdagent package is small, and the
dependencies it needs are most likely present anyway in a guest with
a graphical desktop installed.

The host side is a bit more tricky.  spice-server has a relatively long
list of dependencies not needed otherwise on a virtualization host.

> > 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.
> 
> As I understood, the idea is not to run a full VNC server on the guest OS
> but to make it easy to write the guest agent that you'll need to run is to
> reuse parts of a VNC server which is already available on almost all
> platforms.

spice guest agent is already available for linux and windows.  Not fully
sure how the state is on other unix-ish platforms like *bsd is.  In any
case it should not be that hard to port the linux version over.

take care,
  Gerd



  reply	other threads:[~2021-02-02 11:33 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é
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 [this message]
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=20210202113144.jrmqtgllpgd2nw2h@sirius.home.kraxel.org \
    --to=kraxel@redhat.com \
    --cc=balaton@eik.bme.hu \
    --cc=berrange@redhat.com \
    --cc=cdupontd@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).