virtualbox.org

michaln wrote:
Daniel.Glasser wrote:Is it possible to switch Vbox to provide an emulated USB rather than PS2 keyboard?
Yes. 'VBoxManage modifyvm <vmname> --keyboard usb'

That's been working so far. I'll let you know how it does over an extended period. I've been using the graphical Vbox manager, which does not appear to support setting this via the UI. I'd suggest that it (along with debug) be added as "advanced" settings for a machine; it would make it easier to explore and tweak these things.

BTW I don't know if you noticed that it's possible to send a larger sequence of scan codes with a single command.

Yes, I've sent long sequences of scan codes that way.

When typing in the guest, I have now noticed a lot of lost make scans; that is, I type a character, and nothing happens in the terminal (or editor) window I'm working in. It happens with a similar frequency to the lost break codes.
Okay, that sounds like very good evidence that the guest is simply losing keystrokes. When it's a make code, it can be repeated, but when it's a scan code, it causes real trouble.

The make/break codes are, in effect, scancodes. For example, delete-down (make) is 0x0e, delete-up (break) is 0x8e.

Please try the 'showkey' utility in the guest, perhaps 'showkey -s'. It would also be interesting to know whether the same problem with losing keystrokes occurs in X11 and in a full-screen virtual terminal? What I'm trying to find out is whether it's the Linux kernel losing the scan codes or something (much?) higher up the chain.

Here's something interesting... This is the result from running "Showkey" and then holding the left-shift down for about 4 seconds, releasing it, then holding the left-shift down for another 4 seconds, releasing it, and then doing the same (for less time) with the "caps lock" key. Note that multiple scan codes are being reported for each of these, and they're all "make" codes until the key is released, where the scan code is the make code ORed with 0x80 (this is using the USB keyboard mode):

Code: Select all

$ sudo showkey -s
kb mode was ?UNKNOWN?
[ if you are trying this under X, it might not work
since the X server is also reading /dev/console ]

press any key (program terminates 10s after last keypress)...
0x9c 
0x2a 
0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 
0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 
0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 
0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 
0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 
0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 
0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 
0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0xaa 
0x3a 
0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 
0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 
0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 
0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0xba 
0x3a 
0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 
0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 
0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 
0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 
0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0x3a 0xba 
$

It's looking more and more to me that a virtual USB keyboard emulation option would be a good thing to add (if it's not there already, and I've just not found it.)
That's assuming the USB keyboard protocol is better than the PS/2 protocol... which is sadly not true (USB is a step backwards in so many ways it's not even funny). The USB protocol is completely different and the model falls apart unless there is a slow human hand touching the keys. It's certainly worth trying though.

I wasn't thinking the protocol would be better, but if it is, as I suggested, a problem with how Ubuntu is dealing with the virtual keyboard controller, the USB keyboard uses a completely different path into the Linux "keyboard". Since USB is delivered in packets, it's less likely that the keyboard code will mess things up because code that talks to the PS2 keyboard controller is out of the path the data is coming in through.

I assume that the command "'VBoxManage modifyvm <vmname> --keyboard ps2", or something like it, is how I would switch the keyboard back to PS2.

Thanks for the attention and help so far; I think we're zeroing in on the problem, and may have a work-around.

Daniel.Glasser wrote:That's been working so far. I'll let you know how it does over an extended period. I've been using the graphical Vbox manager, which does not appear to support setting this via the UI. I'd suggest that it (along with debug) be added as "advanced" settings for a machine; it would make it easier to explore and tweak these things.

To be honest, we'd rather not. The problem with all the "advanced" settings is that people go in and start toggling every setting and en up with a big mess. The USB keyboard emulation has its own set of issues and having it selectable in the GUI would on the whole probably cause more problems than it'd solve. We'd much rather fix whatever is causing trouble with Ubuntu with the PS/2 keyboard emulation.

The make/break codes are, in effect, scancodes. For example, delete-down (make) is 0x0e, delete-up (break) is 0x8e.

Yes, I know how PC scan codes work, and about the different scan sets etc

