VirtualBox-5.2-5.2.10_122088 Keyboard problems

[Foxdoismil]

I updated VirtualBox to version 5.2.10 direct from the VirtualBox Fedora repository and immediately experienced the following problems with the Keyboard (and mouse):

Host: Fedora27 on a notebook and on a desktop, both running on Intel i7 with 8G or 16G RAM.

Guest: Windows XP, Windows 7 as well as Fedora 24

The bug is easily seen using Notepad-plus-plus.org on Windows and Kate on Linux guests. It can also be seen with Libreoffice and possibly with any other text processing interface/editor. It took more time to see the bug in Libreoffice, so I suggest you try with notepad-plus-plus

How to reproduce: On Windows XP and 7 the keyboard properties (Control Panel => Keyboard, select "Speed" tab) is set to the "lowest repetition interval" and "Fastest repetition rate".

Open any long enough plain text document (some 2 to 4 pages should be enough) position the cursor anywhere and finally press and hold the up or down arrow in order for the cursor to quickly move downwards or upwards.

The cursor initially goes fast (almost as it used to be on 5.2.8) and than if freezes, then sometimes it continues after a small pause, sometimes you have to release the arrow key and press(&hold) again. The cursor moves fast again and stops every few random lines. At random it starts to select the lines as if you were holding the shift key +up or+down arrow key. Clicking anywhere up and down with the mouse still shows select mode active. It will not cancel the selection state unless you press the Shift key once.

IMHO it is a bug introduced when it was tried a quick fix for this bug: https://www.virtualbox.org/ticket/17592

Maybe it would be better to revert that commit while studding a better solution for that bug.

This bug rendered VirtualBox 5.2.10 useless to me and I am forced back to 5.2.8

[michaln]

Please provide a VBox.log from affected VM.

Please specify which arrow key you're holding (the arrow one in the numeric block or the separate 'gray' arrow?) and what the state of Num Lock is. It probably makes a difference.

[Foxdoismil]

In all the machines we had problems, the Host was a KDE Fedora and the Num Lock was ON. Also in the Windows and Linux guests, Num Lock was ON.

However, I was using the separate up/down/left/right arrow keys as well as Page Up and Page Down keys. Not the ones in numeric pad.

As for the log, I will have to update VirtualBox to 5.2.10 again in order to answer. Is there any particular log lines you are interested in?

[michaln]

I need the entire VBox.log to see the exact host system and VM configuration (one log should be enough). The problem probably happens because the host and/or VM is overloaded. I cannot reproduce it so I need more data.

I suspect the problem is actually old and maybe 5.2.10 makes it more likely to occur.

[bugs_claudio]

As the original poster has not yet uploaded a log file, I attached mine.

As you say, it looks like the VM overloading, CPU more specifically. The host has enough resources for this not to happen (as it did not happen in the past). I could work around the problem by assigning an extra core (1 -> 2) to the VM. Moving the cursor with the arrows in MS Word is still somewhat sluggish, but the behaviour the original poster described does not arise then.

Setup:

• Host: Ubuntu 18.04 am64 (Intel(R) Core(TM) i7-4510U CPU @ 2.00GHz (4 cores), 16GB RAM, SSD disk). Running under Wayland, not Xorg. On this Optimus-video laptop (nvidia/intel) I have very good video performance with Wayland with nouveau, terrible performance with all other combinations (including Xorg) since Ubuntu 17.10).
• Guest: Windows 7 Ultimate 32-bit (1 or 2 cores, 4gb ram). Running the latest VBox expansion pack and guest additions (upgraded to 5.12 with same results).

Feel free to contact me if more tests are needed.

C.

[michaln]

The keyboard trouble is almost guaranteed to be caused by an overloaded VM (not being able to process the keyboard input fast enough). That is a problem which can not be generally solved (you can always throw more at the host than it can handle), but should not cause trouble in typical usage. Question is, why is the VM overloaded?

