Ticket #14302 (new defect)

Opened 3 years ago

Last modified 19 months ago

Keyboard Caps lock, Num lock and Scroll Lock problems with Virtualbox 5.0

Reported by: bmn Owned by:
Priority: major Component: other
Version: VirtualBox 5.0.0 Keywords: Keyboard
Cc: Guest type: Windows
Host type: Windows


Steps to reproduce the problem: 1) With no virtual machines running, activate Caps lock and/or Num lock and/or Scroll lock. 2) Start a virtual machines from saved state. 3) When I reduce the window of the virtual machine or I close it (by saving the state or by shut down the system) the state of Caps lock, Num lock and Scroll lock are deactivated.

Host: Windows 7 x64 Guest tested: Windows Xp SP3: Windows 7 x64 SP1; Windows 8.1 x64


VBox.log Download (92.3 KB) - added by mhanor 3 years ago.
VM start loop.bat Download (384 bytes) - added by mhanor 3 years ago.
VBox.log.1 Download (125.3 KB) - added by mhanor 2 years ago.
see comment 29

Change History

comment:1 Changed 3 years ago by mhanor

I have the same problem. I can reproduce the issue with bmn's test case. I saw there was a problem regarding the keyboard LEDs state since the beta/rc phase, but I didn't know how to trigger it.

Changed 3 years ago by mhanor

comment:2 Changed 3 years ago by msq

Same here. Seems like after migration to 5.0 NumLock on all virtual machines is turned off by default. Having NL enabled on host - whenever I switch focus to vm window - NumLock is going off. You can get NL enabled for each machine - just boot vm, focus on vm window and turn on NumLock. It should come back as on after reboot, but that is not always the case.

Apart from that even when you manage to enable NL for particular vm - it is going on and off during booting stage.

comment:3 Changed 3 years ago by mhanor

There is a related issue. If VirtualBox is launched in the background, it still alters the host keyboard state. You can test it by continuously typing in a host text editor and running a script for delay launching the VM, see the attached example. Tested with VirtualBox 5.0.1-101908.

Last edited 3 years ago by mhanor (previous) (diff)

Changed 3 years ago by mhanor

comment:4 Changed 3 years ago by VVP

fixed in SVN.

comment:5 Changed 2 years ago by frank

Please could you confirm that the latest 5.0.x Windows test build fixes the problem? Thank you!

comment:6 Changed 2 years ago by mhanor

I'm not sure, but I think bmn's issue is solved.
I have managed to reproduce my issue. I'm using Windows 8.1 x64 and VirtualBox-5.0.3-102322. Open a Command Prompt window and one VM. Assuming you have at least one different key state (e.g. Num Lock is 'on' on the host, but it's off in the guest). Bring the Command Prompt window into foreground, making it active, while keeping the VM's window in the background, but with the maximize/minimize/close buttons (from the title bar) accessible. With the Command Prompt window active, click the minimize button of the VM window. It's done. Now, the host has the Num Lock/Caps Lock/Scroll Lock state of the guest.
Also, what I have described in comment 3 is still true.

Last edited 2 years ago by mhanor (previous) (diff)

comment:7 Changed 2 years ago by frank

The fix is part of VBox 5.0.4.

comment:8 Changed 2 years ago by mhanor

I can still reproduce the issue I've described in comment 6, using VirtualBox 5.0.4

Last edited 2 years ago by mhanor (previous) (diff)

comment:9 Changed 2 years ago by mmcknc

I'm still having the trouble in 5.0.4 as well.

I have Win7 set where window-focus follows the mouse... as I mouse over various VM windows, the num-lock light changes depending on the state within a given machine. This pretty annoying, especially when I leave a machine with num-lock ON and go back to the win7 host and it's somehow been turned OFF... and I'm trying to type in numbers not even realizing the state of they keypad has changed.

comment:10 Changed 2 years ago by fade2gray


Switching focus from guest vm to the manager via Windows 7 taskbar causes guest to abort (related to Num Lock status) - see

Last edited 2 years ago by fade2gray (previous) (diff)

comment:11 Changed 2 years ago by Suncatcher

I use the latest 5.0.12 version and still experience this bug. Moreover, I can add that state of Numlock is deactivated not only after minimizing VM window, but also after restoring it.

comment:12 Changed 2 years ago by Suncatcher

In the 5.014 the bug haven't disappeared. Is it so complicated to fix it?

comment:13 Changed 2 years ago by michael

I will give you two answers to that.