Here's something interesting... This is the result from running "Showkey" and then holding the left-shift down for about 4 seconds, releasing it, then holding the left-shift down for another 4 seconds, releasing it, and then doing the same (for less time) with the "caps lock" key. Note that multiple scan codes are being reported for each of these, and they're all "make" codes until the key is released, where the scan code is the make code ORed with 0x80 (this is using the USB keyboard mode):

I see nothing unusual about that. This is how "typematic keys" (aka key repeat) works. If you press and hold down a key, after a specified time period the keyboard start re-sending the make code with a specified frequency. The fact that there's no break code is how software can distinguish between key repeats and actual physical key presses/releases.

A PS/2 keyboard does this on its own (and it's the keyboard, not the keyboard controller). A USB keyboard does no such thing, it just reports which keys are currently pressed, and does not send new reports unless the state changes. The OS is entirely responsible for emulating the key repeat functionality.

I assume that the command "'VBoxManage modifyvm <vmname> --keyboard ps2", or something like it, is how I would switch the keyboard back to PS2.

Yes, exactly.

Thanks for the attention and help so far; I think we're zeroing in on the problem, and may have a work-around.

Thanks for your help so far! As you can imagine, it's very hard to fix a problem you can't see, and most users who do see the problem are unwilling to communicate beyond "it doesn't work here".

robertb wrote:The guest is Linux.

I have no external USB keyboard, and this problem seems to occur even when not running X-Windows in the guest, i.e., the sticky key duplicates happen even in the linux console window. I also have the guest additions installed.

Is there still no way to fix this problem? Must I live with the key repeating and key drops?

I can verify that I am showing exactly the same symptoms. In a Linux console window running in an ubuntu 64 bit guest, with an OS-X host, I get the auto-repeat problem. The clipboard settings do not seem to have an effect, by the way...

I believe that you can try what I've done; seems to have cleared it up for me. With the VM not running, get into a terminal window, put the directory with VirtualBox in your path (or cd to where it is), and type:

Code: Select all

VBoxManage modifyvm <vmname> --keyboard usb

It does not matter whether your keyboard is an external USB keyboard, it just directs your keyboard input through an emulated USB controller rather than through the emulated keyboard controller.

It is my theory that the problem we're experiencing is an incompatibility with the virtual keyboard controller that Ubuntu is seeing and Ubuntu's keyboard controller driver. X-11 is not part of the problem, it's much deeper in the guts of the system. There is something about how the controller is emulated by VirtualBox that Ubuntu is not fully compatible with. It could be a timing thing, or some obscure feature of a real hardware interface that is not perfectly emulated; I've looked at neither the driver code nor the emulator code, and I'm not sure I'd recognize a problem if I did. USB has the advantage that the keyboard events are in packets within a surrounding protocol that get queued rather than a fixed depth byte FIFO of key event codes that, when emulated, might suffer from race conditions or other concurrency issues.

Try this and see if it solves your issue. It has been working for me; I neither get the repeats, nor do I get the "_" in emacs when I type a space as I'm releasing the shift key.

michaln wrote: Thanks for your help so far! As you can imagine, it's very hard to fix a problem you can't see, and most users who do see the problem are unwilling to communicate beyond "it doesn't work here".

I can understand the frustration. I'm a software engineer, have been since the dark ages (1982), and have suffered from the same problem; either the user experiencing the problem can't or won't give key details that allow you to reproduce the problem, mis-characterizes the problem, or is very happy to give you the details they think matter, while omitting the details that identify the problem. Sometimes these "it doesn't work" folks are engineers.

My gut tells me that what we've been dealing with is a compatibility issue with the emulated PS2 keyboard controller. I've not done emulation of one of those.* Figuring out exactly what the incompatibility is, however, may be extremely difficult. Compare the Ubuntu driver code to another Linux distribution and see if there are any differences that might account for it. Another source of problems could be that they've got an optimization turned on (or off) when compiling the driver that is causing problems. In the old days, I'd throw an ICE on the thing with a trigger that marked the trace each time a key was pressed or released, and a "big red button" that freezes the trace (and, when possible, the guest) that the operator presses when he or she first notices the problem occurring.

Sorry that I've not provided more information on a timely basis recently, I'm sort of up against a deadline at work.

*Though I have of an 8051 connected to a DEC LK-201 keyboard, but I wrote the firmware in the 8051 on the system I was emulating, and it was nothing like the PS/2 controller uses. I used to work in the video terminals group at DEC. This emulation was a PDP-11 running on a M68000, so the instruction set of the guest was also being emulated.

Daniel.Glasser wrote:I can understand the frustration. I'm a software engineer, have been since the dark ages (1982), and have suffered from the same problem; either the user experiencing the problem can't or won't give key details that allow you to reproduce the problem, mis-characterizes the problem, or is very happy to give you the details they think matter, while omitting the details that identify the problem. Sometimes these "it doesn't work" folks are engineers.

Yes... and that's kind of sad. They should know better.

My gut tells me that what we've been dealing with is a compatibility issue with the emulated PS2 keyboard controller.

It's likely, but there is probably something else at play. The PS/2 keyboard and keyboard controller are technically relatively straightforward devices, and it is possible to emulate them very reliably. Then again, the controller is just complex enough that getting it 100% right isn't trivial.

In the old days, I'd throw an ICE on the thing with a trigger that marked the trace each time a key was pressed or released, and a "big red button" that freezes the trace (and, when possible, the guest) that the operator presses when he or she first notices the problem occurring.

We have the software equivalent of ICEs... but as you know, that's no good if you can't reproduce the problem

Sorry that I've not provided more information on a timely basis recently, I'm sort of up against a deadline at work.

In the meantime, I've been trying to reproduce the problem on my Mac but just couldn't see any problem. Just to make sure I'm looking at the right thing... which Ubuntu version (release and bitness) are you using, and what major non-default settings are you using? Things like a desktop manager. And how many VCPUs? Can you reproduce the problem in a plain terminal window when there's nothing else running in the guest? Do you have any non-standard hardware or non-default settings or software related to keyboard on the host?

Basically it seems the problem is quite easy to reproduce for you and some unknown number of others, but not nearly everyone or we would hear a lot more about it. So there's probably something the systems which exhibit the problem have in common... but what?

*Though I have of an 8051 connected to a DEC LK-201 keyboard, but I wrote the firmware in the 8051 on the system I was emulating, and it was nothing like the PS/2 controller uses. I used to work in the video terminals group at DEC. This emulation was a PDP-11 running on a M68000, so the instruction set of the guest was also being emulated.

Very cool! I'm too young for PDP-11s but am well aware that it was one of the more historically significant computer systems. Emulating it sounds like it should have been very interesting

In the meantime, I've been trying to reproduce the problem on my Mac but just couldn't see any problem. Just to make sure I'm looking at the right thing... which Ubuntu version (release and bitness) are you using, and what major non-default settings are you using? Things like a desktop manager. And how many VCPUs? Can you reproduce the problem in a plain terminal window when there's nothing else running in the guest? Do you have any non-standard hardware or non-default settings or software related to keyboard on the host?

Ubuntu Desktop 13.04 x86_64
Unity Desktop (default)
Configuration 1:
- Windows7 hosted instance package list: file attached
  
  ubuntu-package-list.txt.bz2
  
  List of optional (and standard) packages installed in "configuration 1".
  
  (187.22 KiB) Downloaded 14 times
- 2 virtual CPUs
- Host: Windows 7 Enterprise (Service Pack 1) on Intel(R) Core(TM) i5-3570 CPU @ 3.40GHz w/8.00 GB RAM, 64 bit operating system, main drive is an SSD, but the virtual file systems are on a SATA drive.
Configuration 2:
- Mac hosted instance has fewer optional packages, a subset of the above list, plus the Apache 2 http server.
- 1 virtual CPU, 3GB RAM
- Host: Mac Mini (2nd gen Intel) running Snow Leopard on Intel(R) Core2(TM) Duo, CPU w/8.00 GB RAM, 64 bit operating system.
Configuration 3:
- Windows 7 hosted instance has the same selection of packages as the Mac hosted instance.
- 2 virtual CPUs, 2GB RAM allocated
- Host: Older Core2 Quad based system, 6GB RAM, Windows 7 Professional 64 bit.
Problem is reproducible with windowed and text, though I have spent very little time in text-mode; it's not easy to get to.
I most often start seeing the problem when using emacs, but it affects the rest of the system; menus, terminal windows, dialog boxes, etc.
All 3 configurations behave in the same manner; setting them to use "usb" instead of "ps2" for the keyboard seems to avoid the problem. I've not tried setting PS2 mouse emulation.

I hope this helps you to reproduce the problem. The host OS seems to have very little influence on the behavior, and the host auto-repeat setting does not affect this problem.

I could attempt to make a stripped down VM with a small HD and see if it happens there, then send you the VM files for that. It will have to be next week, though; I'm going out of town for Thanksgiving, and I can't do that at work.

Thanks for your continued support on this.

Daniel.Glasser wrote:I hope this helps you to reproduce the problem. The host OS seems to have very little influence on the behavior, and the host auto-repeat setting does not affect this problem.

Okay, so the host OS is pretty much eliminated. I think I have finally reproduced the problem, by running 'VBoxManage controlvm XXX keyboardputscancode 02 03 04 05 84 82 83 85 06 86 07 87 08 88 09 89 0a 8a 0a 8a 09 89 08 88 07 87'. This should type '1234567899876' but in a terminal window in Ubuntu 13.04, I only get '76'. This is with just 1 VCPU, and the guest is idle. Could you please confirm that this also doesn't work right for you?

The exact same command delivers the expected results in other operating systems, including older Linuxes. In fact it also works fine in a Ubuntu VT (switching via Ctrl-Alt-F2). But when I run xev in the Ubuntu desktop, there's just the '76' and the other keystrokes just vanish.

The problem seems to be a bit more complicated than I thought... at this point I see no evidence that the Ubuntu kernel gets confused, but somehow X11 does. Some of the keystrokes simply get lost, and I strongly suspect that the trigger is pressing several keys at once and releasing them in a different order. That's something which can't really happen with USB.

We'll continue digging.

michaln wrote:I only get '76'

Just for kicks, I tried it in a couple of guests myself. Host OSX 10.6.8. Guests all with 2 VCPUs.
- Ubuntu, ScientificLinux: I get '76'.
- OSX 10.6.8, 10.7.5: I get '1'.
- Fedora, Win7, WinXP: I get '1234567899876'.
Let me know if you need more details...

socratis wrote:
michaln wrote:I only get '76'
Just for kicks, I tried it in a couple of guests myself. Host OSX 10.6.8. Guests all with 2 VCPUs.
- Ubuntu, ScientificLinux: I get '76'.
- OSX 10.6.8, 10.7.5: I get '1'.
- Fedora, Win7, WinXP: I get '1234567899876'.
Let me know if you need more details...

With OS X you're using a different keyboard emulation (USB vs. PS/2) which will behave differently as the keys are pressed and released too quickly for USB to react. Currently uninteresting

What surprises me that you're getting one kind of behavior with Scientific Linux and another with Fedora. Is it the GUI in each case, and if so, what is the GUI? I expect that in both Ubuntu and Scientific Linux, you'll get the right result in a full-screen VT (if you switch via Ctrl-Alt-F1 or so).

michaln wrote:With OS X you're using a different keyboard emulation (USB vs. PS/2)

And I would have no clue about that unless you pointed it out and "VBoxManage showvminfo <name>" confirmed it. Thanks!

michaln wrote:Is it the GUI in each case, and if so, what is the GUI? I expect that in both Ubuntu and Scientific Linux, you'll get the right result in a full-screen VT (if you switch via Ctrl-Alt-F1 or so).

ScientificLinux 6.4 (Carbon) x64, template based on RedHat-64, Gnome 2.28.2
Linux localhost.localdomain 2.6.32-358.23.2.el6.x86_64 #1 SMP Wed Oct 16 11:13:47 CDT 2013 x86_64 x86_64 x86_64 GNU/Linux

Fedora 19 x64, template based on Fedora-64, Xfce 4.10
Linux VB-Fedora.local 3.8.8-202.fc18.x86_64 #1 SMP Wed Apr 17 23:25:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Both are running the default terminal client only and that is where the input is directed (and recorded). SciLinux exhibits the unintended behavior in the terminal and in gedit.

If I switch to full screen via Alt-Ctrl-F2, both of them work as expected.

Odder and odder...

michaln wrote:I only get '76'

Ubuntu 13.04, X86_64, 2 VCPUs, 2575MB RAM
- Guest display @1175x740: "123456789876" (--keyboard ps2)
- Guest display @1175x740: "1" (--keyboard usb)
- Guest display @1527x861: "76" (--keyboard ps2)
- Guest display @1680x926: "123456789876" (--keyboard ps2)
- Guest display @1680x926: "1" (--keyboard usb)
It seems to be fairly random after re-sizing the guest display whether I get the full string or just the two characters. I've tried a lot of different combinations.
Ubuntu 13.04, X86_64, 2 VCPUs, 2575MB RAM, keyboard ps2:
- Guest display @1593x953: "76"
- Guest display @1005x630: "76"
Every other size I tried also gave me "76".
Fedora 13 x86_64, 1 VCore
- Guest display @1323x970 "76" (--keyboard ps2)
- Guest display @1170x857 "76" (--keyboard ps2)
- Guest display @1170x857 "1" (--keyboard usb)
All sizes of display seem to have the same result.

From what I can tell, using the VTs usually gives me everything for the PS2 keyboard. Not sure about the USB keyboard.
That would make your conjecture correct, that it's in something above the keyboard device driver level. When I was writing terminals firmware for a living, we implemented "n-key rollover", which allowed us to keep track of some number (n) of keys in the correct order, however modifier keys were always handled to the side of the character keys. I would suggest investigating this as a possible culprit, though the number of virtual CPUs affects the results here, which makes it less likely to be that (unless it's multithreading this aspect). Defective key order-of-operation tracking could cause lots of trouble. If the scan key codes arrive in the wrong order, this could also cause trouble. Just why the guest screen resolution affects this for the 2 core case is unclear to me.

