Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

In my lab we have about 40-50 machines, all cloned with the same image of CentOS 6.

For some reason the keyboard auto repeat function decides to randomly turn itself off. Typically we just have students type xset r on which will turn it on. However, all throughout the day and random intervals it turns itself off again. There seems to be nothing in common with the times it does it, or the actions that were being performed on the system at the time it turned off. Recently it will even remain off even after typing xset r on multiple times in a row as both root and a normal user.

It's highly annoying and I can't seem for the life of me to figure out how to permanently turn this on. My only real solution I've thought of was to create a cron job that turns it on every minute or so, however this only seemed to work temporarily. Hours after it starts running it just turns off again and the script seems to be rendered null and void. I've tried adding it to start up scripts, bash_profile, xinit scripts etc. But it will not stay on.

What may be causing this and how can I permanently fix it?

I have found others with similar issues that seem to believe it has something to do with VMware's mouse and keyboard driver that allows seamless integration of desktops. Which could be the case since we do run VMware Workstation on the machines. But sometimes it will happen even if a Virtual Machine isn't running even after a fresh reboot.

UPDATE #1: I found a few potential fixes when searching around. None of which have actually fixed the problem. Here is what I tried:

Potential Fix #1 (Unsuccessful)

Source: VMware update: Keyboard repeat problem solved

Added: divider=1- clocksource=acpi_pm to /etc/grub.conf

This didn't work, nor do I understand why it would work. But was worth a shot. Also this fix is for the Guest OS. My problem isn't related to the Guest, it's a problem with the Host which carries over to Guest OS's to include Windows and Linux VM's.

Potential Fix #2 (Unsuccessful)

Source: VMware and the fubar keyboard effect

This user had a different problem with the keyboard keys remapping randomly. However, I thought I'd try his fix to see if it would fix mine. It was not successful.

