First letter after Caps Lock engaged not capitalized

[rsparapa@…]

This has been bugging me for about a year. Every release of VirtualBox that I have tried has had the same problem. When I press Caps Lock the first letter that I type is not capitalized. I've gotten used to turning on Caps Lock "early" so that I can type a space prior to the capitalization. But, some times a space is not needed or I forget.

[Michael Thayer]

Could you please attach a log from a VM session? I assume that you don't see similar issues on your host? And has this ever worked in VirtualBox?

[rsparapa@…]

It has never worked in VirtualBox (never is relative, I've only been using it for about a year). I do not see similar issues on the host.

[Michael Thayer]

Interesting, what you attached is a debug log, which a release version of VirtualBox should not produce. Is it from the test build which I attached to the other ticket? (That build should of course not produce a debug log either...) And could you attach a release log? You can access it through the "Machine" menu in the Machine Selector window. Thanks.

[rsparapa@…]

No, that was from last Monday and I didn't get the test build until yesterday.

[rsparapa@…]

Can you give me an update?

[Michael Thayer]

I assume that there is no difference with VirtualBox 3.0.8. Is the message at the beginning of the release log ("Failed to recognize the keyboard mapping or to guess it based on the keyboard layout") still the same in 3.0.8? Out of interest, what sort of keyboard and keyboard layout are you using?

[Michael Thayer]

Ah, I see you gave details in #5050.

[rsparapa@…]

The "Failed to recognize the keyboard mapping" message AND the bug are still present in 3.0.8.

[Michael Thayer]

Sorry if this sounds like I am making wild guesses (I am...), but could you try starting the xev client on the host, giving it the focus, then pressing and releasing CAPS_LOCK once to enable caps lock, pressing and releasing a single alphabetic key and finally pressing and releasing CAPS_LOCK once more to release caps lock? And then attaching the event log with the output from xev (you can remove the events which are not relevant of course). Thanks.

[rsparapa@…]

KeyPress event, serial 26, synthetic NO, window 0x980001,

root 0x30, subw 0x0, time 1399236073, (40,73), root:(1578,169), state 0x0, keycode 64 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 characters: ""

KeyPress event, serial 26, synthetic NO, window 0x980001,

root 0x30, subw 0x0, time 1399244697, (40,73), root:(1578,169), state 0x2, keycode 11 (keysym 0x41, A), same_screen YES, XLookupString gives 1 characters: "A"

KeyRelease event, serial 26, synthetic NO, window 0x980001,

root 0x30, subw 0x0, time 1399244809, (40,73), root:(1578,169), state 0x2, keycode 11 (keysym 0x41, A), same_screen YES, XLookupString gives 1 characters: "A"

KeyRelease event, serial 26, synthetic NO, window 0x980001,

root 0x30, subw 0x0, time 1399247992, (40,73), root:(1578,169), state 0x2, keycode 64 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 characters: ""

[Michael Thayer]

Is that really what you get? It looks like you held down caps lock while you were pressing the "A" key and only let go of caps lock after you had pressed "A"...

[rsparapa@…]

That's really what I get.

[Michael Thayer]

And if you just press-and-release caps lock and then press-and-release "A"? Without disabling caps lock again after that?

[rsparapa@…]

KeyPress event, serial 26, synthetic NO, window 0x980001,

root 0x30, subw 0x0, time 1402136963, (95,74), root:(1633,170), state 0x0, keycode 64 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 characters: ""

KeyPress event, serial 26, synthetic NO, window 0x980001,

root 0x30, subw 0x0, time 1402139243, (95,74), root:(1633,170), state 0x2, keycode 11 (keysym 0x41, A), same_screen YES, XLookupString gives 1 characters: "A"

KeyRelease event, serial 26, synthetic NO, window 0x980001,

root 0x30, subw 0x0, time 1402139362, (95,74), root:(1633,170), state 0x2, keycode 11 (keysym 0x41, A), same_screen YES, XLookupString gives 1 characters: "A"

[Michael Thayer]

OK, so your host is not sending a key release event when you press caps lock, but it is updating the key state. My guess is that Windows is not enabling caps lock until it gets the key release, but that VirtualBox is noticing slightly later that the key state has changed and simulating the key release event. Not sure if this is standard Solaris behaviour though.

[rsparapa@…]

Hi Michael:

I'm running: Solaris 10 11/06 s10x_u3wos_10 X86 Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 14 November 2006

Not sure how you can get more "standard Solaris" than that :o) Do you have a specific bug/patch in mind? We're pretty up-to-date. We are going to be completely up-to-date tonight.

[Michael Thayer]

The only S10 system I could get my hands on immediately did send key release events for the caps lock key. Not a very representative system though, as it was one I logged into via a remote administration console. Do you have "physical rights" to the machine you are using? I would be very interested to know whether you get similar results if you booted a Ubuntu live CD on it and ran xev from that.

[rsparapa@…]

It is a Thumper server that's in a rack that has only terminal access. No video card, no CD/DVD ROM, not a single luxury.

[Michael Thayer]

