Check handling for keyboard catching

[Markus Elfring]

I look at the guest "Knoppix 5.3.1" from a KDE 3.5.10 session on my openSUSE 11.1 system.

I have noticed that the keys for switching of virtual terminals (Ctrl+Alt+F1 ...) are still directed to the host desktop while the guest should get keyboard input (as indicated by the green symbol in the status bar on the bottom).

I am using the keyboard "Logitech Cordless Desktop MX3000". It has got a special wheel on the top to adjust the sound volume. If I turn it a bit, a corresponding change is displayed by the KMix applet on the host screen. The virtual Knoppix machine does not react to presses of the host key (right Ctrl) any more after the little volume control window vanishes. The virtual test machine does also not process usual keyboard input while the caught mouse pointer is still working. I can shutdown the Knoppix display (driven by the virtual box version 2.1.2-4.3) by mouse clicks to get mouse control back to the host after a while.

The keyboard is still stuck on the host. I wonder why this happens.

I need to logout and login again to get back to normal input handling with usual responsiveness.

[Michael Thayer]

The first issue is unavoidable, since X.Org does not allow an application to capture Ctrl-Alt-Fx (and the VirtualBox GUI is just an X11 application from this point of view). I was not able to reproduce the second issue using the multimedia keys on my USB keyboard.

[Markus Elfring]

Is my volume wheel handled differently in comparison to your multimedia keys?

[Michael Thayer]

Probably not, but I still can't reproduce it.

[Markus Elfring]

I imagine that a relevant difference is which software component will react to turning of a volume wheel instead of similar multimedia keys. Does a corresponding control like a pop-up window from the KMix applet appear in your desktop environement?

Do we need to dig further into the details of keycodes handling?

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.