Shift key (and caps lock) stop working when using VMWare

Bug #195982 reported by robb
400
This bug affects 49 people
Affects Status Importance Assigned to Milestone
Linux
Invalid
Undecided
Unassigned
Gentoo Linux
New
Undecided
Unassigned
linux (Ubuntu)
Won't Fix
Undecided
Unassigned
Nominated for Dapper by Walt Corey
Nominated for Hardy by Walt Corey
Nominated for Intrepid by Walt Corey
Nominated for Jaunty by Walt Corey
Nominated for Karmic by hkais
Nominated for Lucid by Walt Corey
xkeyboard-config (Ubuntu)
Invalid
High
Unassigned
Nominated for Dapper by Walt Corey
Nominated for Hardy by Walt Corey
Nominated for Intrepid by Walt Corey
Nominated for Jaunty by Walt Corey
Nominated for Karmic by hkais
Nominated for Lucid by Walt Corey

Bug Description

[Problem]
VMWare's keyboard mapping is imperfect, sometimes resulting in certain keys stopping functionality when running under VMWare, requiring the user to setup their configuration settings manually in VMWare. For a detailed explanation see the following article:

http://www.vmware.com/support/ws55/doc/ws_devices_keymap_linux_longer.html

[Original Report]
After a day or so of running the shift key mysteriously stops working as does the cap lock. In other words I cannot enter shifted characters of any kind. The keyboard is connected to a KVM and all other systems respond to it properly. In additional any VMWare sessions I have open respond correctly. So I have the condition where all non-vmware applications in Ubuntu Hardy (all updates applied as of 2008-02-26 at 12:43 UTC) fail to recognize the shift key BUT applications within an active (a paused/restarted session also works) VMWare sessions running DO recognize the key.

When this condition occurs ALL applications (except those within a VMWare session) are also unstable and will usually crash within a few keystrokes.If I continue to operate in this mode. I cannot pinpoint what, if any, application triggers this. It has always happened while working within terminal/browser/vmware sessions and NOT when opening a new application. It could be related to the KVM switch, but none of my other systems (2 Mandriva, 1 Windows) are affected by this.

This bug has been present on my system for a number of days across daily updates and reboots (if the update requested it) and I think since I installed Hardy Alpha 1.

A work around: log off and back on. A reboot/restart does not appear to be needed.

Error logs show some unusual activity.

--- MARK ----
...
... kernel ... rtc lost 7 interrupts ...
--- MARK ---
....

Plus some segfaults indicating which application crashed as I tried to type into it (mouse works fine).

System: HP dv9743cl (which otherwise works lovely)
Ubuntu: Hardy 8.04 (from lsb-release)

----
TEST CASE:
1. Click inside the VM and
2. Hold any of the Ctrl, Alt and/or shift keys while releasing the keyboard/mouse to the host OS (which you obviously do when you press Crtl-Alt to revert back to windowed mode, as the cursor is then released from the VM).

WORKAROUND:
After this happens to recover your keyboard execute 'setxkbmap' in a terminal

Revision history for this message
Leann Ogasawara (leannogasawara) wrote :

Hi Robb,

Care to test the latest 2.6.24-11 kernel. If the issue still exists, per the kernel team's bug policy, can you please attach the following information. Please be sure to attach each file as a separate attachment.

* uname -a > uname-a.log
* cat /proc/version_signature > version.log
* dmesg > dmesg.log
* sudo lspci -vvnn > lspci-vvnn.log

It would also be helpful if you could attach the segfaults you are seeing. For more information regarding the kernel team bug policy, please refer to https://wiki.ubuntu.com/KernelTeamBugPolicies . Thanks again and we appreciate your help and feedback.

Changed in linux:
status: New → Incomplete
Revision history for this message
robb (robb-canfield) wrote :

So far no crashes in the last 24 hours (running 2.6.24-11). Plus a reboot issue (where the system locked with a LCD white screen - never reported) has also been resolved. I will continue to monitor and on any errors post the requested data. The segfaults have, usually, been submitted as a different bug. I will also attach them here if I can.

As an aside, having worked with many distributions of 10 years, Ubuntu's community, dedication and ability to just make things works is very impressive. Nice work.

Revision history for this message
testman57 (testman57fr) wrote :

Hello,
I have to say I have been having the same kind of problem using vmware-server-console... but with not only the shift key dead, but the ctrl and alt keys too... They work perfectly in the vmware session running, but not outside, and programs started after that seems to segfaults rather quickly after some key presses. I have to check if the 2.6.24-11 solves the problem by me (it was installed this morning)...

Revision history for this message
testman57 (testman57fr) wrote :