I doubt this gives you any more information than you already have, but it's worth a try...

Thanks

No, this doesn't give me anything I didn't know, unfortunately... the behavior with the USB keyboard emulation is expected, and not really relevant here. The PS/2 behavior is what's interesting.

What I saw here is that the Linux kernel does receive all keystrokes and produces the expected results in a full-screen console/VT. In X11, keys are getting "swallowed" if more than 9 or so keystrokes are sent quickly. I don't know if that is behaving "as designed" but it's clearly something the OS is doing somewhere above the kernel level.

The problem is that I've not been able to reproduce the case where a key "hangs". So I'm not sure I'm looking at the right thing.

There are also several similar-sounding bugs opened against Linux on physical hardware: https://bugzilla.kernel.org/show_bug.cgi?id=9448 , https://bugs.launchpad.net/ubuntu/+sour ... bug/599316 , https://bugs.launchpad.net/ubuntu/+sour ... bug/124406 . There is no resolution to either of those.

At this point it increasingly looks like a bug/weirdness in Ubuntu/X11, and one that didn't use to exist several years ago (I saw different behavior with Ubuntu 8.04, as well as RHEL4 class Linuxes). We still need some reproduction scenario for the endless repeat to really pin the problem down.

FYI -- there are two relevant diagnostic tools, showkey (mentioned before) and evtest. In a VT I can clearly see that showkey sees everything I send but evtest does not. It may also be worth trying to turn off key repeat in the GUI and see how that affects the original problem (which I have yet to see).

