A consola remota com caixa a alternar sozinha — escreves era e o ecrã mostra ErA, ligas o capslock e o guest responde com minúsculas, ou pior: numa consola de recuperação o root não entra porque a password ficou toda invertida. O desencontro nasce da forma como as consolas de VMware e de VNC tratam a tecla: mandam eventos de tecla, nunca o estado. A cura nas VMs que se gerem por consola desligar a tecla no keymap do guest (caps:none) e ficar só com o Shift — a única tecla de maiúsculas sem estado. O cenário que motiva o artigo: VM Ubuntu sem ambiente gráfico na consola do VMware.

TL;DR — desliga o CapsLock e fica com o Shift

O CapsLock é um interruptor só de hardware, sem feedback para o software. Entre o teu teclado e o guest há dois estados de caixa independentes — e a consola remota manda eventos de tecla, não estados. Para as VMs que se gerem por consola: (1) confirma o estado num campo visível antes de qualquer password, (2) usa SSH para trabalho normal, (3) desliga o CapsLock no guest — XKBOPTIONS="caps:none" no /etc/default/keyboard + sudo dpkg-reconfigure console-setup (headless) ou gsettings (com GNOME), (4) a partir de então, Shift para tudo.

1. Porque é que o CapsLock dessincroniza

O CapsLock não é tecla nem comando: é um interruptor. O LED do teu teclado acende por uma alteração eléctrica física no próprio dispositivo — nenhum programa consegue perguntar ao teclado "qual é o teu estado" — cada aplicação só sabe o estado que ela própria registou. A base de conhecimento da Broadcom resume isto à letra nas palavras: a tecla não fica registada no software e é um toggle só de hardware — por isso é que a inversão acontece também ao nível de qualquer programa que tenha acesso ao teclado (KB 303391).

Com uma consola remota somam-se três protagonistas: o teu teclado físico, o canal de input (o mks da VMware, ou o VNC do browser), e o estado de caixa interno do guest. O canal manda eventos de tecla — "CapsLock premido", "CapsLock solto" — nunca o estado absoluto "caps está ligado". Cada lado aplica o toggle quando recebe o evento, e o desencontro nasce em qualquer mudança de foco: a janela da consola liberta o teclado com o CapsLock activo, outra aplicação o processa, e o guest perdeu o toggle — a partir de certo ponto os dois estados ficam em luta: invertidos de forma estável, ou alternando cada vez que o canal entrega o evento a um lado e não ao outro.

Teoria — Shift nunca dessincroniza

O Shift é momentâneo: transforma a letra por baixo enquanto está premido e não guarda estado nenhum de um evento para o outro. Não há latch que dessincronizar — é por isso que a primeira medida de qualquer consola é Shift para maiúsculas e CapsLock para nunca.

2. Sintomas e diagnóstico

Sintoma O que se está a passar
Invertido de forma estável (LED aceso, guest em minúsculas — ou o contrário) Um toggle ficou só num lado (mudança de foco, outra app, auto-repeat solto)
A caixa alterna dentro da mesma palavra (era → ErA) O toggle chega em duplicado ou desfasado — browser + mks + guest processam cada um o seu — típico em VM Linux guest com remapeamento XKB próprio do CapsLock (em seguida no artigo)
Colar texto no noVNC sai com a caixa exactamente ao contrário A colagem do VNC sintetiza a caixa letra a letra e o estado invertido do guest vira cada carácter

O diagnóstico tem duas regras de ouro. Primeira: testa sempre a caixa num campo visível antes de uma password — o campo do username, por exemplo. A própria KB da Broadcom regista o caso de admin que não conseguiu entrar como root num ESXi 9 recém-instalado porque o estado do teclado na consola remota invertia a password — campo mascarado, ninguém vê, e a password do root ficou diferente do que foi escrito. Segunda: isola o lado guest por SSH.

ssh [email protected]
duarte@vm-ubuntu:~$ grep -n "caps" </dev/null || true

O SSH serve aqui de discrimininar onde mora o problema — abres uma sessão SSH e escreves normalmente. Se por SSH a caixa se mantém correcta, o sistema está são e o desencontro pertence ao canal da consola (mks/VNC); se por SSH também alternar, o keymap do próprio sistema ficou remapeado — e a secção 4 resolve. Para ver o mesmo comportamento dentro do canal da consola, muda de tty via Send Key → Ctrl+Alt+F2 (o atalho digitado directo no teclado fica-se pelo PC anfitrião) e testa a escrita à letra por letra.

3. O realinhamento rápido

Se estás no VMRC (VMware Remote Console): o menu Virtual Machine → Send Key → Caps Lock manda um toggle só ao guest, sem tocar no teu teclado físico — é a solução oficial da KB e o realinhamento num clique.

Se estás na consola do browser (HTML5 ou VNC), o protocolo de reset completo: (1) escreve um carácter na consola e alterna o CapsLock até o guest confirmar minúsculas — a partir de aí ignora o LED do teu teclado, o guest é que manda, e fica no Shift — o CapsLock já cumpriu o papel de diagnóstico, (2) fecha a janela da consola por completo (a aba toda, não só o foco) — é o que termina a sessão de mks/VNC, (3) desliga o CapsLock físico (LED off), (4) reabre a consola. O realinhamento alinha os dois lados mas não é cura: se na consola voltar a premir o CapsLock, o próximo desencontro de foco repete o problema. A partir do momento em que o guest confirma minúsculas, a disciplina passa a ser uma só — o Shift — até o CapsLock estar desligado na secção 4. E se o estado voltar a enroscar, o reset repare-se, sempre pelo mesmo caminho.

