From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: virtio-dev@lists.oasis-open.org, berrange@redhat.com
Subject: Re: [virtio-dev] Re: virtio-input for copy/paste?
Date: Thu, 20 Aug 2020 08:50:03 +0100 [thread overview]
Message-ID: <20200820075003.GA2664@work-vm> (raw)
In-Reply-To: <20200820053250.jy3fwuhy5josnfog@sirius.home.kraxel.org>
* Gerd Hoffmann (kraxel@redhat.com) wrote:
> Hi,
>
> > Right; what I was interested in was whether there would be a way to
> > plumb copy/paste through for a VNC or local Gtk display; the guest view
> > should be independent of the transport protocol.
>
> Well. Full-blown cut+paste is quite complex. spice goes all-in and
> supports cut+paste everything both ways. The minimal thing would be
> host -> guest support for "text/plain; charset=utf-8". Quick google
> search suggests the vnc protocol supports just that.
>
> So, what exactly we are talking about?
Yes I saw VNC supports some of this; but consider a qemu started
with -vnc and it's remotely displaying - I don't think we wire up VNC's
copy/paste in qemu to give anything to the guest, because we've
got nothing in the guest to present it as - which is what I was trying
to add.
> > Perhaps that way is just to standardise on the virtio-serial channel
> > that spice already uses and provide that for other transports;
> > but if not then it feels like there should be some standard.
>
> Not that easy I think, the channel is not used exclusively for
> cut+paste but also some other, spice-specific stuff.
>
> We could try integrate this into qemu guest agent.
>
> Or use something completely separate. qemu guest agent works at system
> level whereas cut+paste would work on user session level. spice solves
> this by having both system and user daemon, where the user daemon talks
> to the system daemon. With a separate channel you wouldn't need the
> system daemon as middle man though.
>
> > > You also need the agent as user interface, so the user can explicitly
> > > enable clipboard access for the other side (you don't want do this
> > > automatically for security reasons: the guest should not be able to
> > > sniff the passwords which you cut+paste on the host from password
> > > manager to browser).
> >
> > That should be on the host side-UI shouldn't it?
>
> Guest UI too (you can make the same argument the other way around) if we
> want support guest->host cut+paste.
OK, I was less worried about the host stealing from the guest, since it
normally already can.
Dave
> take care,
> Gerd
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
>
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
---------------------------------------------------------------------
To unsubscribe, e-mail: virtio-dev-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: virtio-dev-help@lists.oasis-open.org
next prev parent reply other threads:[~2020-08-20 7:50 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-10 16:41 [virtio-dev] virtio-input for copy/paste? Dr. David Alan Gilbert
2020-08-17 5:15 ` [virtio-dev] " Gerd Hoffmann
2020-08-19 15:35 ` Dr. David Alan Gilbert
2020-08-20 5:32 ` Gerd Hoffmann
2020-08-20 7:50 ` Dr. David Alan Gilbert [this message]
2020-08-20 8:22 ` Gerd Hoffmann
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=20200820075003.GA2664@work-vm \
--to=dgilbert@redhat.com \
--cc=berrange@redhat.com \
--cc=kraxel@redhat.com \
--cc=virtio-dev@lists.oasis-open.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.