I think that the key hangs that I'm getting are related to how I use emacs. Because the "control" key is in the wrong place on the keyboard (lower left corner instead of to the left of the "A" key, where it belongs), I tend to leave the little finger of my left hand resting on that key, and when navigating (control-f/control-b/control-u/control-n, etc.), my finger is often on then off then on then off, or just mostly on while I pivot my hand and wrist. Shift may be depressed before control is fully released (happens all the time to me), and so on. When the repeat starts, it repeats the last key pressed until another key is pressed, then it repeats that key indefinitely until it has a new key to repeat, and so on.

I have not run into this problem on Linux in the past when not hosted, but I don't have anything modern on bare metal since my primary Linux box stopped making it through post for no reason I (or a local PC repair shop) could diagnose and had to be put out of its misery. Cause of death was listed as "unspecified motherboard failure". I've been running in virtual machines on my Mac and my wife's PC ever since.

If this is, indeed, a problem with the X server, it's unlikely that Virtual Box can fix it. I'm pretty sure that Parallels is configured to provide a USB keyboard to the guest machines on my mini. I know it thinks the mouse is USB. Virtual Box claims my mouse is a USB tablet; not sure why.

It's possible that, due to the other tasks running on the host, sometimes the VM gets its key events batched together in bursts that do not occur in real-life on direct-to-metal Linux installations. Human fingers cannot move fast enough to outrun the CPU, thus this may not ever be seen on such systems. I'm in the midst of releasing a raft of firmware images to the "factory" on my current embedded project, and don't have time to experiment for the next few days, but I'll let you know if I am able to better characterize the failure.