Correction: problem still exists for me on kernel 2.6.24-11 :( But I am still not sure when it happened exactly, as I am using Vmware server (remotely through vmware-server-console) and vmware workstation locally...

Revision history for this message
Brian Murray (brian-murray) wrote :

I've run into this issue more than once myself with 2.6.24-12 and using 'setxkbmap' resolves it for me.

Revision history for this message
Ryan Lovelett (ryan-lovelett) wrote :

I'm having the same issue in Hardy Beta 4. This is installed on my laptop and use it for daily use. Let me know what I need to attach to help resolve this issue. The log out and log in works for me, however this is annoying. The 'setxkbmap' does not resolve my issue.

Thanks.

Revision history for this message
Stefan Skotte (screemo) wrote :

Running setxkbmap solved it for me aswell.

Revision history for this message
AndrewNaoum (anaoum) wrote :

I also can also confirm this is happening to me. I am running vmware workstation 6.0.2, 2.6.24-12-generic kernel & hardy beta.

setxkbmap works like a charm, but the problem still is rather annoying.

Revision history for this message
arnaud.didry (arnaud-didry) wrote :

hello
the same problem occurs to me, but i'm not using ubuntu inside vmware;
running 'setxkbmap' doesn't solver the issue for me;
how can we help ?

Revision history for this message
philsom (phil-somerville) wrote :

Hi

Been having this same problem on an off for a few weeks, quite new to linux so i wont say more than that.

Logs attached

Revision history for this message
arnaud.didry (arnaud-didry) wrote :

hello,
I have seen that the summary changed for "Shift key (and caps lock) stop working when using VMWare" but I think that the problem is not related to VMWare, I am experiencing it without using vmware. I will send my log the next time I boot on hardy

Revision history for this message
philsom (phil-somerville) wrote :

May i add that i am also not using VMWare, notable keys which stop working are, shift, caps lock, ctrl

I expect everything else about my dsitro and system will be in the logs.

Revision history for this message
Brian Murray (brian-murray) wrote :

This bug report was initially about this issue happening when using VMWare and should stay that way as it is probably a separate bug. If the two people who are experiencing the symptom without using VMWare could submit separate bug reports and subscribe me to them, that would be quite helpful. Thanks in advance.

Revision history for this message
robb (robb-canfield) wrote :

I am slowly working out when this happens. So far I have the following data points

1. I reinstalled Ubuntu, from scratch using the BETA download
2. I had NO problems with or without VmWare using the nv driver
3. I finally figured out how to enable Nvidia proprietary driver
4. Problems began anew within a day or so
5. Once the problem begins Ubuntu is HIGHLY unstable with crashes in all range of applications. The VMwre session is unaffected (which makes sense). Recover is log on/off.

I realize this is not very scientific and possibly of minimal value. I have now disabled the proprietary Nvidia drivers (gads video is slow now) to see if that helps. I run in VMware extensively as I am using it for development, but I suspect VMware is a red herring. I think the problem is with the proprietary Nvidia drivers on my HP Laptop (8600 m).

My hypothesis is that disabling Nvidia proprietary drivers (the reason I went with Ubuntu in the first place) will resolve the keyboard and stability issues.

PS: Disabling the Nvidia driver required an edit to my xorg, un-checking the box in the Hardware Drivers was ineffective, even with a reboot.

Revision history for this message
Brian Murray (brian-murray) wrote :

I've experienced this bug only when using VMWare and I am using the "ati" video driver in my host operating system. Subsequently to avoid confusing this bug report I think it would be best if robb were to open a new bug report regarding his issue.

Revision history for this message
Brian Murray (brian-murray) wrote :

I didn't realize that robb was the initial reporter of this bug - sorry about that. I'm not quite certain what would be best in this case. robb what would you prefer happens?

Revision history for this message
robb (robb-canfield) wrote :

There may be more to this bug than just VMware or just Nvidia. I think until it can be isolated it is best to leave this bug as is. I don't see a reason to spawn another bug report based on a hypothesis used to isolate this one. Once more data is accumulated a new more specific bug can be filed if appropriate.

I find it curious you only encounter this bug when running VMware. Out of curiosity are you using the VMware tools in the client? I am, and maybe that interaction is contributing to this problem. And just to add more confusion lets say it is an Xorg issue and some drivers are more susceptible than others. Just guessing, but some ideas to track down. So may variables that are hard to isolate since the bug does not, at least for me, happen instantly.

1. Xorg?
1.a. Video Driver contributing?
2. VMware?
2.a. VMware tools in client?

Revision history for this message
robb (robb-canfield) wrote :

It's been 24 hours or so, longer than any prior good result with Nvidia drivers, and my system is stable using the "nv" driver. VMware works fine as do all other applications so far. Also resolved is the odd auto-repeat for the keyboard. Using the 'Nvidia' driver I get weird keyboard auto-repeat timeouts in VMware (long pauses to start and then VERY fast repeat). With the "nv" driver the repeats work as expected.

Unfortunately the nv driver is rather slow, especially for scrolling, so it is not a good long term solution for me.

I am still not sure if this is an issue with VMware,VMware tools or NVidia drivers on my system. Any suggestions on what I can do to help resolve this bug are appreciated.

Revision history for this message
arnaud.didry (arnaud-didry) wrote :

I haven't encountered the bug since my last upgrade (2008-04-03). I also seen in the apt log that xkb-data had been upgrated. Maybe it is the origin of the problem ?

Revision history for this message
Corey Seliger (seliger) wrote :

I too have been experiencing this issue. I launch VMware Workstation 6.0.3 build 80004 and when I click inside a Windows XP console (don't have any other VMs yet) and come back out, my shift keys, caps lock, control and alt keys no longer function. Like in the other cases, my mouse continues to function properly, so I can click through and log out. Logging out seems to reset whatever needs to be reset because I can log back in and the keyboard works as expected.

Here is the other spin to this -- if I open a GNOME Terminal in this state and press *ANY* key at all, the terminal window immediately disappears. I also had Firefox go to lunch on me when I was typing into the location bar. I can trigger that again and send a crash report if necessary.

Here is some more info on my setup:

XOrg:
X.Org X Server 1.4.0.90
Release Date: 5 September 2007
X Protocol Version 11, Revision 0
Build Operating System: Linux Ubuntu (xorg-server 2:1.4.1~git20080131-1ubuntu6)
Current Operating System: Linux feathers 2.6.24-15-generic #1 SMP Fri Apr 4 03:10:59 UTC 2008 x86_64
Build Date: 30 March 2008 04:44:41PM

Video Driver:
Restricted nVidia driver
ii nvidia-glx-new 169.12+2.6.24.12-15.33 NVIDIA binary XFree86 4.x/X.Org 'new' driver
ii nvidia-kernel-common 20051028+1ubuntu8 NVIDIA binary kernel module common files

VMware:
VMware Workstation 6.0.3 build 80004

VMware tools:
YES

I am attaching the requested output mentioned earlier. I have no segfaults or anything at this time to report. I do not believe anything is crashing per say, but I am definitely having the keyboard issues reported and it (at least for me) seems to be related to the VMware console functionality.

3 comments hidden view all 234 comments
Revision history for this message
robb (robb-canfield) wrote :

Yes, that mirrors my case. I have found that many dialog boxes will cause the specific application to crash. Starting Thunderbird, entering the package manager, etc. Existing applications work OK but without the SHIFT/ALT/CTR. Opening a new window often causes an application crash.

Have you tried switching to the to basic NV video driver and see if this is more stable?

Revision history for this message
Corey Seliger (seliger) wrote :

I just tried. Made absolutely no difference between the restricted driver and the OSS driver. My video board is a GeForce Go 7600 in a HP Pavillion dv9000z (AMD Turion 64) laptop.

Now here are two other mild discoveries made:

1. Inside the VM, the functionality of the CAPS key works. If I push it once, I get uppercase; if I push it again, I get lowercase. However, the CAPS indicator on my keyboard never changes... It normally does in other environments where I have used VMware. It should also change state inside and outside of the VM window dynamically (if one is in CAPS and the other is not, etc.).

2. The functionality of the CTRL/ALT/SHIFT/CAPS keys disappearing seems to be directly related to pressing CTRL+ALT+ENTER to lauch full screen from the VM console. If I use the VM within the window, everything seems to be fine (with exception that #1 still applies in window mode). However if I use CTRL+ALT+Enter, all bets are off.

3) If I use the "Fullscreen" button on the toolbar, I retain the ability to use the keyboard as normal when switching in and out of the VM in full screen.

There are a couple of mentions of xkbmap and that seems to fix the problem for some people. Is there any specific way that is run, or just running it fixes the problem? And how are people running it if dialogs and the like explode due to the strange keyboard state?

Revision history for this message
Justin (justin75) wrote :

hi all,

just wanted to add that i just experienced this bug as well. i'm running hardy amd64, fully updated. been working fine with vmware server 1.05, as you mentioned corey, i just used ctrl-alt-enter to switch to full screen in my win xp guest and upon return to window mode, no shift, caps lock, alt keys. all keys still work fine in the xp guest, but not in hardy. i will probably not use full screen on guests, but good luck and hope this helps. [sorry for all lowercase ;]

Revision history for this message
robb (robb-canfield) wrote :

Just had the problem again and this time with the normal NV driver. I never switched to full screen VMware (always ran windowed). So I have reproduced the problem under similar circumstances others have reported. I still feel there is some interaction with the xorg as the nvidia driver consistently fails much sooner than the nv driver.

Once a failure occurs dialog boxes become highly unreliable and crashes (outside of VMware) become common.

I am now going back to the nvidia driver and disabling the vmware tools just to see if that might be an issue. Hopefully going back to nvidia driver will accelerate any issues I have. Any suggestions for further testing are encouraged.

Of course a VMware solution would be rather handy....

Revision history for this message
xtknight (xt-knight) wrote :

i have this issue with hardy and amd64. ctrl doesn't work either. numslock/scrollock/capslock lights are dead.

nvidia driver here. don't think it's related. probably the new kernel changing something. i didn't have this problem in gutsy [ok maybe once]

i bet you can guess why there's no capitals. ;p

Revision history for this message
xtknight (xt-knight) wrote :

for me, the shift and control work inside the vm, but not outside it.

Revision history for this message
xtknight (xt-knight) wrote :

And restarting the X server works. Sorry for the multiple comment spam here.

Revision history for this message
terigox (terigox) wrote :

Hello all, I am under the same scenario. Running Vmware Server Beta 2.0 with Windows XP inside under Hardy Beta amd_64....

This seems to happen for me very regularly when I do not ctrl+alt out of the vmware client. If I simply pull my mouse out of the client window, the keys will sometimes work, but more often than not this causes the Ctrl+alt, caps, etc keys to fail.

setxkbmap also resolves this problem for me.

Revision history for this message
RuralRob (ruralrob) wrote :

Was googling on "shift key stops working" and found this thread. I am seeing the same problem, running VMware Workstation 6.0.3 under the latest Sidux. I'm pretty convinced it has something to do with VMware's automatic keyboard/mouse-grabbing logic when moving the mouse in and out of a VM window, because I only see the problem when running VMware in Quick-Switch or Full UI mode and switching between multiple VMs, as opposed to running the VM full-screen (where you have to Ctrl-Alt to get back to the host). So this is probably worth a bug report to VMware as well.

Revision history for this message
robb (robb-canfield) wrote :

Since my last post on 4/6 I have NOT had the issue occur. I removed the vmware-tools from the virtual server and now use ctrl-alt to switch. I am running in a window mode.

I agree that this appears to be a vmware issue, although it would be nice to have xorg a tad more robust and not crashing dialog boxes on us when the error occurs.

Revision history for this message
Dym (dmarszal) wrote :

Hardy latest. I too experience this bug, seems thats removing VMWare tools fixes this problem. Also running "setxkbmap" in the console fixes the problem without relog.

Revision history for this message
robb (robb-canfield) wrote :

Do you experience any reliability issues in the Ubuntu host when VmWare tools is installed in the VPS?

I, and some others, have major stability issues, especially on opening new applications or dialog boxes. I have NOT tested this with the latest xorg updates released in the last week so maybe that part has been fixed.

Revision history for this message
Dym (dmarszal) wrote :

Yes, dialog boxes seem to close on keystroke. I have the latest Hardy packages.

Revision history for this message
robb (robb-canfield) wrote :

Your logs may well show some xorg or general segfault errors in this case. Makes the system kind of hard to use! An exit out of xorg is all that is needed to recovery (a reboot does not seem to be required).

OK, at least we have more data. Not sure how that helps given I can't do much more than test. At least the problem seems to be associated to the vmware-tools within the client VPS. For now I just don't use vmware-tools.

I suspect an update from VmWare will be the final solution.

Revision history for this message
terigox (terigox) wrote :

I have the VMWare tools isntalled on the VPS and have not experienced any issues with reliability (Also under Hardy latest).

However, I don't normally leave the VPS running more than a day or so. I'll try to leave it running and see if this changes anything.

Revision history for this message
terigox (terigox) wrote :

I forgot to mention I'm on VMWare Version 2.0 Build 84186.

I'm not sure if perhaps you are running a different build.

Revision history for this message
Dym (dmarszal) wrote :

I'm using VMWare Workstation 6.0.3 build 80004. Problem occurs just after starting VMWare client.

Changed in linux:
status: Incomplete → Confirmed
Bryce Harrington (bryce)
Changed in xorg:
importance: Undecided → High
status: Confirmed → Triaged
Changed in linux:
status: New → Invalid
description: updated
Bryce Harrington (bryce)
description: updated
154 comments hidden view all 234 comments
Revision history for this message
cengopon (pognonec) wrote :

Hi there,

I had the same problem: shift key suddenly stopped working, after having played around with cubes in Compiz. I turned off the System/Preferences/Appearance/Visual effects to none, and shift key magically came back. Don't ask me why, but now, I won't show off with Compiz anymore (or should I write: compiz?).
It may have to do with the video card (I am on Dell XPS M1130, on 8.10 Intrepid) with the NVIDIA driver 173 (I had problems with the 177).

Revision history for this message
Dejan (dejan-rodiger) wrote :

Philippe you are correct.

Here is the solution:
Open Compiz Settings Manager, open General Options, open Commands tab.
Open Key Bindings and disable F19 key on Run command 0.

Revision history for this message
cengopon (pognonec) wrote :

Great job, Dejan!
Now I can show off with Compiz AND use the shift key
;-)

Revision history for this message
Bryce Harrington (bryce) wrote :

As per comment #191, this isn't an xkeyboard-config bug, so canceling that task.

Changed in xkeyboard-config:
status: Triaged → Invalid
Revision history for this message
Noel J. Bergman (noeljb) wrote :

I have never seen this bug before, but all of a sudden it has surfaced consistently with Jaunty. The workaround of running

  setxkbmap

in a terminal window does correct the lack of modifier keys.

VMware Workstation 6.5. Interestingly, I have never seen this with Fedora 9, Fedora 10, Gutsy, Hardy, Intrepid, or even Jaunty until recently. And I still can't reproduce it anywhere other than with Jaunty.

Revision history for this message
oleibrock (oliver-leibrock) wrote :

Hi all,

I do have same issue on an acer Laptop with ATI graphic card and VMware Server 1.0.8 build-126538 on Ubuntu 8.04.

Keyboard is working some time in both environments (vmware session eqaul with OS is booted and Ubuntu Host). Whatever happend after some time keyboard and ctrl/alt /shift keys are no more working on the host but still in guest.

Only chance to fix was to logout and login again.

"sudo setxkbmap" saved my live from today on.

Thanks for this.

Cheers

 Oliver

Revision history for this message
kantoka (kantoka) wrote :

Hi,

The VMWare keybord vs Linux (Ubuntu only?) issue continues. In 8.10 the after effects of using VMWare Desktop in Ubuntu where easily solved by executing the "setxkbmap" after switching back to the host.

But... in Ubuntu 8.10 it have turned to the worse. Now the "setxkbmap" doesn't have any effect any longer. It messes up the shift and ctrl keys so I can't make the "shift-ctrl-v" for copying text into a text terminal. In the VMWare client, the "Alt Gr" - key have turned into an "enter" -key, for example making a newline when pressed in text editor. This means that I can't use some keys to produce certain characters when switching to a VMWare client.

I still hope that there will be a solution to this problem, as I do love to use Ubuntu.

Revision history for this message
kantoka (kantoka) wrote :

Made a typo in the second sentence. Should be 8.04, not 8.10!
==========================================

Hi,

The VMWare keybord vs Linux (Ubuntu only?) issue continues. In 8.04, the after effects of using VMWare Desktop in Ubuntu where easily solved by executing the "setxkbmap" after switching back to the host.

But... in Ubuntu 8.10 it have turned to the worse. Now the "setxkbmap" doesn't have any effect any longer. It messes up the shift and ctrl keys so I can't make the "shift-ctrl-v" for copying text into a text terminal. In the VMWare client, the "Alt Gr" - key have turned into an "enter" -key, for example making a newline when pressed in text editor. This means that I can't use some keys to produce certain characters when switching to a VMWare client.

I still hope that there will be a solution to this problem, as I do love to use Ubuntu.

Revision history for this message
KJ (cortexbuster) wrote :

Hi,
this problem persists in 9.04 jaunty beta with all updates installed. but setxkbmap does work for me to work around the issue. but as it occurs ever time I'm in the vmware console (I run vmware server 2.01) it's very very very annoying. are there other ways to resolve this issue?

Revision history for this message
Michael Kofler (michael-kofler) wrote :

I finally switched to Virtual Box a week ago (after having used VMware products for about 10 years!). VMware was great for a long time, but I had simply too much different stability problems during the last year (keyboard, network, X). Virtual Box certainly is no perfect product, but at least for the last week, it just worked. I need Win XP for some aspects of my work, and I need to run it flawlessly. Virtual Box seems to offer what I need.

Revision history for this message
Ratius (ratius) wrote :

The bug happened to me as well on Jaunty which I have upgraded today. The "setxkbmap" worked fine for me.

This happened on a 64bits operating system, VMware workstation 6.5.0, and it had never occured to me on intrepid. After using the "setxkbmap" command, switching back and forth with the guest and host didn't turn off the key modifiers again but I haven't tested much yet.

Revision history for this message
danhar (dan-harenberg) wrote :

I can reproduce the bug on a fresh install of Kubuntu Jaunty (latest, all updates). Happens nearly always when I have a VmWare virtual machine running and perform some action in it, but not if it's running in the background, i.e. no focus and no mouse action in it. Running VmWare Server 2.0.0 Build 122956 with the Vsock patch applied and the keyboard patch so that in the virtual machine, the keys are mapped correctly (xkeymap.noKeycodeMap = "TRUE"
 in /etc/vmware/config). setxkbmap works but have to issue the command every time after I did something in the virtual machine.