Can you tell where the CPU cycles are going? Is the guest OS itself busy? (That is, is Task Manager within the VM showing high CPU utilization?) Or is the guest OS relatively lightly loaded but the VM process is busy? Does it have something to do with graphics updates?

I have not been able to reproduce anything similar, but I'm not running the latest-and-brokenest Linux stuff on the host side.

BTW do you know why your VM keeps re-doing DHCP all the time (about every 6 minutes)?

You could try the latest development snapshot from https://www.virtualbox.org/wiki/Testbuilds -- it contains slight tweaks to the keyboard behavior. Among other things, it should complain in VBox.log if the internal keyboard queue overflows.

[pw2]

I was referred here from: https://www.virtualbox.org/ticket/17779 (I do have additional details there, though it may be related to this 17709 ticket)

In my case, the guest OS is not overloaded at the time of the problem (I built my XP and Windows 7 machines to be as 'quiet' as possible, not running search-indexing services, etc. I can see this problem with a host machine at ~10% processor usage and guest machine at less than 5% CPU usage. It is a fairly new Virtualbox bug as I can rollback to Virtualbox 5.2.2 and not see the problem. I tested this on a ~2013 i5 with 16GB and SSD and also on a ~2015 i5 with 16GB and SSD.

I can demo the problem by holding down the left arrow key in Notepad on the 2013 machine and the problem will appear every ~30 characters or so. The 2015 machine is harder to replicate the issue, but usually after holding down the left-arrow key through a couple hundred characters in Notepad will get it done.

If I repeat this a few times, the keyboard will get into an unusable state as it will think a shift key or control key is held down. Only recovery method is to shutdown and restart the guest machine.

[michaln]

VBox.log or it didn't happen...

If a "stuck" Shift or Ctrl key can't be "unstuck" by pressing and releasing same, you probably have a different problem.

[F]

I can confirm the problem running both Win 8.1 and Win 7 on a Fedora 28 host using an updates VirtualBox 5.2.

After some time of use, the guest(s) behave as if the SHIFT key would be pressed permanently - I haven't figured out how to "release" the key again.

(It's certainly not a hardware issue, since the host os doesn't experience the problem).

I also experience a high CPU load, without any obvious reason (the guests are up-to-date, no Windows update system working hard in the background).

[michaln]

Once again, VBox.log or it didn't happen.

The "high CPU load" is almost certainly triggering the misbehavior. To be clear, we can't tell you what's causing the high load, you have to tell us because you have the system you can analyze. It does not have to be the guest being overloaded.

There are changes in the current development snapshot (from https://www.virtualbox.org/wiki/Testbuilds ) that may or may not help. The changes will not be backported into any 5.2.x release until someone confirms that they make a difference.

No one here can reproduce the problem so all we can do is guess. It might take a long time to guess the correct answer, or it might never happen. If users can't even bother to provide a VBox.log, that's a clear indication to us that users don't care to have this resolved.

[pw2]

I added 2 attachments I tested with version 5.2.13 and the issue still remains. When testing on 5.2.8, the problem is not present. I did also test with 5.2.10 and 5.2.12 and these have the problem. In this case, I tested on a 3rd computer: (Dell 3020m-micro, 16GB, normal hard-drive), though I was loading the little Windows-XP disk image into Ubuntu-16.04 ram-disk. The error was also possible to demonstrate in Windows 7 VM with its disk-image on the host's SSD (on the 2013 computer I mentioned above) -- all 3 computers are Dell computers -- hopefully the attached log files (esp. the 5.2.13 file) will help, but if needed, I can also video record the issue so you can see it happen. Thanks for looking into this.

[michaln]

Sorry, I probably wasn't clear enough. The results with 5.2.13 are expected to be identical to 5.2.10/5.2.12 because there are no changes, so that doesn't really help. What I need is a log from a development snapshot, it will be version 5.2.97. I can see how the versioning can be confusing.

The systems are all running more or less very similar Linux kernels? Do you happen to have any non-Linux systems at your disposal?

[pw2]

Version 5.2.97 is much better -- I attached a logfile. It's not perfect, but it is usable for what I use the VMs for (software development and text editors). I was not able to get it in an unusable state (the shift keys and control keys no longer get stuck when holding down an arrow-key)

it never started selecting text when only the left arrow-key is held down for a long time (version 5.2.10 --> 5.2.13 -- had this problem) -- this is great news!

It does start slowing-down/getting-jammed-up a little (with similar character traversal counts as what the bad versions get) when the arrow key is held down, but it works through it, tries to catch up and thankfully doesn't get into an unusable state

I do have some Windows systems and I have a 2012 Mac mini. I'll try rerunning these tests on those systems as time allows (within a week)

[michaln]

Thanks. This explains one part of the problem. The updated keyboard code is careful about either queuing up a complete keystroke sequence (which may consist of up to 6 bytes for the gray cursor keys, depending on Num Lock and Shift state) or dropping the entire sequence. The old code could end up queuing partial sequences which clearly confused the guest OS in some situations.

The mystery is why your system can't keep up. Something is much slower than it ought to be, and it is probably host OS/hardware/configuration specific.

[michaln]

Actually it turns out that something is much faster than it ought to be. On Linux/X11 hosts, we get very different key repeat behavior, which looks like the user is pressing and releasing the key very fast. The default repeat rate is fairly fast, and what's much worse, it ends up generating much more data (because instead of just sending key presses, it sends key presses and releases). That is why the problem reported in this ticket appears to be specific to Linux hosts.

We used to have a fix for this (ignoring the simulated key release events) but it inadvertently got lost a while ago.

[bugs_claudio]

@michaln,

I forgot I didn't configure this tracker to send me mails. It looks like you pinpointed the error. Do you still need someone to test the testbuild?

[bugs_claudio]

Replying to michaln:

Can you tell where the CPU cycles are going? Is the guest OS itself busy? (That is, is Task Manager within the VM showing high CPU utilization?) Or is the guest OS relatively lightly loaded but the VM process is busy? Does it have something to do with graphics updates?

I encounter the problem with MS Word on Windows 7 x86, but I also can reproduce when only notepad is running. Services like updates are set to manually. Nothing else is running and CPU is almost zero, until the problem arises and the CPU peaks.

BTW do you know why your VM keeps re-doing DHCP all the time (about every 6 minutes)?

This setup is rather simple. VirtualBox is set to NAT, the Win7 VM has its out-of-the-box dhcp config. I can not explain why this happens. The host has a stable connection and refreshes its dhcp lease every 4,5 hours.

If this is a problem, I can open an ticket for it.

[pw2]

Replying to michaln:

We used to have a fix for this (ignoring the simulated key release events) but it inadvertently got lost a while ago.

Do you know what change in 5.2.10 made these two issues become visible? (If it's the new keyboard delay for the Pascal software, would it be possible to make that delay value a parameter in VBoxManage (or in the GUI), with the default being "0"? -- I've been using VirtualBox for years and prior to 5.2.10, the VM-USB keyboard worked just as good as a normal OS (non-VM) -- I can help test if you are interested in finding out which change in 5.2.10 made the two issues visible, though it looks like you also have a path forward too (I'd be happy to help test the [ignoring the simulated key release events] code if it can be re-added)

Thanks!

[bugs_claudio]

Replying to pw2:

Replying to michaln:

We used to have a fix for this (ignoring the simulated key release events) but it inadvertently got lost a while ago.

Do you know what change in 5.2.10 made these two issues become visible? (If it's the new keyboard delay for the Pascal software, would it be possible to make that delay value a parameter in VBoxManage (or in the GUI), with the default being "0"? -- I've been using VirtualBox for years and prior to 5.2.10, the VM-USB keyboard worked just as good as a normal OS (non-VM) -- I can help test if you are interested in finding out which change in 5.2.10 made the two issues visible, though it looks like you also have a path forward too (I'd be happy to help test the [ignoring the simulated key release events] code if it can be re-added)

Thanks!

It looks like the ticket in question is this one: https://www.virtualbox.org/ticket/17592 It seems like a very niche usage.

C.

[michaln]

pw2: I'll try to summarize the problems. It's a bit complicated.

1) The PS/2 keyboard emulation was not careful about queuing up either a complete keystroke scan code sequence or nothing. Been there since day one or so, problem only shows up if the internal queue overflows.

2) After a rewrite to support Qt5, the VirtualBox X11 GUI lost the ability to distinguish between key repeat caused by keys held down and keys repeatedly pressed and released. This was a then-unnoticed, or at least not understood, VirtualBox 5.1.0 regression (again X11 only). This at least doubles the amount of data queued up when a key is held down, and possibly much more if the host key repeat is fast.

3) A change in VirtualBox 5.2.10 to better emulate PS/2 keyboard behavior, slowing it down slightly, exposed problem 1) on systems also affected by problem 2) by making it more likely to overflow the scan code queue.

Problems 1) and 2) are now fixed in the 5.2 branch (and trunk). The delay introduced as part of fix for problem 3) can be turned off by setting the VBoxInternal/Devices/pckbd/0/Config/KbdThrottleEnabled extradata key to 0.