Thanks for the continued attention to this issue.

Daniel.Glasser wrote:I think that the key hangs that I'm getting are related to how I use emacs. Because the "control" key is in the wrong place on the keyboard (lower left corner instead of to the left of the "A" key, where it belongs),

Ha. Get yourself one of those Sun UNIX keyboards... everyone I know hates those because they have Caps Lock and Control swapped

I tend to leave the little finger of my left hand resting on that key, and when navigating (control-f/control-b/control-u/control-n, etc.), my finger is often on then off then on then off, or just mostly on while I pivot my hand and wrist. Shift may be depressed before control is fully released (happens all the time to me), and so on. When the repeat starts, it repeats the last key pressed until another key is pressed, then it repeats that key indefinitely until it has a new key to repeat, and so on.

Wait. A single key press/release triggers the repeat sequence when the system is "confused"? I think I missed this part previously.

If this is, indeed, a problem with the X server, it's unlikely that Virtual Box can fix it. I'm pretty sure that Parallels is configured to provide a USB keyboard to the guest machines on my mini. I know it thinks the mouse is USB. Virtual Box claims my mouse is a USB tablet; not sure why.

VirtualBox doesn't know or care what your mouse is, or if you have one

It emulates a USB tablet (when possible) because that's an absolute pointing device and doesn't require the mouse to be "captured".