Add: xkeymap.nokeycodeMap = true to /etc/vmware/config (if it doesn't exist create it)

http://sgros.blogspot.com/2012/01/keyboard-autorepeat.html

UPDATE #2

So I ran a search to see what files and processes have a handle on XChangeKeyboardControl since that is the function which controls the keyboard auto repeat toggle. Here is the command I ran and my results:

PATH=$PATH:$HOME/bin:/usr/lib:/usr/lib64:/usr/share:/usr/include:/usr/libexec

IFS=:; find $PATH -type f -exec grep -lw XChangeKeyboardControl {} +  

My results were:

/usr/lib/vmware/bin/vmware-remotemks
" "                /vmware-vmx-debug  
" "                /vmware-vmx  
" "                /vmware-vmx-stats  
/usr/lib64/libX11.so.6.3.0  
" "       /gnome-settings-daemon-2.0/libkeyboard.so  
" "       /libxklavier.so.15.0.0  
/usr/share/vm/io/L-master/linuxop-cl1.vmdk  
/usr/include/X11/Xlib.h

I also ran the same command searching for "XAutoRepeatOff" and found this string in /usr/bin/expresskeys which is some sort of program that enables the use of PDA's and tablets style stylus's with the system. But its not running and isn't loaded at startup.

UPDATE#3

Note I verified I am using VMware Workstation 9.0. So all answers I've found that simply suggested upgrading to 8.0+ shouldn't really work.

Still no resolution to this problem.

share|improve this question
1  
Does IFS=:; find $PATH -type f -exec grep -l XChangeKeyboardControl {} + bring up any potential suspect? –  Stéphane Chazelas Jan 31 at 21:32
    
I'll check today. Thanks for your response. –  Kentgrav Feb 3 at 13:14
    
Yeah the only result I got was: /usr/bin/xset –  Kentgrav Feb 3 at 13:29
    
You could extend the grep to lib and libexec directories, and maybe the content of suspiscious packages. A grep -w xset might help in case that is done using a script invoking xset. –  Stéphane Chazelas Feb 3 at 14:24
    
I'll try that, however I am fairly certain this issue is VMware related. But I can't prove it. –  Kentgrav Feb 3 at 15:28

1 Answer 1

This is largely a guess, so take this all with a pinch of salt.

I encountered something that may be related where, when vmware was configured to 'grab' and 'release' the keyboard/mouse when the cursor moved in and out of the vmware window. I switched using a specific keypress to grab and release. Basically, in the preferences under keyboard/input control I unchecked most of the options. (I recall switching from the default control+alt to something else, because I suspected a window manager key binding was conflicting somehow.)

At the very, absolute worst, figure out how to add a global startup item that on your centos machine's that executes a script containing:

{ while sleep 2; do xset r on; done } &

Good luck!

P.S. When I had the similar problem, before I figured how to fix it, I would just ssh into my guest linux VMs or rdesktop into my guest windows VMs. In the end, I found that approach to be much nicer. Certainly made it gobs easier to move files back and forth using ssh ControlSockets or the rdesktop -r disk: redirection. Just a thought.

[Edit: Potentially worthwhile details I discovered.]

While poking around trying to find evidence proving GTK at fault, I used strings on the binaries to find a poorly documented configuration statement to increase MKS (mouse keyboard screen) logging. Then I discovered the following strings:

MKS Keyboard: Reset auto-repeat = %d
MKS Keyboard: Restore on-grab auto-repeat = %d
MKS Keyboard: Restore power-on auto-repeat = %d
MKS Keyboard: Auto-repeat = %d
MKS Keyboard: Saved power-on global_auto_repeat = %d
MKS Keyboard: On-grab global_auto_repeat = %d
MKS Keyboard: Saved on-grab global_auto_repeat = %d

Clearly, formatting for conditional log messages. Unfortunately, I've been unable to reproduce your problem so I can't test this myself, but near those log messages I found another string, I suspect a configuration file label. Try adding this to your ~/.vmware/preferences and your VM's .vmx file

mks.x.saveAutoRepeatEveryGrab = "TRUE"

I don't know what that statement causes and it may be the default condition - the very opposite may be necessary. These might enable the logging that would pin the problem down. I don't know if they belong in the VMX or in the preferences, so I would add them to both.

mks.x.printXError = "TRUE"
mks.dbg = "TRUE"
mks.mksDbg = "TRUE"

If you do discover what was causing this, please do let me know.

Good Luck.

share|improve this answer
    
Thanks for your answer. I will look into this sometime today. My students run a Windows XP VM as well as a RHEL6 VM on their CentOS 6 physical machine. The way our infrastructure is designed there really is no way around them having to run both VM's via VMWorkstation and using the GUI to perform their work. If all else fails I'll try the script you mentioned. I'll report back with results. Thanks again. –  Kentgrav Feb 14 at 16:27
    
Ok your first solution didn't work. Turned off everything there was to turn off in the preferences. Not 1 minute later it started toggling off again. So for now I am ad a dead end. Not sure how to fix this for good. Running a script that continuously runs xset r on may be my only option. Unless someone else finds a solution. I've searched everything I can on google with no luck. –  Kentgrav Feb 14 at 20:19
1  
I realize it's been a while, but, I noticed that some of the vmware UI issues were bugs in distro's X/GTK libraries while others were issues in vmware's use of them. Check the bin/launcher.sh script in your vmware install - probably under /usr/lib/vmware/ . There's an environment variable VMWARE_USE_SHIPPED_GTK which has three possibilities, "forced", "yes", and "no". Please consider trying both forced and no. It's possible centos is doing something vmware doesn't expect or vice-versa. It's a long shot, but, might help. –  etherfish Feb 17 at 19:42
    
One other thing, the gnome accessibility plugin a11y-keyboard apparently caused xset r to get stuck on, break xtrs, x11vnc, maya, as well as vmware. Two quick thoughts, log in with a different environment/window-manager than you normally use. If the problem disappears, it's likely something related to that. Also, check the vmware.log (inside the virtual machines directory, with the vmdk and vmx), /var/log/Xorg.0.log, ~/.xsession-errors. I think xev will monitor global keyboard changes. I'd tee that to a file. –  etherfish Feb 17 at 20:13
    
Awesome, thanks for the tips and information! I will try both these things. I haven't found a definitive solution to fix the core problem yet. However, your answer/temp fix of the while loop has more or less alleviated the problem till I can find a permanent solution. So I will award the bounty. –  Kentgrav Feb 18 at 14:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.