"Type" clipboard (feature already requested? unsure)

[BloodyIron]

Hey cool cats,

I do see the noVNC QEMU clipboard state is being improved upon, starting a bit with v8.2 and probably later versions.

However I tried to search via Google/elsewhere if a particular clipboard related function/feature had already been requested, and really could not find any "hits", so I'm taking to the forum first (instead of posting a ticket).

So... I was hoping that some day we could have a way to have the VM/LXC/whatever local console "type" out what is in the clipboard of the client manually (and maybe have some sort of interface confirming/enabling you to edit what is typed, etc). So that this could be a "universal override" so to say agnostic of whatever OS the console is for. And yes one-way, only send clipboard-ish to the console.

This would be particularly useful for broken systems, or systems that may "never" be nice to current/future console interfacing. Particularly useful for resetting/entering passwords on wonky/obscure systems. Especially when one wants to use rather strong (long and complex) passwords in wonky scenarios.

So yeah... is this ask "already tracked" or am I the first to request it, etc? I think this particular item is worth doing as it is tangibly distinct from the other efforts I have seen.

Either way, thanks for your time hearing me out! Love the Proxmox team for all the stuff, and the forum members too, you all rock some serious socks!

 

[MarkusF]

hello,

did I understand correctly? You want to copy text to a VM or LXC regardless of the display protocol?
All display options support clipboard as far as I know.

xterm.js supports clipboard
SPICE supports clipboard via spice-vdagent
VNC supports clipboard via spice-vdagent

With this tool you could also send text to VNC without spice-vdagent:
https://github.com/sibson/vncdotool

 

[BloodyIron]

No, not copy text, type it out. As in simulate the keyboard being pressed with the entry of the clipboard. This is so that no client software needs to be installed, the VM/LXC object does not need to be in a particular configured state (at the hypervisor level), and so the GuestOS does not need certain software installed for this to happen.

This is distinct from simply "copying" the clipboard in that this does not interface with the common clipboard functionality in any guest, it again, is strictly simulating typing out the contents of the clipboard.

There are many scenarios I encounter where this would be huge value due to many scenarios not having any clipboard capability at all.

The request is for this to become a built-in functional option, not rely on external tools. And a CLI tool for this function really is not a good solution. I really don't want to have to open another terminal window just to type clipboard text into the local console I have open in another window.

 

[MarkusF]

If no client software is installed, QEMU has no idea what keyboard layout the client is using and therefore does not know what keycodes to send.

Here is the post of a colleague explaining the problem:
https://forum.proxmox.com/threads/novnc-copy-paste-not-works.19773/post-487471

 

[BloodyIron]

If no client software is installed, QEMU has no idea what keyboard layout the client is using and therefore does not know what keycodes to send.

Here is the post of a colleague explaining the problem:
https://forum.proxmox.com/threads/novnc-copy-paste-not-works.19773/post-487471

Why not just use the language of the client user session (webGUI login preference) and use that to determine a keyboard layout? Or maybe have keyboard layout setting for user preferences? The characters to-be-sent are already known as they're in the clipboard that can be read, the next step is just sending the equivalent instructions to the console of the Proxmox VE Object that "these characters were typed in this order" kind of thing.

I am optimistic there is a solution here.

 

[MarkusF]

Why not just use the language of the client user session (webGUI login preference) and use that to determine a keyboard layout?

Because it can be different from the layout inside the VM. There are also variants of keyboard layouts like altgr-int and layouts with deadkeys.

There is not generic solution for this problem.
You would need to maintain a translation for all of the available layouts and variants in the world on every operating system.

The only solution I have in mind would be to write a new keyboard driver for each operating system. But this is very difficult (if even possible) and unnecessary, since you can just install spice-vdagent or set up a serial console to use a clipboard.

 

[BloodyIron]

Because it can be different from the layout inside the VM. There are also variants of keyboard layouts like altgr-int and layouts with deadkeys.

There is not generic solution for this problem.
You would need to maintain a translation for all of the available layouts and variants in the world on every operating system.

The only solution I have in mind would be to write a new keyboard driver for each operating system. But this is very difficult (if even possible) and unnecessary, since you can just install spice-vdagent or set up a serial console to use a clipboard.

Well what about it being a "Beta, only turn on if you know what you're doing" kind of feature? Whereby it is written with a very limited set of features (en-US + en-GB, US104/qwerty, for example) that are explicitly spelled out, so the aspects you speak to are "accounted" for by it being an "advanced only" feature?