Hope that is of some help. I am quite a newbie here so let me know if there is anything I can do (like sending reports, which ones and how).

Revision history for this message
Mark (darck1) wrote :

I can also reproduce this bug. I'm running Win XP Professional on my Ubuntu Jaunty box (latest all updates). The version of Vmware Workstation I am using is 6.5.0 build-118166. I have VMTools installed. I have xkeymap.nokeycodeMap = true in my ~/.vmware/config because otherwise my keymap wouldn't work. Typing setxkbmap in a console worked for me.

This happened several times when I was switching often between my VM and my desktop. I was copying/pasting from the VM to OpenOffice.

Revision history for this message
hkais (r-2) wrote :

Hello I can also report this issue. I have 2-3 times a week the issue. Additionally enough my passwords must have special chars, so I am often lost, if my screensaver locks...

I am running jaunty 32 bit with latest updates. VMware 6.5.2. I tried both the generic kernel and the server kernel.
In both configs I get the really odd error, that my especially SHIFT isn't working any more.

How can I support to figure out, there the root-cause of this error is?

Revision history for this message
kernel-janitor (kernel-janitor) wrote :

Hi robb-canfield,

Please be sure to confirm this issue exists with the latest development release of Ubuntu. ISO CD images are available from http://cdimage.ubuntu.com/releases/ . Please then run following command from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux-image-`uname -r` 195982

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

