Como ativar permanentemente o Autorepeatar do Teclado nas instâncias do VMware do CentOS 6?

Question

No meu laboratório, temos cerca de 40-50 máquinas, todas clonadas com a mesma imagem do CentOS 6.

Por algum motivo, a função de repetição automática do teclado decide desligar-se aleatoriamente. Normalmente, apenas temos alunos que digitam xset r on , o que irá ativá-lo. No entanto, durante todo o dia e intervalos aleatórios, ele se desliga novamente. Parece não haver nada em comum com as vezes em que o faz ou com as ações que estavam sendo executadas no sistema no momento em que foi desativado. Recentemente, ele permanecerá desligado mesmo depois de digitar xset r on várias vezes seguidas como raiz e usuário normal.

É muito chato e eu não consigo imaginar a vida de mim para permanentemente ligar isso. Minha única solução real que pensei foi criar um trabalho cron que o transformava a cada minuto, mas isso só parecia funcionar temporariamente. Horas depois que ele começa a rodar, ele simplesmente se apaga novamente e o script parece ser declarado nulo e sem efeito. Eu tentei adicioná-lo para iniciar scripts, bash_profile, xinit scripts etc. Mas não vai ficar ligado.

O que pode estar causando isso e como posso corrigi-lo permanentemente?

Encontrei outros com problemas semelhantes que parecem acreditar que tem algo a ver com o driver de mouse e teclado da VMware, que permite a integração perfeita de desktops. Qual poderia ser o caso desde que nós executamos o VMware Workstation nas máquinas. Mas às vezes isso acontece mesmo quando uma máquina virtual não está em execução, mesmo depois de uma nova reinicialização.

UPDATE # 1: Encontrei algumas possíveis correções ao pesquisar. Nenhum dos quais realmente resolveu o problema. Aqui está o que eu tentei:

Correção de potencial nº 1 (sem sucesso)

Fonte: Atualização da VMware: problema de repetição de teclado resolvido

Adicionado: divider=1- clocksource=acpi_pm a /etc/grub.conf

Isso não funcionou, nem entendo por que isso funcionaria. Mas valeu a pena um tiro. Além disso, essa correção é para o sistema operacional convidado. O meu problema não está relacionado com o Guest, é um problema com o Host que é transferido para o Guest OS para incluir as VMs do Windows e Linux.

Correção de potencial nº 2 (sem sucesso)

Fonte: VMware e o efeito de teclado fubar

Este usuário teve um problema diferente com as teclas do teclado remapeando aleatoriamente. No entanto, pensei em testar sua correção para ver se isso consertaria a minha. Não foi bem sucedido.

Adicione: xkeymap.nokeycodeMap = true a /etc/vmware/config (se não existir crie-o)

link

UPDATE # 2

Então, eu corri uma pesquisa para ver quais arquivos e processos têm um identificador no XChangeKeyboardControl, já que essa é a função que controla a alternância de repetição automática do teclado. Aqui está o comando que eu corri e meus resultados:

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

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

Meus resultados foram:

/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

Eu também executei o mesmo comando pesquisando por "XAutoRepeatOff" e encontrei essa sequência em /usr/bin/expresskeys , que é um tipo de programa que permite o uso da caneta stylus do PDA e dos tablets no sistema. Mas não está sendo executado e não é carregado na inicialização.

UPDATE # 3

Observe que estou usando o VMware Workstation 9.0. Então, todas as respostas que encontrei que simplesmente sugeriram a atualização para 8.0+ não devem funcionar.

Ainda não há resolução para este problema.

    

Answer 1

Isso é em grande parte um palpite, então leve isso tudo com uma pitada de sal.

Encontrei algo que pode estar relacionado onde, quando o vmware foi configurado para 'agarrar' e 'liberar' o teclado / mouse quando o cursor entrou e saiu da janela do VMware. Eu troquei usando uma tecla específica para pegar e soltar. Basicamente, nas preferências sob controle de teclado / entrada, desmarcamos a maioria das opções. (Eu me lembro de mudar do controle padrão + alt para outra coisa, porque eu suspeitava que uma ligação de chave do gerenciador de janelas estava em conflito de alguma forma.)

No pior dos casos, descubra como adicionar um item de inicialização global em sua máquina centos que execute um script contendo:

{enquanto dorme 2; do xset r on; feito} &

Boa sorte!

P.S. Quando eu tive o problema semelhante, antes que eu descobrisse como consertá-lo, eu apenas usava ssh em minhas VMs guest linux ou rdesktop em minhas VMs de janelas convidadas. No final, achei essa abordagem muito mais agradável. Certamente tornou mais fácil mover os arquivos para frente e para trás usando o ssh ControlSockets ou o rdesktop -r disk: redirection. Apenas um pensamento.

[Editar: Detalhes que valem a pena que eu descobri.]

Enquanto pesquisava tentando encontrar evidências que provassem a falha do GTK, usei strings nos binários para encontrar uma declaração de configuração mal documentada para aumentar o registro de MKS (tela do teclado do mouse). Então eu descobri as seguintes 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

Claramente, formata para mensagens de log condicionais. Infelizmente, não consegui reproduzir o seu problema, por isso não posso testar isso sozinho, mas perto dessas mensagens de log eu encontrei outra string, suspeito de um rótulo de arquivo de configuração. Tente adicionar isso ao seu ~ / .vmware / preferences e ao arquivo .vmx da sua VM

mks.x.saveAutoRepeatEveryGrab = "TRUE"

Eu não sei o que essa afirmação causa e pode ser a condição padrão - o oposto pode ser necessário. Isso pode ativar o registro que reduziria o problema. Não sei se pertencem ao VMX ou às preferências, por isso gostaria de adicioná-las a ambos.

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

Se você descobrir o que estava causando isso, informe-nos.

Boa sorte.