Input -> Keyboard -> "Paste as text (send characters)"

[sorin_postelnicu]

I have an idea of a very "basic" feature, but I am not sure where I could open a ticket for this:
Add the following menu item: Input -> Keyboard -> "Paste as text (send characters)"

This would have this very simple functionality which is very useful when the guest-machine is in text-mode:
it will read the host clipboard as text (the VirtualBox host application will do this, without the guest machine having access to the host clipboard),
and it will send the text to the guest machine virtual keyboard, as if the user had manually typed the pasted characters.

This simple operation would then be available even if GuestAdditions is not installed or if Shared Clipboard is disabled.

[socratis]

Input -> Keyboard -> "Paste as text (send characters)"

Hey, I like that one!!! Something like "emulate key presses". I mean we can already send Alt-Ctrl-Del, Ctrl-Break and Insert. Why not tap in the host's clipboard, and if it is text, emulate each character as a key entered manually! That could work. Even the shortcut HostKey+V is available!

Of course the opposite, from Guest to Host, would not be that easy, because you'd have to have access to the guest's clipboard; that's where the GAs are playing their role.

I like it a lot. I'll look in the bugtracker if it is already filed (later, got to go now). If not, I'll open an enhancement ticket and I'll update the thread.

[Martin]

Host to guest is a little more complex because Vbox only sends key scan codes to the guest and you would need to define a way to translate a character to a corresponding key on the keyboard. And there could be characters in the clipboard which don't have a key on the keyboard.

[socratis]

Acceptable. How about restricting it to what's available on the keyboard; i.e. ASCII only.
If not ASCII => reject it (the whole thing altogether? the action? the capability?).

[socratis]

I thought this deserved it's own topic, so it got split from: Discussion about "Summary of Most Requested Features".
Actually it wasn't even a Most Requested Feature...

[socratis]

I'll look in the bugtracker if it is already filed (later, got to go now). If not, I'll open an enhancement ticket and I'll update the thread.

Turns out this is a requested feature, an old one, the oldest in reference to Clipboard to be exact. We have the following tickets:

• 2017-09-08, #17066 : Universal host-to-guest paste (closed enhancement: duplicate)
• 2016-04-30, #15372 : Let users paste plain text as keystrokes (closed enhancement: duplicate)
• 2016-01-12, #15031 : Add menu item to type/insert clipboard contents to keyboard (closed enhancement: duplicate)
• 2011-07-24, #9291 : [feature-request] Guest Additions: Please provide clipboard copy paste for text-mode console VMs (without X.org) (closed enhancement: duplicate)
• 2009-02-07, #3293 : Genereal text paste support (host->guest) (closed enhancement: duplicate)
• 2008-01-31, #1139 : Feature request: wider copy/paste support, in Console for instance

I don't know enough about the code, I'll ask in the developer's list and see where we are. Damn, it seems so simple (in theory), but it's open for more than 8 years now, so I guess it should tell me something (like, avoid it?).

[michaln]

If you think you're missing something basic... you're right.

The problem is that a) the host can only send scan codes, not ASCII characters, b) the guest will translate scancodes according to any of a myriad possible keyboard layouts, c) you don't know what the keyboard layout in the guest is, and d) the layout in the guest can change at any time. Point b) makes implementation extremely labor intensive, and point c) either renders the whole exercise useless or pawns off the responsibility to the user (with predictably poor outcomes).

VirtualBox would need to support at least a good number of common keyboard layouts. From a practical perspective, we never figured out how to implement something like this in a way that would not increase the number of user complaints. A poorly implemented feature is worse than no feature at all, because it's a lot faster to say "no" than to fix broken code, leave alone to fix a broken design.

Just to be clear, synthesizing scan codes only makes sense if there are no Guest Additions or similar in the guest. If there is any host-controllable component running inside the guest, then shared clipboard etc. is a far better option.

I will add that synthesizing Alt+Num Pad combinations would sound like a tantalizing option for Windows guests if Microsoft didn't f**k it up in Vista and later versions.

[socratis]

a) the host can only send scan codes, not ASCII characters

That's "translatable", that's the easy part, no? But, you have more points. Of course you would, I didn't think it would be easy...

b) the guest will translate scancodes according to any of a myriad possible keyboard layouts