tags: added: needs-kernel-logs
tags: added: needs-upstream-testing
tags: added: kj-triage
Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Executive (ooo-biodef) wrote :

I have two Ubuntu machines, one is running 8.04 LTS 64bit Server edition and the other is 9.04 64bit Desktop edition.

I have installed VMware Server on the 8.04 server and I am accessing it with Firefox via HTTPS.

I have the problem being discussed here and running setxkbmap restores my keyboard mapping so that the Ctrl and Alt keys start working again both in the Desktop and Server windows.

My guess is that this problem is related to VMware setting the keyboard mapping on the host, to match the mapping on the virtual machine.

Problem could be, I have a 105 key USB keyboard on my workstation but vmware has a 102/3 key virtual keyboard attached to the virtual machines (I have 1 Redhat and 1 Windows 2003 server running as virtual machines)

This could also be related to how WMvare "grabs" the keyboard. I don't know.. Fact is I don't think this is a OS problem at all. I belive the OS is behaving as it should.-

Revision history for this message
hkais (r-2) wrote :

Hello all,

I switched pretty luckily to karmic/9.10 and hoped some of the previous issues will be gone...

This issue also affects now 9.10/karmic...

How can I help to find the bug?

Revision history for this message
d2globalinc (shane-2710studios) wrote :