4. Remover o CapsLock na VM Ubuntu

Esta é a recomendação deste artigo: nas VMs que se gerem por consola remota, o CapsLock é um risco sem contrapartidas. As duas formas de o desactivar cobrem os dois mundos do Ubuntu.

VM headless (sem ambiente gráfico) — keymap do VT:

sudo nano /etc/default/keyboard
# XKBOPTIONS="caps:none"
sudo dpkg-reconfigure console-setup
nano a editar o ficheiro /etc/default/keyboard no tty da VM Ubuntu: XKBOPTIONS="caps:none" marcado, com XKBMODEL pc105 e layout pt

O ficheiro /etc/default/keyboard na VM Ubuntu (consola do VMware), com a opção caps:none aplicada ao keymap do VT

O console-setup é o serviço que constrói o keymap para as consolas de texto (os tty) no Ubuntu — as opções de /etc/default/keyboard servem sem ambiente gráfico nenhum. A opção caps:none é a variante oficial do xkeyboard-config para desligar o comportamento de bloqueio (a lista completa de variantes caps: vem na doc do xkb — caps:swapescape (troca pelo Esc), caps:escape (Esc adicional), caps:ctrl_modifier (Ctrl adicional)). dpkg-reconfigure console-setup recompila o keymap do VT e aplica na hora, sem reboot. De agora em diante a tecla CapsLock é ignorada nos tty — escreve com Shift, que funciona sempre.

VM com GNOME (sessão gráfica) — opção XKB no dconf:

gsettings get org.gnome.desktop.input-sources xkb-options
# ex.: @as [] (vazio)
gsettings set org.gnome.desktop.input-sources xkb-options "['caps:none']"

Faz efeito imediatamente, sem logout, e sobrevive ao reboot porque fica gravado no dconf. Cuidado com a sobreposição: o gsettings set substitui a lista inteira — se já tiveres outras opções aí, junta a nova à lista em vez de a apagar (o primeiro comando é exactamente esse diagnóstico). Em sessão Wayland a variante via setxkbmap não serve (o setxkbmap só mexe no Xorg) — o gsettings é o caminho certo nos dois.

Para o caso de precisares de escrever tudo em maiúsculas de uma vez: sudo apt install xdotool e depois xdotool key Caps_Lock — sintetiza o toggle dentro do próprio guest, sem passar pela consola nem pelo teu teclado, e é uma solução documentada na comunidade para manter o hábito sem o risco do hardware.

5. Consolas de desktop: Workstation e Fusion

Nos produtos de desktop da VMware há uma chave própria para o problema: a sincronização dos LEDs do teu teclado físico com o estado do guest.

mks.keyboard.syncLEDs = "TRUE"

No Workstation vai no .vmx da VM (com a máquina desligada). No Fusion vai no ~/Library/Preferences/VMware Fusion/config, criado de raiz se não existir — e a opção tem um histórico antigo: na versão 1.1.1 do Fusion esse código foi desligado por um conflito com drivers de teclado Logitech, e é a própria Broadcom quem documenta a linha acima para o voltar a ligar. A leitura prática: com syncLEDs activa, o LED do teclado segue o estado do guest — a caixa continua a poder desencontrar-se, mas o LED deixa de mentir em sentido contrário.

6. noVNC (Proxmox) e outros pipes VNC

O Proxmox serve as consolas das VMs e dos LXC por noVNC — e o VNC do browser partilha da mesma limitação: manda o evento de tecla premida, não o estado absoluto. O sintoma é o mesmo (invertido da primeira vez que tocas no CapsLock, e o texto colado a sair com a caixa ao contrário), e a cura é o mesmo protocolo de reset da secção 3: confirma minúsculas no guest, fecha a consola toda, desliga o físico, reabre. A grande diferença: o noVNC não tem Send Key para o CapsLock — o reset completo é a via. No Proxmox o mesmo sintoma aparece nas consolas SPICE, que têm tratamento de teclado próprio e são uma alternativa prática por isso mesmo.

7. A disciplina que fecha o tema

  • Shift para tudo — na consola da VM, no RDP, no DCUI do ESXi: maiúsculas com Shift e o tema morre aí. A tecla Shift não guarda estado, por isso não há nada que dessincronizar.
  • Passwords: teste no campo visível — o username primeiro, sempre. O caso do root ESXi 9 que a KB documenta só aconteceu por ninguém ter testado antes do campo mascarado.
  • Trabalho normal por SSH — a consola da VM é para as situações em que a rede/SSHD falham — o SSH não passa pelo mks e não tem este problema.
  • VMRC em vez da consola do browser para VMs de produção — tem Send Key, lida melhor com o teclado e é a consola recomendada para sessões longas.
  • CapsLock desligado nas VMs que geris — os dois comandos da secção 4 fazem-no em um minuto, e a partir daí o risco simplesmente não existe.

A conclusão que a experiência ditou: o CapsLock é um interruptor desenhado para o mundo físico — o remoto não sabe ler interruptores, só eventos. Quem gere VMs por consola remota retira-lhes o papel (caps:none) e passa a viver com a tecla que não sabe mentir: o Shift.

Artigos Relacionados

Fontes Oficiais