Physical or logical? Because the logical ones, we can throw them all out. All of them. But, if there is a difference in the scan key code, for the key to the right of the Tab between a AZERTY and a QWERTY, then, yes, that is sort of a problem. I am thinking (maybe naively) that if the "A" key is pressed, no matter where it is "geographically" on the keyboard, you'll get the same scan code. I mean, if I connect a AZERTY keyboard and tell nothing about it to my host, would pressing "A" produce a "Q"?

c) you don't know what the keyboard layout in the guest is, and d) the layout in the guest can change at any time.

I don't really care. If it's ASCII QWERTY, it will work. If not tough luck. Again, that is under the assumption that a key-scan-code is a key-scan-code, independent of geographical coordinates.

A poorly implemented feature is worse than no feature at all, because it's a lot faster to say "no" than to fix broken code, leave alone to fix a broken design.

Couldn't agree more. If it is doable as ASCII only, and is documented as such, then, point them to the documentation and close the bug as "Invalid" or "WorksForMe" or "WontFix". Pretty much, just say no, but in a different, gentler no. And mind you, this is only for things like URLs and CLI commands. And not the ones with "ω" or "á" or "ø" in them.

Just to be clear, synthesizing scan codes only makes sense if there are no Guest Additions or similar in the guest. If there is any host-controllable component running inside the guest, then shared clipboard etc. is a far better option.

+1
But, there are a ton of guests that do not have GAs, my favorite OS X guests being one of them. Just typing over and over again things that I have notes for, instead of copy/paste them is a pain I could live without. Yes, I know I could share the notes . Plus doing the clipboard->fake keyboard would help a lot of clients (and save me a great headache about GAs for OSX).

I will add that synthesizing Alt+Num Pad combinations would sound like a tantalizing option

Nope, nothing like that. As I already mentioned in #1139, we need just to cover the basic ASCII, from 0x20 (space) to 0x7e(~). Possibly 0x0a (LF) and 0x0d (CR), but I don't see (at this point) the need for multi-line text; you're going to run into line-ending problems/headaches.

[Martin]

But, if there is a difference in the scan key code, for the key to the right of the Tab between a AZERTY and a QWERTY, then, yes, that is sort of a problem. I am thinking (maybe naively) that if the "A" key is pressed, no matter where it is "geographically" on the keyboard, you'll get the same scan code. I mean, if I connect a AZERTY keyboard and tell nothing about it to my host, would pressing "A" produce a "Q"?

Yes it would, and that's the problem. A keyboard scan code just consists of row/column and therefore you would need to decide if an "a" in the clipboard should send the scancode from a QWERTZ/QWERTY keyboard (the key right of <Caps Lock>) or from an AZERTY keyboard (the key right of <Tab>) or maybe even somewhere else on another layout.

[michaln]

b) the guest will translate scancodes according to any of a myriad possible keyboard layouts

Physical or logical? Because the logical ones, we can throw them all out. All of them. But, if there is a difference in the scan key code, for the key to the right of the Tab between a AZERTY and a QWERTY, then, yes, that is sort of a problem. I am thinking (maybe naively) that if the "A" key is pressed, no matter where it is "geographically" on the keyboard, you'll get the same scan code. I mean, if I connect a AZERTY keyboard and tell nothing about it to my host, would pressing "A" produce a "Q"?

That is exactly the problem. All 101/102-key keyboards have the exact same physical layout. That is to say, if you press the key to the right of the Tab key, you will always get the same scan code. It's up to the software to decide whether it's translated to 'A', 'Q', or something completely different.

The labels on the keys are just pictures, they have absolutely no significance to the hardware. The system also doesn't have any way to tell what the pictures on the keys look like (i.e. what the layout is). If you think this is really poorly thought out, I sort of agree. It's actually not thought out at all, it just happened that way.

But this is why even if you restrict the problem to ASCII text, or even if you restrict it to just alphanumeric characters (26 letters + 10 digits), you still can't even synthesize the input the same way across basic US/German/French keyboard layouts.

[michaln]

I will add that synthesizing Alt+Num Pad combinations would sound like a tantalizing option

Nope, nothing like that. As I already mentioned in #1139, we need just to cover the basic ASCII, from 0x20 (space) to 0x7e(~). Possibly 0x0a (LF) and 0x0d (CR), but I don't see (at this point) the need for multi-line text; you're going to run into line-ending problems/headaches.

To be clear, that's not related to multi-line text. That's just about entering ASCII codes directly, without depending on the keyboard layout selected in the guest.

[socratis]

