[pve-devel] [PATCH qemu-server v3 1/6] enable clipboard parameter in vga_fmt
Dominik Csapak
d.csapak at proxmox.com
Thu Mar 2 11:28:17 CET 2023
first:
sorry for the late review ;)
high level comments:
i know why you're adding it to the vga format, but maybe that's not the way
to go? we couple the console method with the display quite a lot, but
maybe we don't want to further increase that coupling?
(imho it would be much nicer to be able to define the console method/options
independently to the virtual display hardware)
any thoughts to that anyone?
On 10/28/22 14:33, Markus Frank wrote:
> added option to use the qemu vdagent implementation to enable the noVNC
> clipboard. When enabled with SPICE the spice-vdagent gets replaced with the qemu
> implementation.
>
> This patch does not solve #1406, but does allow copy and paste with
> a running X-session, when spice-vdagent is installed on the guest.
>
> Signed-off-by: Markus Frank <m.frank at proxmox.com>
> ---
> PVE/QemuServer.pm | 19 ++++++++++++++++++-
> PVE/QemuServer/PCI.pm | 3 ++-
> 2 files changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/PVE/QemuServer.pm b/PVE/QemuServer.pm
> index c706653..333afc2 100644
> --- a/PVE/QemuServer.pm
> +++ b/PVE/QemuServer.pm
> @@ -190,6 +190,12 @@ my $vga_fmt = {
> minimum => 4,
> maximum => 512,
> },
> + clipboard => {
> + description => "enable clipboard (requires spice-vdagent)",
i'd expand/change that a bit, e.g. by saying it needs the spice tools
in the guest (spice-vdagent is rather linux specific)
> + type => 'boolean',
> + optional => 1,
> + default => 0
> + }
> };
>
> my $ivshmem_fmt = {
> @@ -3836,6 +3842,13 @@ sub config_to_command {
> }
> }
>
> + if ($vga->{clipboard} && $vga->{type} =~ /^std|^cirrus|^vmware/) {
that regex could be written as /^(std|cirrus|vmware)/, it's a bit clearer and
if one adds one, the chance to oversee/forget the '^' is mitigated
also, whats with serial ports? can it even work on that?
maybe it would be nicer to have some compatibility hash where we can simply
add the vga methods supported, and add it here only instead of in two places?
(just a thought, you don't have to go that way if it's not much better)
> + push @$devices, '-chardev', 'qemu-vdagent,id=vdagent,name=vdagent,clipboard=on';
> + my $pciaddr = print_pci_addr("clipboard", $bridges, $arch, $machine_type);
> + push @$devices, '-device', "virtio-serial-pci$pciaddr";
> + push @$devices, '-device', 'virtserialport,chardev=vdagent,name=com.redhat.spice.0';
> + }
> +
> my $rng = $conf->{rng0} ? parse_rng($conf->{rng0}) : undef;
> if ($rng && $version_guard->(4, 1, 2)) {
> check_rng_source($rng->{source});
> @@ -3880,7 +3893,11 @@ sub config_to_command {
> die "failed to get an ip address of type $pfamily for 'localhost'\n" if !@nodeaddrs;
>
> push @$devices, '-device', "virtio-serial,id=spice$pciaddr";
> - push @$devices, '-chardev', "spicevmc,id=vdagent,name=vdagent";
> + if ($vga->{clipboard}) {
> + push @$devices, '-chardev', 'qemu-vdagent,id=vdagent,name=vdagent,clipboard=on';
like i wrote above, we add it in two different places (that cannot happen together AFAICS)
it would be much nicer if we'd only have a single point in the code where we add that
> + } else {
> + push @$devices, '-chardev', 'spicevmc,id=vdagent,name=vdagent';
> + }
> push @$devices, '-device', "virtserialport,chardev=vdagent,name=com.redhat.spice.0";
>
> my $localhost = PVE::Network::addr_to_ip($nodeaddrs[0]->{addr});
> diff --git a/PVE/QemuServer/PCI.pm b/PVE/QemuServer/PCI.pm
> index 3d0e70e..7ddabe0 100644
> --- a/PVE/QemuServer/PCI.pm
> +++ b/PVE/QemuServer/PCI.pm
> @@ -138,7 +138,8 @@ sub get_pci_addr_map {
> scsihw1 => { bus => 0, addr => 6 },
> ahci0 => { bus => 0, addr => 7 },
> qga0 => { bus => 0, addr => 8 },
> - spice => { bus => 0, addr => 9 },
> + spice => { bus => 0, addr => 9, conflict_ok => qw(clipboard) },
> + clipboard => { bus => 0, addr => 9, conflict_ok => qw(spice) }, # clipboard is used if spice is not running
> virtio0 => { bus => 0, addr => 10 },
> virtio1 => { bus => 0, addr => 11 },
> virtio2 => { bus => 0, addr => 12 },
More information about the pve-devel
mailing list