I hear what you're saying, but the value of having this, even for the very limited scope of en-US, would be very very high. And quite frankly not having it is causing me regular problems. It's very inconsistent in my experience to determine "which" systems I can do anything with a clipboard, and which I cannot. It is also worth pointing out that the statistical majority of systems in IT are en-US/qwerty/US104, so I don't think it's unreasonable to have a limited scope for this (even if that's all it ever is, or maybe just a starting point).

How about that?

 

[LnxBil]

It is also worth pointing out that the statistical majority of systems in IT are en-US/qwerty/US104, so I don't think it's unreasonable to have a limited scope for this (even if that's all it ever is, or maybe just a starting point).

That statistic may be way off with respect to PVE, yet I hear you

I also thought about this for years and saw its first implementation in Hyper-V, which does exactly this and I really love it. This is the only thing I love about Hyper-V and I really miss it in other hypervisors. For PVE, I wrote a small script to generate the QEMU sendkey commands and plug then into the qemu monitor for the VM in PVE to get what I want, yet this is not really user friendly but gets the work done.

 

[BloodyIron]

That statistic may be way off with respect to PVE, yet I hear you

I also thought about this for years and saw its first implementation in Hyper-V, which does exactly this and I really love it. This is the only thing I love about Hyper-V and I really miss it in other hypervisors. For PVE, I wrote a small script to generate the QEMU sendkey commands and plug then into the qemu monitor for the VM in PVE to get what I want, yet this is not really user friendly but gets the work done.

Yeah I can only really speak to the statistics I "mostly" know ;P I have no real idea on specific demographics for Proxmox VE at all, hence the touch of nuance.

I really see a basic starter function set here being very useful. And maybe even building on it over time to fill the achievable gaps could be worthwhile too. I don't think we necessarily need to build a monolith here on first-attempt, and I certainly don't want to keep certain sections of humanity excluded either, but a "happy medium" I think can be struck here as a starting point.

Any thoughts @MarkusF ? Appreciate your time on this topic, thanks!

 

[MarkusF]

Any thoughts @MarkusF ? Appreciate your time on this topic, thanks!

I found a feature request in our bugtracker: https://bugzilla.proxmox.com/show_bug.cgi?id=5393
This should be the feature you actually want.

For PVE, I wrote a small script to generate the QEMU sendkey commands and plug then into the qemu monitor for the VM in PVE to get what I want, yet this is not really user friendly but gets the work done.

You do not need to use the qemu monitor, you can just use the CLI for this: qm sendkey <vmid> <key>

Here are all the keys you can send.
https://en.wikibooks.org/wiki/QEMU/Monitor#sendkey_keys

You could than script something like this (sendkey.pl):

#!/usr/bin/perl

use strict;
use warnings;

my %keycodes = (
    'a' => 'a',
    'b' => 'b',
    'c' => 'c',
    'd' => 'd',
    'e' => 'e',
    'f' => 'f',
    'g' => 'g',
    'h' => 'h',
    'i' => 'i',
    'j' => 'j',
    'k' => 'k',
    'l' => 'l',
    'm' => 'm',
    'n' => 'n',
    'o' => 'o',
    'p' => 'p',
    'q' => 'q',
    'r' => 'r',
    's' => 's',
    't' => 't',
    'u' => 'u',
    'v' => 'v',
    'w' => 'w',
    'x' => 'x',
    'y' => 'y',
    'z' => 'z',
    '0' => '0',
    '1' => '1',
    '2' => '2',
    '3' => '3',
    '4' => '4',
    '5' => '5',
    '6' => '6',
    '7' => '7',
    '8' => '8',
    '9' => '9',
    ' ' => 'spc',
    '!' => 'shift-1',
    '@' => 'shift-2',
    '#' => 'shift-3',
    '$' => 'shift-4',
    '%' => 'shift-5',
    '^' => 'shift-6',
    "&" => 'shift-7',
    '*' => 'shift-8',
    '(' => 'shift-9',
    ')' => 'shift-0',
    '-' => 'minus',
    '_' => 'shift-minus',
    '=' => 'equal',
    '+' => 'shift-equal',
    ';' => 'semicolon',
    ':' => 'shift-semicolon;',
    ',' => 'comma',
    '<' => 'shift-comma',
    '.' => 'dot',
    '>' => 'shift-dot',
    '/' => 'slash',
    '?' => 'shift-slash',
);

my $vmid = shift || die "Usage: $0 <vmid> <text>\n";
my $input_text = shift || die "Usage: $0 <vmid> <text>\n";

sub translate_to_keycodes {
    my ($text) = @_;
    my @keycode_sequence;
    foreach my $char (split('', $text)) {
        $char = lc($char);
        my $keycode = $keycodes{$char};
        if ($keycode) {
       push @keycode_sequence, $keycode;
        }
    }
    return @keycode_sequence;
}

my @keycode_sequence = translate_to_keycodes($input_text);

foreach my $keycode (@keycode_sequence) {
    print("qm sendkey $vmid $keycode \n");
    system("qm sendkey $vmid $keycode");
}

and than run: ./sendkey.pl <vmid> "foobar"

 

[LnxBil]

Nice! The API endpoint should be easily integratable into the noVNC console and also a virtual keyboard is pretty straight forward.