Same issue here with karmic - troubleshooting the issue more - don't remember having this problem before. Using vmware workstation 7 - and I recalled that I used to have some settings in the /etc/vmware/config file for keyboard mapping for some arrow key fix for workstation 6.. I decided to re-input those mappings into my /etc/vmware/config file to see if it helps resolve this issue.. I'll post back my findings.. This is what I put at the end of my /etc/vmware/config file - incase anyone else would like to test their findings as well.

xkeymap.keycode.108 = 0x138 # Alt_R
xkeymap.keycode.106 = 0x135 # KP_Divide
xkeymap.keycode.104 = 0x11c # KP_Enter
xkeymap.keycode.111 = 0x148 # Up
xkeymap.keycode.116 = 0x150 # Down
xkeymap.keycode.113 = 0x14b # Left
xkeymap.keycode.114 = 0x14d # Right
xkeymap.keycode.105 = 0x11d # Control_R
xkeymap.keycode.118 = 0x152 # Insert
xkeymap.keycode.119 = 0x153 # Delete
xkeymap.keycode.110 = 0x147 # Home
xkeymap.keycode.115 = 0x14f # End
xkeymap.keycode.112 = 0x149 # Prior
xkeymap.keycode.117 = 0x151 # Next
xkeymap.keycode.78 = 0x46 # Scroll_Lock
xkeymap.keycode.127 = 0x100 # Pause
xkeymap.keycode.133 = 0x15b # Meta_L
xkeymap.keycode.134 = 0x15c # Meta_R
xkeymap.keycode.135 = 0x15d # Menu