It's possible that, due to the other tasks running on the host, sometimes the VM gets its key events batched together in bursts that do not occur in real-life on direct-to-metal Linux installations. Human fingers cannot move fast enough to outrun the CPU, thus this may not ever be seen on such systems.

At this point that's my working theory as well. Actually it may be coupled with the fact that the behavior may be specific to PS/2 keyboards, which are becoming quite rare on physical hardware.

It looks like there is a relatively small buffer somewhere in Linux and it can only process a handful of keystrokes at a time. Virtualization makes it more likely that the buffer will overflow. If this is the case, it's likely that the same problem can be triggered on physical hardware, but it would require some relatively unusual conditions.

Anyway... my suspicion right now is that the problem isn't in X11 per se but rather the evdev module, or possibly some interaction between evdev and X11.

I'd like you to try two things. First, disable key repeat in the GUI. Does that affect the problem? If so, how?

Second, switch X11 to use the old input drivers (requires creating a xorg.conf). If you don't know how to do this, please let me know and I'll find out the details.

Thanks for the continued attention to this issue.

Thank you! I'm sure we'll get to the bottom of this eventually.

virtualbox.org

How to stop keys from repeating when typing

Re: Output from "info ps2k"

Re: Output from "info ps2k"

Re: How to stop keys from repeating when typing

Re: How to stop keys from repeating when typing

Re: Output from "info ps2k"

Re: Output from "info ps2k"

Re: How to stop keys from repeating when typing

Re: How to stop keys from repeating when typing

Re: How to stop keys from repeating when typing

Re: How to stop keys from repeating when typing

Re: How to stop keys from repeating when typing

Re: How to stop keys from repeating when typing

Re: How to stop keys from repeating when typing

Re: How to stop keys from repeating when typing

Re: How to stop keys from repeating when typing