In any case, your system (this may be something to do with the SunRay, I don't know much about them) is not generating keyboard events correctly in the X server. The fact that caps lock is being enabled at all is due to a hack inside VBox, which sends additional key events when it notices that the caps lock state on the host and the caps lock led on the guest are out of sync (which apparently happens after you have pressed a key after enabling caps lock). I don't know if we can do much here though, as we rely on getting the right keyboard events from the host, which we are not in your case.

[rsparapa@…]

Wait a minute. But, every other application that I use behaves as I would expect after pressing Caps Lock!?!

[Michael Thayer]

Most applications do not check caps lock key press and release events - instead they check the X server's caps lock state. Obviously a guest system in a virtual machine can't do this though (it is not aware that it is running inside an application connected to an X server), and relies on those key events instead. You would probably see something similar if you ran a different virtualisation product, or something else that relayed key event information (really relayed that is - many VNC/RDP-type systems do half working hacks instead, which you notice as soon as you try to use them with a non-US keyboard).

[Michael Thayer]

Just to clarify - your system correctly maintains the X server's caps lock state, but it doesn't send those events correctly - from the key events it sends, it looks to "anyone" watching as though the caps lock key was held down from the time when you enable caps lock until the time when you actually disable it. Without our hack which checks the server caps lock state, a Windows guest would ignore the first press of the caps lock key (when you enable caps lock) and enable caps lock when you pressed the key a second time to disable it on the host.

[rsparapa@…]

So, should I contact Sun? I have a support contract.

[Michael Thayer]

You could do that - since no one else has ever reported this, I would guess that it is some configuration issue. I can ask someone who knows a bit more about SunRays tomorrow if they know anything too.

[Michael Thayer]

The event reporting you posted above is reproducible on a SunRay here (connected to a Sparc server). I don't think that this is correct, so you might really want to take it up via your support contract.

[Michael Thayer]

rsparapa: I have been following this up further (also in relation to a similar issue on Windows hosts). It seems by the way that the keyboard events sent by the SunRay may be correct for legacy X servers. Would you be able to do similar testing with xev inside a Linux or Solaris guest? If you need a quick and dirty one, you can download the DSL ("Damn Small Linux") live CD, which is only about 50MB, boots fast and doesn't need to be installed. I would be interested to see events the guest receives when you enable CapsLock there and then press two alphabetical keys (so that the first one is lowercase due to the problem you are seeing, and the second uppercase). Thanks.

[rsparapa@…]

I have Ubuntu installed just for testing. I can't figure out how to get the copy and paste to work, but I see the same thing. Ubuntu xev shows a KeyPress event for CapsLock, but there is no KeyRelease event until you do a second CapsLock to toggle it off. Of course, this is still all on a SunRay.

[Michael Thayer]

I think you may have misunderstood me - I meant an X11 *guest* running under VirtualBox in the same configuration as the problem Windows guest was. I assume that the events you report are not what you would see in this configuration, as otherwise there would be no explanation for what you see in the Windows guest. In particular, I would expect a number of additional CapsLock KeyPress and KeyRelease events in the guest before you pressed the alphabetic key the first and the second time. (Or did I misunderstand something, and the general problem is not reproducible with an X11 geust?)

[Michael Thayer]

If that was a guest, then you can copy and paste to the host by installing the Guest Additions, selecting text and using explicit copy-paste from the menu (that is, the older X11 select-and-paste mechanism is not supported, but the newer X11 clipboard mechanism is. Most applications also support Ctrl-C, Ctrl-V to copy and paste. Gnome-terminal uses Ctrl-Shift-C and Ctrl-Shift-V, as Ctrl-C is already used there for something else :) )

[rsparapa@…]

I think I did what you asked. This is a Linux guest on a Solaris host. And the bug does exist there as well.

[Michael Thayer]

Could you actually paste the full keypress and release log output here then? See above for copying and pasting. I'm sure there must be more than the three events you mentioned (especially as I asked for you to press three keys, two of which definitely produce at least two events each :) )

[rsparapa@…]

Ah, I forgot about the guest additions, thanks:

KeyPress event, serial 30, synthetic NO, window 0x3600001,

root 0x46, subw 0x0, time 2175835300, (103,67), root:(108,116), state 0x0, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False

PropertyNotify event, serial 30, synthetic NO, window 0x3600001,

atom 0x107 (XKLAVIER_STATE), time 2175835311, state PropertyNewValue

KeyPress event, serial 30, synthetic NO, window 0x3600001,

root 0x46, subw 0x0, time 2175839092, (103,67), root:(108,116), state 0x2, keycode 38 (keysym 0x41, A), same_screen YES, XLookupString gives 1 bytes: (41) "A" XmbLookupString gives 1 bytes: (41) "A" XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x3600001,

root 0x46, subw 0x0, time 2175839235, (103,67), root:(108,116), state 0x2, keycode 38 (keysym 0x41, A), same_screen YES, XLookupString gives 1 bytes: (41) "A" XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x3600001,

root 0x46, subw 0x0, time 2175842012, (103,67), root:(108,116), state 0x2, keycode 66 (keysym 0xffe5, Caps_Lock), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False

[Michael Thayer]

Sorry for the delay in answering. Unfortunately, the event log you showed me doesn't actually show the problem - as you see, both key-presses resulted in a capital A in the guest. I am now beginning to wonder whether our code mis-reads the CapsLock state on your host, as experimenting with sending key events to a Windows guest via VBoxManage did not reproduce the behaviour you mentioned.

[rsparapa@…]

Still broken in 3.1.0

[rsparapa@…]

After upgrading to VB 3.2.6 and SRSS 4.2, I don't see this problem any more.