Please do try the current 5.2.x test builds (revision 122890 or later), these include fixes for problems 1) and 2).

[bugs_claudio]

Replying to michaln:

Problems 1) and 2) are now fixed in the 5.2 branch (and trunk). The delay introduced as part of fix for problem 3) can be turned off by setting the VBoxInternal/Devices/pckbd/0/Config/KbdThrottleEnabled extradata key to 0.

Please do try the current 5.2.x test builds (revision 122890 or later), these include fixes for problems 1) and 2).

Hi michaln,

I just installed the test release:

• VirtualBox-5.2.13-122890-Linux_amd64.run
• Oracle_VM_VirtualBox_Extension_Pack-5.2.13-122881.vbox-extpack
• VBoxGuestAdditions_5.2.13-122825.iso

I will test it longer (by working on a longer period on the VM), but so far it looks like a night and day difference:

• I no longer get the described stuck shift-mode.
• Moving the cursor with the arrows in MS Word is fast.
• No high cpu load. The released Virtualbox consistently used 60% of a cpu on an idle 100-page Word document. This is not longer the case. Idle means idle cpu now.

Thank you for the fix, it's very much appreciated.

C.

[michaln]

Thanks for the report! The previously high CPU load now dropping is unexpected. I wonder if Word may have been a victim of problem 2) I described above, and the very fast simulated key presses and releases triggered something.

