Host CTRL key acts like it is on when pressing ALT -> dkms issue

[Andrew Ziem]

Simply installing VirtualBox 2.1.2 on Fedora 10 32-bit causes the host keyboard to malfunction. It happens even before running the VirtualBox GUI or any guests.

What happens:

• I press ALT+F2 (to get Run Dialog) and it acts like CTRL+ALT+F2 and takes me to virtual console.
• I press ALT+LEFT (to change tabs in Firefox) and it acts like CTRL+ALT+LEFT.

However:

• I press F and it doesn't act like CTRL+F (to bring up search in Firefox), and CTRL+F works normally too.
• This problem didn't happen with VirtualBox 2.1.0 or 2.0.6.

Note

• Uninstalling VirtualBox and rebooting host fixes the behavior.

[Michael Thayer]

Possibly a silly question, but is this behaviour reproducible?

[Andrew Ziem]

For me it is very reproducible. I tried a few combinations of uninstalling, re-installing, and rebooting. Every time I install, it starts to happen. I had to revert to an older version (2.1.0) and rollback my configuration files.

[Jari Turkia]

On my Fedora 10 (64-bit) there is exactly same behaviour on Linux client. My Windows clients seem to work ok. I'm running headless clients and using Vista RDP-client to connect.

My Finnish keyboard has following keys on the lowest row:

• ctrl
  
• windows
  
• alt: no visible behaviour
  
• space
  
• altgr: behaves like ctrl, this key is needed to gain [], {}, @ and \
  
• windows
  
• menu
  
• ctrl
  

(Comment for those readers who missed the fact that I'm using a Finnish keyboard: Yes, I'm positive that my keyboard has the keys arranged like that and yes, I'm positive that AltGr is required to produce [ and ].)

I checked ​scancode list and found out following. AltGr has make scancode of 0xE0 0x38 and break 0xE0 0xB8, during Vista RDP-client session showkey -s reveals that the actual scancode received by Linux for AltGr are for make 0x1D 0xE0 0x38 and break 0x9D 0xE0 0xB8.

This effectively means that pressing and releasing AltGr-key sends Left Ctrl + AltGr equivalent codes. This prevents using AltGr for the original purpose as an extra shift-key. The above mentioned characters cannot be produced with ctrl or shift pressed at the same time.

[Michael Thayer]

andrewz: I'm afraid that I can't reproduce this (I tried it by installing VirtualBox 2.1.2 from virtualbox.org into a 32bit Fedora 10 VM. Obviously I couldn't start any VMs in that situation, but you said that you got this as soon as you installed. I assume that you are using VirtualBox from virtualbox.org. Do you have any other software installed that might possibly be related to this?

cfturkja: I'm not quite sure what you were meaning, and I'm not sure that it is the same thing as andrewz reported. Do you mean that when you connect to a headless VM using the Linux rdesktop client the keyboard does not work correctly in the guest?

[Jari Turkia]

Update:
The behavior I described occurs only in an OpenSuSE guest. I'm running 64-bit 11.1 as a guest. For testing purposes I did install a 64-bit Fedora 10 guest also. In Fedora AltGr works perfectly, in OpenSuSE 11.1 the behavior is as I described.

In my opinion it is the same thing. There is the "sticky" Ctrl getting into way. At minimum you have some sort of bug with the Alt/AltGr-key which may or may be difficult to reproduce.

The behavior I described earlier occurs when I use a headless guest via a Windows RDP-client. It is reproducible all the time and it started right away after guest install finished.

[Michael Thayer]

cfturka: what andrewz describes occurs on his Fedora 10 host (that is, whenever he presses ALT on the host, it acts as though he had pressed CTRL and ALT together). It also happens when no guest is running. You are describing (if I understood correctly) behaviour which occurs inside guests, and with a Windows host.

[Andrew Ziem]

All packages installed on my system (after installing Fedora 10 fresh in January)

[Andrew Ziem]

Do you have any other software installed that might possibly be related to this?

Nothing I can see, but I attached a list of installed packages on my system since I installed it fresh mid-January.

[Andrew Ziem]

Just tried VirtualBox-2.1.4_42893_fedora9-1.i386.rpm, hit ALT+F2, and switching back to VB 2.1.0. ;)

[Dave Ulrick]

I experienced this problem after upgrading from VirtualBox-2.1.2_41885_fedora9-1.i386.rpm to VirtualBox-2.1.4_42893_fedora9-1.i386.rpm on FC10. For instance, pressing <Alt-F4> in KDE would close the current window _and_ switch to virtual console #4. The problem went away after I went back to 2.1.2 and rebooted.

[Michael Thayer]

daveu8282: do/did you also get this before even starting a VM?

[Dave Ulrick]

I didn't notice the keyboard problem until after I started and shut down a Windows XP VM.

[Dave Ulrick]

I've just experimented with upgrading to 2.1.4. After the new kernel module was compiled and loaded, <Alt-F4> acted as I described in my earlier comment (2009-02-28 01:48:10) even though I hadn't yet started a VM.

[Andrew Ziem]

Same as before for me in VirtualBox 2.2 (Fedora 10 again).

[Dave Ulrick]

VirtualBox 2.2 under Fedora 10 exhibits the same problem as 2.1.4 on my PC. 2.1.2 works correctly.

[Dave Ulrick]

I've made another attempt to upgrade from VirtualBox 2.1.2 to 2.2. I used this command line:

# rpm -Uvh Download/VirtualBox-2.2.0_45846_fedora9-1.i386.rpm

Immediately after the rpm script that builds and loads the kernel module completed, the bug manifested itself: <Alt-F4> acted like <Ctrl-Alt-F4>, etc.. Rather than revert to 2.1.2, I logged out of my X11 session (KDE 4.2.1), restarted the X server, and logged back in. The bug did not occur: <Alt-F4> acted correctly. I later shut down and rebooted. The bug still did not occur.

Might it be that what's going on here is that the unload/reload of the VirtualBox kernel driver _while the X server is running_ is causing the X server or the kernel to get confused about the status of the <Ctrl> key? Perhaps restarting the X server is sufficient to reinitialize the system keyboard and recover from the problem. If this is the case, two possible circumventions for this problem come to mind:

1. Advise the user to upgrade VirtualBox with the X server shut down.

2. Advise the user to log off and back in to the X server immediately after upgrading VirtualBox (or, more precisely, after unloading/reloading the kernel driver).

Since the bug has not recurred since I restarted the X server, I have stuck with VirtualBox 2.2 and will not be falling back to 2.1.2.

[Andrew Ziem]

Restarting X helped here too (VB 2.2.0)

[Michael Thayer]

Just a wild guess here. Can you take a look at the script /usr/sbin/dkms (or wherever it is located on your system) and see if it still contains a call to udevtrigger? If so, can you try running that command manually to see if it causes this problem? If that is the case, you can just change dkms not to call that (replace it with a dummy command or something) - it is a bug (now fixed upstream) that it does it at all.

[Dave Ulrick]

/sbin/udevtrigger does indeed trigger the CTRL/ALT keyboard problem. Good call!!! Looks like a Fedora bug (#454407) against this problem is open and unfixed.

[Michael Thayer]

Since this seems to be due to that dkms bug, and fixable by restarting X, I will close this ticket. Since the bug is fixed in upstream/Ubuntu dkms, I assume that it will reach Fedora soon as well.