Revision history for this message
Kikker46 (kikker46) wrote :

I have those already in the script and thus this is not fixing that issue with me. (Ubuntu 9.04)
I updated to VMware Workstation 7, so I might need to remove them, will check this out and comment my findings.

Revision history for this message
Randy Syring (rsyring) wrote :

I also have this problem on 9.10 x86_64 and vmware workstation 7.0.

Revision history for this message
Roland (roland1979) wrote :

I can confirm post 214 (Ubuntu 9.10 x86_64 and VMware Workstation 7.0). Executing "setxkbmap" still works as a workaround.

Revision history for this message
Jim Lehmer (jim-lehmer) wrote :

Getting this behavior in 64-bit Mint 8 (built on Ubuntu Karmic Koala) running VMWare Server 2. As with others, setxkbmap works as a workaround, and the behavior doesn't affect the guests, just the host.

Revision history for this message
James Baron (james-bluebaron) wrote :

I don't know if this is the same issue that everyone else has had, but I know this has happened to me on multiple systems: My CTRL and ALT keys lock and are on constantly. When I press 'F', the computer acts as if I'm pressing CTRL + 'F'. If anyone else has had this problem, try the following: Tap back and forth rapidly between the CTRL + ALT keys, then sometimes I do the shift keys as well for good measure. The keyboard starts working.

Revision history for this message
Nelly (launch-ecostat) wrote :

Hello,