The first is that fixing even the most trivial of bugs requires about half a day of developer time, by the time you have counted the time switching away from the current task (there is always a current task), bringing the affected code area back to mind, thinking the problem through (is it really as trivial as it looks? Might fixing it affect other things? Fixing things quickly without thinking is almost always a recipe for trouble later), testing the fix (you would be surprised at how even the simplest of fixes can go wrong), communicating with the reporter, providing them with a build to test. Multiply that with 3000 open bug reports and assume that most of them are not trivial - even if all of them were, that would be over ten developer working years. Yes, I know that there are duplicates and what not, but you get the idea.

The second is that interacting with host keyboard LEDs (we are talking about host LEDs here, aren't we? Or did I misread something badly?) is much more tricky than it might seem. They are a resource shared between all processes on the system, one which user processes rarely touch explicitly (therefore interaction with them is not well documented or tested, including by operating system vendors) and work differently on every host operating system.

In fact this is the sort of thing which, unless it clearly disturbs (not just affects) a large number of users, we tend to leave to users with programming skills to fix.

Last edited 2 years ago by michael (previous) (diff)

comment:14 Changed 2 years ago by Suncatcher_13

I admit that fixing one bug can cause another and this doing this smoothly is quite painstaking, but I disagree that this bug is minor.

Permanent on/off on Num Lock causes impossibility to use Numpad at all and I think that this affects most of the users. So this problem is critical!

Last edited 2 years ago by Suncatcher_13 (previous) (diff)

comment:15 Changed 2 years ago by michael

I understand that unfortunately for you, and probably for a few other users, it has a very high priority. Once again, many of the open bug tickets have a very high priority for a number of users. Nonetheless we cannot drop other things to fix these issues, and have to concentrate our limited resources on issues which we judge to be high priority, often because they are directly related to our revenue stream. (I realise you could say that this issue could potentially affect it too if it annoys enough people, but we have enough tasks which are clearly, not potentially related.)

However, if you consider the issue important enough, since the source code is available you might want to look for other people who would be able to fix it. If I have really misjudged the importance then there might well be people affected with programming skills who would be willing to take a look.

comment:16 Changed 2 years ago by mhanor

Though the manual says it's disabled by default, on Windows the HidLedsSync feature is enabled by default (global settings). When minimizing the VirtualBox window while another window is in the foreground, UIMachineLogic::sltSwitchKeyboardLedsToPreviousLeds gets called first (when the WM_ACTIVATEAPP event is processed), but due to a WM_ACTIVATE event, a timer (100ms) gets created and eventually calls UIMachineLogic::sltSwitchKeyboardLedsToGuestLeds. That is what happens, but I don't know what would be a correct fix for this behavior.

comment:17 Changed 2 years ago by Suncatcher_13

I understand you have more urgent bugs, and that's not the problem.

My embarrassment is inspired by those fact that this bug was claimed to be fixed yet in 5.02, but in fact it isn't fixed even now. Just post some bugfixing roadmap which would contain order of priority and from what we would know that in version 5.0.16 (or 5.0.20, or whatever) we can expect fix of this bug.

It would be fair.

Last edited 2 years ago by Suncatcher_13 (previous) (diff)

comment:18 Changed 2 years ago by VVP

Here, there are different issues described in the comments. Would you specify which of them still exist? and separate them from each other.

comment:19 Changed 2 years ago by mhanor

Issue 1: a VM that starts in the background, affects the host LEDs state, even if the VM window is in the background, while a host application window is in foreground and it has continuous keyboard input. See comment 3

Issue 2: minimizing a VM window while it's in the background and another host app window is in foreground, leads to guest LEDs state enforcing. To work around this, make the VM window active then select another host window or minimize the VM window while it's in the foreground. See comments 6 and 16

Both issues are present on a Windows host, while the HidLedsSync feature is enabled (it's enabled by default, set by global settings).

Last edited 2 years ago by mhanor (previous) (diff)

comment:20 Changed 2 years ago by VVP

mhanor, please, use this build with a fix for the second issue from the previous comment try it.

comment:21 Changed 2 years ago by mhanor

I can't reproduce the 2nd issue with the new build.

comment:22 Changed 2 years ago by VVP

thanks for testing and confirmation. So, now only one issue still exists, doesn't it?

comment:23 Changed 2 years ago by mhanor

Only one that I know of, yes.

comment:24 Changed 2 years ago by Suncatcher_13

minimizing a VM window while it's in the background

Does background here mean headless mode? Or just minimizing? Though I cannot imagine how the window can be minimized while it is already minimized.

Or it is just background/foreground property of Windows' windows? Could you clarify your wordings, please? I also want to test the new build.

Last edited 2 years ago by Suncatcher_13 (previous) (diff)

comment:25 Changed 2 years ago by mhanor

When I say foreground window, I mean the active window that is capable of and even receiving input (keyboard/mouse) from the user. It's the window that the user is working with. A background window and a minimized window are different things. A background window is not active and it doesn't receive direct user input unless it's made active. It's visible if it's not behind other windows.

Last edited 2 years ago by mhanor (previous) (diff)

comment:26 Changed 2 years ago by Suncatcher_13

Ok, got it. All the written below is true for both cases, either for background windowed VM or fullscreen.

I tested the above fix and can say that the problem was solved partly and now LED enforcement doesn't take place after booting of guest OS. But!

These 2 issues are still present before booting, during shutdown and all intermediate events throughout the reboot: logon screen, POST (Power-On-Self-Test), Bootscreen, etc. The bug is gone only for booted OS.

comment:27 Changed 2 years ago by snoopy78

I have the same behavior with a Win7 Laptop running Suse Linux. After every boot or something like described above, I have to hit the Numlock key. If I don't do it and switch to fast, the virtual machine crashes. Isn't it possible to set the key in the vbox settings?

comment:28 Changed 2 years ago by frank

The mentioned fixes are part of VBox 5.0.16. Could someone list the remaining issues here?

comment:29 Changed 2 years ago by mhanor

The remaining issues are:

Issue 1: a VM that starts in the background, affects the host LEDs state, even if the VM starts in the background (it must have something to do with the hardening process, the VM window never gets created in focus), while another host application window is in focus and it has continuous user keyboard input. See comment 3. Assuming the host has the NumLock key toggled on, test the issue by continuously pressing a keyboard keypad key in the host's text editor (e.g. pressing keypad key '4'), while the VM start.bat script starts and closes the VM in the background (assuming the VM starts with NumLock toggled off).

Issue 2: If the Windows host is put to sleep (S3) while a VM is running, if this VM's window was the the last window that was active (in focus), after resuming the host, the host key state is set to the last guest's key state. Example (see the attached Vbox.log, it contains extra logging for the GUI group), where the host had only NumLock toggled on and the guest had only ScrollLock toggled on. There are events (setfocus and killfocus) that the VM window gets right before the host enters sleep or right after it resumes.

Issue 3: this might be intentional, but a VM with nothing to boot (displaying the "FATAL: no bootable medium found! System halted") forgets the guest key state when the window looses then regains focus. I think this is what Suncatcher_13 referred to in comment 26 issue 2. Maybe the VM should also check if the VM is halted (or in some uncertain/unusable state), not to switch the key state.

Last edited 2 years ago by mhanor (previous) (diff)

Changed 2 years ago by mhanor

see comment 29

comment:30 Changed 2 years ago by ausername

workaround (doesn't work if you use groups)

(isn't it possible here to watch/subscribe?)

comment:31 Changed 2 years ago by Suncatcher_13

Well, I don't really use VM in background like mhanor, but I assume VBox behavior in background don't differ form the one in foreground. And that's what I see:

  • the Numlock state is the same on all the stages of OS boot process (POST, bootscreen, logon screen) and that's consistent. That's like how it is supposed to be.
  • switching to Guest OS changes Numlock state to "Disabled", whereas switching back to main OS enables it again.

This behavior is quite reasonable and fully satisfies me.

Several other points:

  1. Can I change default LED state for guest OS? Now it is always disabled.
  2. Why to change LED state between guest and host at all?

comment:32 Changed 19 months ago by operator error

I've read the other comments, and maybe this is out of place, but here is my main issue:

  • my ubuntu VM boots an encrypted disk
  • encryption password starts with numbers
  • hitting keys on num pad (with num pad off by default) causes VM screen to disappear

This becomes a big issue for me because I regularly boot this VM from different snapshots to test solutions for customers. Every day, multiple times per day, I make this mistake (not turn the Num Lock on) and I have to reboot my VM for it.

I don't care much for num lock LEDs, (don't have one on my laptop) just looking to turn NUM LOCK to on by default.

On physical systems I know this as a common option in the BIOS/UEFI.

Since VirtualBox technically acts as a BIOS/UEFI, just wondering if there's a common option for it before I go submitting (contributing to) tickets?

comment:33 Changed 19 months ago by Suncatcher_13

Your question exactly corresponds to my first question, so this is not out of place.

I don't care much for num lock LEDs, (don't have one on my laptop) just looking to turn NUM LOCK to on by default.

If you don't have physical LEDs it doesn't mean you have no ones:)

Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use