[pw2]

It looks great! (I'll continue testing and comparing the timing consistency of key repeats in various VirtualBox versions and various guest OSs) -- in general it looks great and for the work I do in VMs, it's perfect and complete. Thanks!

[michaln]

Thanks for the report. There will be further minor changes in the keyboard handling but probably not something you'd notice, just oddities noticed during testing that no one really complained about.

[VirtualboxUser]

Running, virtualbox 5.2.18-dfsg-2, an issue with stuck mouse exist in Windows 7 guest, sometimes keys are stuck when typing, the same key gets repeated many times, also windows and ctrl keys are not passed to the guest. Stuck mouse issue: Sometimes the mouse is stuck so you cannot click anywhere in the machine even on the buttons in shutdown VM dialog, these buttons are clickable only when clicking on the Virtualbox main window interface, then the VM can be saved and loaded again, so the issue is mitigated until the next time. Sometimes the mouse is stuck when pressing the minimize button, then the minimize button is kept pressed, the only workaround is to save and reload the VM.

[Socratis]

@VirtualboxUser

• This ticket is about the keyboard, not the mouse.
• This ticket is about X11 hosts, not OSX hosts.

Please don't (re)open tickets just because they might sound similar...

It's usually better and faster, if issues get first addressed in the ​VirtualBox forums, a lot more eyes there. So, if you can, please open a new thread in the ​Windows Guests section of the forums.