I mean, if I connect a AZERTY keyboard and tell nothing about it to my host, would pressing "A" produce a "Q"?

And with a couple of clear answers to my question, we can now close this as "WontFix".

It was the only point that could have had a flaw in the logic (from where I'm standing). Damn! Of course, had I done my homework, I wouldn't even have raised the question. From Wikipedia's article on Keyboard layout, Mechanical and visual layout:

Mechanical and visual layouts
Mechanical layouts only address tangible differences among keyboards. When a key is pressed, the keyboard does not send a message such as the A-key is depressed but rather the left-most main key of the home row is depressed. (Technically, each key has an internal reference number, “raw keycodes”, and these numbers are what is sent to the computer when a key is pressed or released.) The keyboard and the computer each have no information about what is marked on that key, and it could equally well be the letter A or the digit 9. The user of the computer is requested to identify the visual layout of the keyboard when installing the operating system. Visual layouts vary by language, country, and user preference, and the same mechanical layout can be produced with a number of different visual layouts. For example, the “ISO” keyboard layout is used throughout Europe, but typical French, German, and UK variants of mechanically identical keyboards appear different because they bear different legends on their keys. Even blank keyboards – with no legends – are sometimes used to learn typing skills or by user preference.

(michaln, did you write that article in Wikipedia? your answer is almost identical )

The thing is that I vaguely remember that there was a microchip in every keyboard, which I wrongly assumed that made the geographical to functional layout translation. Apparently that is not the case. After further reading it is far more simple than I thought (the chip) and I don't think it's even used anymore for things like USB keyboards.

Thanks michaln and Martin for your comments. I had a good dream for a couple of hours...

Next stop: GAs for OS X!
(just the clipboard sharing, nothing more...)

[michaln]

(michaln, did you write that article in Wikipedia? your answer is almost identical )

No, I didn't, and I didn't quote from it either

The thing is that I vaguely remember that there was a microchip in every keyboard, which I wrongly assumed that made the geographical to functional layout translation. Apparently that is not the case. After further reading it is far more simple than I thought (the chip) and I don't think it's even used anymore for things like USB keyboards.

You are correct about the microcontroller in keyboards, it's been there since the first PCs. But it doesn't do any translation, it only scans for keypresses and communicates with the host system.

USB isn't any better. Some USB keyboards maaaybe indicate what layout they use, but I don't think I've seen such a keyboard (and even if the keyboard advertised its layout, there's no guarantee the OS uses it). USB does not use scan codes but it does have "HID usage codes" which are basically the same thing, with the same problems. The basic architecture is the same, only the communication protocol is different.

[mpack]

The basic architecture is the same, only the communication protocol is different.

Hence the easy availability of those little widgets that adapt a USB keyboard to a PS/2 socket.

[sorin_postelnicu]

This is such sad news
I admit that I didn't do my research before posting, and I just assumed that it's common-sense that the keyboards also send character-codes, not only key-presses/releases codes...

Maybe it's time for an upgrade in the keyboard technology
Although this is highly improbable, given that now touchscreens are the new norm in computing...


But, if we are to think positively about this wished feature, we can still add an extra requirement to it instead of just dismissing it as "Won't fix":
The proposed menu-item "Paste as text (send characters)" could be in fact a sub-menu (like the Input -> Keyboard) with a (long but limited) list of keyboard layouts, which should at least include the US standard keyboard.
So the user will then be responsible to specify which keyboard layout should be used to convert the clipboard characters (at least ASCII only) into keyboard events.
(And as long as there is at least one layout definition in the VirtualBox implementation, then the implementation of other layouts can be done later, by anyone who volunteers to implement their own preferred keyboard layout)

Or there could be an extra preference in the VirtualBox machine definition (.vbox file) to specify the keyboard layout (and the user will have the ability to select it in the Input -> Keyboard -> Keyboard settings...), something like this:
<HID Pointing="PS2Mouse" Keyboard="PS2Keyboard" KeyboardLayout="US" />
or
<HID Pointing="PS2Mouse" Keyboard="PS2Keyboard" KeyboardLayout="United States - International" />


It's better to have this feature with only the US keyboard layout option, rather than not have it at all.
(I myself work in Belgium where the most common keyboard layout is the AZERTY, but I don't mind if only the US keyboard will be supported as an option in VirtualBox, because it's not difficult to login into the guest OS and choose the US keyboard layout, irrespective of my physical keyboard layout.)