virtio-input for copy/paste?
Hi,
Is there anywhere that virtio has where host/guest copy/paste would
fit? I don't think it's something we have defined at the moment
and I was wondering if virtio-input would be the right place to add it. If the client driver supported the feature then the host would hand it to the client, if it didn't it could insert a string of key events.
It probably needs some design to ensure that whatever we have
would work with existing guests and existing transports like VNC.
Dave
Signature · 6 lines
Dr. David Alan Gilbert / [email protected] / Manchester, UK --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Quoted 3 lines · Dr. David Alan Gilbert
Hi,
Is there anywhere that virtio has where host/guest copy/paste would
fit?
Well, spice supports it, with spice client and spice guest agent talking to each other using a virtio-serial channel (guest <-> spice-server) and a spice protocol tunnel (spice-server <-> spice-client).
You'll need a guest agent anyway, to bridge between window system (x11/wayland/...) and device, so running some protocol over a stream doesn't look bad to me as design choice. These days you might choose vsock instead (depends on how you design the host side 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).
Quoted 5 lines
I don't think it's something we have defined at the moment and I was wondering if virtio-input would be the right place to add it. If the client driver supported the feature then the host would hand it to the client, if it didn't it could insert a string of key events.
The problem with such a fallback is keyboard maps. virtio-input sends scancodes not keysyms. Even with us-ascii this is a problem (querty vs. quertz), and it doesn't become easier with € æ ä ß and emoji ...
take care,
Gerd
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Quoted 8 lines · * Gerd Hoffmann ([email protected]) wrote:
Quoted 3 lines · Dr. David Alan Gilbert
Hi,
Is there anywhere that virtio has where host/guest copy/paste would
fit?Well, spice supports it, with spice client and spice guest agent talking to each other using a virtio-serial channel (guest <-> spice-server) and a spice protocol tunnel (spice-server <-> spice-client).
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.
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.
Quoted 10 lines
You'll need a guest agent anyway, to bridge between window system (x11/wayland/...) and device, so running some protocol over a stream doesn't look bad to me as design choice. These days you might choose vsock instead (depends on how you design the host side 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?
Quoted 9 lines
Quoted 5 lines
I don't think it's something we have defined at the moment and I was wondering if virtio-input would be the right place to add it. If the client driver supported the feature then the host would hand it to the client, if it didn't it could insert a string of key events.
The problem with such a fallback is keyboard maps. virtio-input sends scancodes not keysyms. Even with us-ascii this is a problem (querty vs. quertz), and it doesn't become easier with € æ ä ß and emoji ...
Yeh tricky.
Dave
Quoted 8 lines
take care,
Gerd---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Signature · 6 lines
Dr. David Alan Gilbert / [email protected] / Manchester, UK --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Hi,
Quoted 3 lines
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?
Quoted 3 lines
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.
Quoted 7 lines
Quoted 5 lines
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.
take care,
Gerd
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Quoted 6 lines · * Gerd Hoffmann ([email protected]) wrote:
Hi,
Quoted 3 lines
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.
Quoted 6 lines
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.
Quoted 21 lines
Quoted 3 lines
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.
Quoted 6 lines
Quoted 5 lines
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).
Quoted 4 lines
Quoted 1 line
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->hostcut+paste.
OK, I was less worried about the host stealing from the guest, since it normally already can.
Dave
Quoted 8 lines
take care,
Gerd---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Signature · 6 lines
Dr. David Alan Gilbert / [email protected] / Manchester, UK --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
Hi,
Quoted 5 lines
Quoted 2 lines
Guest UI too (you can make the same argument the other way around) if we want support
guest->hostcut+paste.OK, I was less worried about the host stealing from the guest, since it normally already can.
Yes, typically that would less concerning. I wouldn't completely ignore it though, SEV exists for a reason. Also you might not want cut+paste inside the guest overwrite the host clipboard.
take care,
Gerd
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]