I have the same problem.
I am using Ubuntu 10.04
VMware player 3.0.1 build-227600
I have had the problem now twice, so I cannot say much about the regularity.
setxkbmap works.
I am using this configuration for several months. The problem with non-working SHIFT, CTRL and ALT keys occurred only in the last week. The only change in the configuration (except for the usual updates) is: a new keyboard and a new mouse.
I have now a keyboard without a numeric keyboard (to minimize RSI problems, the new keyboard is only 30 cm width instead of 45 cm, so that the right hand is in a better position to hold the mouse).
And the second time I had this problem (I cann't remember about the first one), the virtual PC had crashed, and when started again, it said it could not grab the keyboard. I have had this message before (before and I believe also after the keyboard change), without any consequences for the SHIFT etc. keys.

Revision history for this message
Nelly (launch-ecostat) wrote :

Hello,

In addition to my previous remarks (#218):
I had another occurrence. Just before, my Virtual PC crashed. It had some message, but that disappeared before I could read it.

Revision history for this message
alain57 (alain57) wrote :

same problem on ubuntu 10.10 with VMware Player 3.1.2 build-301548
my host is ubuntu 10.10 x64
my vm is ubuntu 10.04 x86

on a forum i found this solution, that work on my computer

just create an executable file with this content (and run the magic command if you loose ctrl or other keys ...

#!/bin/sh
/usr/bin/xmodmap - << XXX
clear shift
add shift = Shift_L Shift_R
clear lock
add lock = Caps_Lock
clear control
add control = Control_L Control_R
clear mod1
add mod1 = Alt_L Alt_R
clear mod2
add mod2 = Num_Lock
clear mod3
clear mod4
add mod4 = Super_L Super_R
clear mod5
add mod5 = Scroll_Lock
XXX

Revision history for this message
Bart Janssens (bartholomeus-j) wrote :

Hi,

The exact same thing happens to me on a clean beta Natty with only Vmware Player (version 3.1.4 build-385536) installed on top of that. It is not persistent and I have not yet figured out what triggers it.

As told above, running 'setxkbmap' gets all the keys working again.

Revision history for this message
John Faith (jfaith7) wrote :

The behavior I saw before shift, ctrl stopped working was that all keyboard events and the mouse state were captured. The mouse moved, but stayed as the guest OS's mouse icon (vs Kubuntu's). I could not get to a local console and had to remotely kill the vmplayer process to get back any control. I also tried "export VMWARE_USE_SHIPPED_GTK=yes" in /usr/bin/vmplayer, which seemed to make the problem happen less frequently, but it still happens.

I'm using Natty and VmWare player 3.1.4 build-385536

Revision history for this message
thejpster (ubuntu-thejpster) wrote :

This happens for me on Maverick with Vmware Workstation 7.1.4 build-385536. Sometimes, I don't notice it's a problem (say, I'm working in the VM where the keys still work fine), I go away for a while, the screensaver activates and I find I'm unable to enter my password. I have to kill gnome-screensaver from another machine using SSH, then run setxkbmap to fix it.

Revision history for this message
Hans Meine (hans-meine) wrote :

I have no problem with Shift or Alt, but with Ctrl, everytime when I leave the vmware player on natty (Kubuntu, no Unity or the like here).
(I am using the Neo keyboard layout, so I have no CapsLock key to test.)

Unfortunately, this bugreport seems to be a big mess:
* People having problems with different keys,
* with or without(?) varying(?) virtualization solutions,
* sometimes mentioning new HID hardware (applies to me, too [1]),
* sometimes mentioning graphics drivers (closed-source NVidia for me, too),
* with varying software and kernel versions,
* and with different proposed workarounds (calling 'setxkbmap' being the most efficient one AFAICS).

And for me, I can only say that I did not have this problem in the past, but I am not sure which of the many things that changed in the meantime caused this:
* upgrading from Maverick to Natty
* installing the new keyboard [1]
* performing daily Ubuntu software updates
* updating VMWare player
* /not/ using Unity ;-) but KDE (half-jokingly, after all vmware-player has an "Enter Unity" menu entry)
* using Ctrl-Alt to release the kbd grab

The latter seems to be the most likely to me; in the past, I just moved the mouse to the top to reveal and focus the menubar and then used Ctrl-F2 to change the virtual desktop, but that does not work anymore. So I had to learn about Ctrl-Alt, but now I have the problem with Ctrl stopping to work. (It's always Ctrl, but never Alt, independent of the order in which I press or release the two.)

[1] Got a Microsoft Natural Ergonomic keyboard recently.

Revision history for this message
Tom (thomasmca) wrote :

I still have the fubar keyboard problem when switching between my host (64bit Kubuntu Natty 11.04) and guest (32bit Microcrap Windoze 7) via VMWare Workstation 7.1.5.

Sometimes the Ctrl key stops responding, sometimes Alt-Tab stops responding. I have not noticed if both are broken at the same time. Running setxkbmap fixes it for the current session.

I always use Ctrl-Alt to switch the focus to the host, then Alt-Tab to switch the active app. I've never used CTRL-ALT-ENTER, partly because I always use Quick Switch to make my VM "almost" full-screen.

Hardware specs:
* Dell Precision M6500
* Video: ATI Mobility Radeon HD 5800 Series
* Processor: I7-620M, 2.66, 4 MB, Arrandale, C2
* Display: LCD, 17WUXGA, Samsung
* Video Driver: fglrx

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Rocko (rockorequin) wrote :

fwiw, I just ran into the fubar keyboard problem with vmplayer 5.0.1 in Ubuntu 12.10, but found a workaround. Every single time that my mouse went into the vmplayer window, vmplayer trashed all the modifier keys so that CTRL, SHIFT, ALT all stopped working. xmodmap showed:

shift
lock
control
mod1
mod2
mod3
mod4
mod5

Running setxkbmap reset the modifiers correctly, but of course it was a huge PITA to do that every time the mouse went over the vmplayer window.

However, vmplayer worked fine for another user, so I compared our default xmodmaps:

shift Shift_L (0x32), Shift_R (0x3e)
lock Caps_Lock (0x42)
control Control_L (0x25), Control_R (0x69)
mod1 Alt_L (0x40), Alt_R (0x6c), Meta_L (0xcd)
mod2 Num_Lock (0x4d)
mod3 Control_R (0x69)
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)

The only difference was that mine had the "mod3 Control_R (0x69)" line, whereas the other user had a blank mod3 line.

After issuing xmodmap -e "clear mod3" for my user so the two maps matched, vmplayer stopped trashing the keyboard modifiers for my user.

Revision history for this message
penalvch (penalvch) wrote :

robb, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc5

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Ádám T. Nagy (tnagy.adam) wrote :

Hi everyone,

The issue seems to be reproducible the following way:

0. I am on Ubuntu 12.04.4
1. Install VMWare Player 6.0.2 or 6.0.3
2. Run a VM
3. Go To System settings in Host Ubuntu - Keyboard Layout / Options /Caps Lock behavior ->
Make Caps Lock an additional Control but keep Caps_Lock keysym
4. After this, swinging the mouse over a virtual machine's desktop triggers the issue.
5. Running setxkbmap in terminal is a good workaround

I finally remembered that I changed the keyboard layout with this modification (thanks to this comment: https://bugs.launchpad.net/ubuntu/+source/xkeyboard-config/+bug/195982/comments/226) I had this for a few days but this issue was really a pain.

Hope you can solve it on Ubuntu side

Cheers,
Adam

Revision history for this message
Nathan (nathansmith-2003) wrote :

For me, it turned out that the "Caps Lock as an extra control key" was the culprit. xmodmap was

xmodmap: up to 4 keys per modifier, (keycodes in parentheses):

shift Shift_L (0x32), Shift_R (0x3e)
lock Caps_Lock (0x42)
control Control_L (0x25), Caps_Lock (0x42), Control_R (0x69)
mod1 Alt_L (0x40), Alt_R (0x6c), Meta_L (0xcd)
mod2 Num_Lock (0x4d)
mod3
mod4 Super_L (0x85), Super_R (0x86), Super_L (0xce), Hyper_L (0xcf)
mod5 ISO_Level3_Shift (0x5c), Mode_switch (0xcb)

I removed the Caps_Lock (0x42) from the control line and the problem went away. VMWare stopped flushing my mappings and my keys all worked the same as before. Somehow my CapsLock is still mapped as a control key as well.

Revision history for this message
Po-Hsu Lin (cypressyew) wrote :

Closing this bug with Won't fix as this kernel is no longer supported.
Please feel free to open a new bug report if you're still experiencing this on a newer release (Bionic 18.04.3 / Disco 19.04)
Thanks!

Changed in linux (Ubuntu):
status: Incomplete → Won't Fix
Revision history for this message
Gary Clayburg (gclayburg) wrote :

Ok I see this issue is closed as its quite old. Is this particular issue tracked somewhere else?

I just upgraded my Ubuntu 16.04 system to Ubuntu 18.04.5 and this issue still exists for me.

what I'd like to be able to do is:
1. configure my keyboard on the host laptop to map "Caps Lock as an extra control key"
2. launch a vm in vmware player on the laptop
3. Use both the left and right shift keys inside any window on the host laptop.

The workaround of running "setxkbmap" does get around the issue somewhat. For me it does allow the right shift key to start working again. However, it doesn't fix everything. For example, I notice that I can no longer use a the Alt-F1 keyboard shortcut in IntelliJ IDEA. The only workaround I have found for this is to restart the entire laptop after using any vm in vmware player or just not use Alt-F1 keystroke.

I do recall having to do some keyboard mapping a long time ago so that IntelliJ could process Alt-F1 and not Ubuntu itself.

Does anyone know if Ubuntu 20.04 magically makes this issue go away?

One other thing I remembered. I had a similar but a little different issue some years ago with the "caps lock as extra control key" setting when using synergy. More details here:

https://github.com/symless/synergy-core/issues/4658

AFAIK, that issue was never resolved either.

Revision history for this message
Gunnar Hjalmarsson (gunnarhj) wrote :

@Gary: Please submit a new bug report. You won't call anyone's attention by a comment on this old closed one.

Revision history for this message
Ronny Ager-Wick (ronny-ager-wick) wrote :

Wow, I did not expect this bug from 2008 to resurface in 2021!

To quote myself in 2008:
> As I'm using the free version of vmware, I can live with it until:
> 1. They fix it
> 2. VirtualBox becomes stable enough to use

#2 happened many *many* years ago, so I can no longer test this issue, that was never really resolved beyond the sort-of-workaround with setxkbmap in over 12 years...

Revision history for this message
Gary Clayburg (gclayburg) wrote :

Ok, so I went back and re-read some of the most recent comments here - especially #226 and #229.

This is what works for me:
$ alias vmware="xmodmap -e 'remove control = Caps_Lock ' && /usr/lib/vmware/bin/vmplayer"

If I start vmware with this alias, the keyboard on the host does not get corrupted when the mouse leaves the window. Well, sorta. I've used this for a few days and it was working until just now as i type this message. So this fix is not perfect. But this 2 step fix seems to get around the issue:
$ setxkbmap
$ alias vmware="xmodmap -e 'remove control = Caps_Lock '

To me this really looks more like a vmware bug. I plan on filing an issue there.

Displaying first 40 and last 40 comments. View all 234 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.