Voxtype no Wayland 2026: por que ditado por voz Linux parou

O voxtype no Wayland resolve um problema que todo guia de “como migrar pra Wayland” esquece de mencionar: o script de automação de teclado que você usava com xdotool no X11 vai simplesmente parar de escrever, sem erro, sem log, sem explicação. Isso acontece porque o Wayland foi desenhado pra impedir exatamente esse tipo de acesso. É nesse buraco que entra o voxtype, um projeto open source em Rust que trata ditado por voz no Wayland de um jeito que respeita a arquitetura nova em vez de tentar gambiarrar em cima dela. Esse texto explica por que seu app de ditado quebrou, qual mecanismo legítimo o voxtype usa pra contornar isso e, principalmente, em qual compositor ele realmente funciona hoje, antes de você perder uma tarde instalando algo que não vai digitar uma letra sequer na sua máquina.

Por que seu script de ditado parou de funcionar quando você saiu do X11 (e não é bug seu)

No X11, qualquer cliente gráfico podia pedir pro servidor X injetar eventos de teclado e mouse em qualquer janela do sistema. Era assim que xdotool existia: ele não “fingia” digitar, mandava o X server gerar eventos sintéticos de tecla, sem pedir permissão a ninguém. Ótimo pra automação. Péssimo pra segurança, porque o mesmo mecanismo que deixa seu app de ditado escrever por você também deixa um malware capturar tudo que você digita em qualquer janela, inclusive senha de banco.

Um cenário comum é o dev que roda i3 com X11 há anos, tem um atalho que chama um script baseado em xdotool type, migra pro Hyprland porque viu print bonito no Reddit, e descobre que o script simplesmente não digita mais nada. Sem mensagem de erro, sem crash: o processo roda e termina normalmente, só que o texto nunca aparece no cursor. Isso não é falha de configuração, é o Wayland fazendo exatamente o que foi projetado pra fazer, que é isolar cada cliente gráfico do resto do sistema. Nenhum compositor Wayland sério (Mutter do GNOME, KWin do KDE, wlroots por trás de Sway, Hyprland e River) expõe um canal livre de injeção de input pra qualquer processo. Isso precisa ser autorizado explicitamente, por protocolo específico. É aí que mora a diferença entre um app de ditado mal feito e um app de ditado que simplesmente não tem outra escolha a não ser pedir essa permissão do jeito certo.

O protocolo por trás do voxtype: o que virtual-keyboard-unstable-v1 permite e o que ele deliberadamente bloqueia

O Wayland não tem um substituto direto, um pra um, do xdotool. Existe uma família de protocolos de extensão com escopo bem delimitado, e o relevante aqui é o virtual-keyboard-unstable-v1, mantido no repositório wlr-protocols e implementado nativamente pelos compositores baseados em wlroots (Sway, Hyprland, River). Ele permite que um cliente autorizado crie um teclado virtual e envie eventos de tecla pro compositor processar como se viessem de hardware real, só isso. Não deixa o cliente ler o conteúdo de outras janelas, não deixa capturar tudo que é digitado globalmente, e a autorização geralmente passa por colocar o usuário no grupo input do sistema ou por o compositor ter uma lista de permissões explícita.

É isso que a camada de digitação do voxtype usa por baixo dos panos. Pelo README do projeto, o voxtype prioriza “Wayland-first typing via wtype”, e wtype é justamente a ferramenta de linha de comando que implementa esse protocolo pra injetar texto no compositor ativo. Se wtype não estiver disponível ou o compositor não suportar bem o protocolo, o voxtype documenta uma cadeia de fallback: dotool, depois ydotool, depois clipboard. Quando nada mais funciona, ele copia o texto transcrito pra área de transferência e deixa você colar manualmente. Um fallback honesto: não finge que resolveu o problema, admite o limite.

Dá pra reparar num detalhe interessante: o README também cita “evdev fallback for X11” e instrui adicionar o usuário ao grupo input pra usar o hotkey embutido em ambiente X11 puro. Isso confirma que o caminho elegante via protocolo Wayland é tratado como prioridade de arquitetura, e X11 vira caminho secundário de compatibilidade, o inverso do que a maioria dos apps de automação ainda faz.

Compositor por compositor: o que funciona de verdade em GNOME, KDE e Hyprland hoje

Pelo README do voxtype, dá pra montar um mapa realista de suporte. O projeto documenta um bloco de keybinding nativo pra Hyprland, Sway, River e KDE, mas não traz um exemplo equivalente de atalho pra GNOME, mesmo listando GNOME entre os ambientes com “compositor keybindings everywhere”. Isso bate com algo já conhecido na comunidade Wayland: Mutter historicamente trata protocolos de input virtual de forma mais restrita que os compositores wlroots, então a experiência tende a exigir mais configuração manual.

Compositor	Keybinding documentado no README	Observação
Hyprland	bind = SUPER, V, exec, voxtype record start / bindr pra stop	Push-to-talk nativo via hold/release
Sway	bindsym --no-repeat $mod+v / --release	Mesmo modelo hold/release
River	riverctl map normal Super V spawn	Mesmo modelo hold/release
KDE Plasma (KWin)	Atalho customizado via System Settings chamando voxtype record toggle	Sem suporte a key-release, por isso é obrigatório usar modo toggle
GNOME	Citado como compatível, sem bloco de bind específico no README	Depende mais de configuração manual
X11 / XWayland	Hotkey embutido (ScrollLock) via grupo input	Caminho de fallback, não o caminho principal

Um caso recorrente é o usuário que depende de ditado por questão de acessibilidade e tenta usar a mesma configuração entre GNOME e KDE esperando portabilidade total, e esbarra em dois modelos de permissão de input diferentes: um exigindo toggle (KDE, porque KWin não reporta evento de soltar tecla) e outro aceitando hold/release nativo. Outro cenário frequente é tentar rodar uma ferramenta de ditado antiga via XWayland dentro de uma sessão Wayland: o foco de janela funciona pela metade, porque o compositor trata a janela XWayland como um cliente isolado, e a captura de tecla simplesmente não chega onde deveria. Isso não é peculiaridade do voxtype, é o preço de rodar um app pensado pra X11 num ambiente híbrido.

Push-to-talk como decisão de arquitetura, não feature de conveniência

O padrão do voxtype é “hold to talk”: segura a tecla (ScrollLock por padrão), fala, solta, o texto aparece. Parece estética, mas no contexto Wayland é decisão técnica. Como o protocolo de teclado virtual não dá acesso livre e contínuo de captura global, depender de hold/release é o jeito mais previsível de delimitar exatamente quando o app deve escutar e quando deve parar, sem precisar de um daemon ficando de olho em tudo o tempo todo.

Por isso o KDE é o caso mais instrutivo do README: como o KWin não reporta evento de soltar tecla pra esse tipo de atalho customizado, o projeto é obrigado a trocar pra modo toggle (aperta uma vez pra começar, aperta de novo pra parar) só nesse compositor. Não é o voxtype sendo inconsistente, é o voxtype se adaptando à limitação real de cada compositor e documentando a diferença em vez de fingir que é tudo igual.

O que o voxtype não resolve: idioma, latência e a pegadinha de rodar em pt-BR

O README lista nove engines de transcrição (Whisper, Parakeet, Moonshine, SenseVoice, Paraformer, Dolphin, Omnilingual, Cohere e OpenVINO Whisper) e promete cobertura ampla de idiomas pelos engines multilíngues, além de CJK completo. O que o README não traz é uma tabela de acurácia por idioma, muito menos um número específico pra português brasileiro. Essa é uma lacuna real de documentação, não um defeito escondido: o projeto afirma rodar local, sem nuvem e sem telemetria, e isso dá pra verificar no próprio código por ser MIT. Mas a qualidade de reconhecimento em pt-BR vai variar conforme o engine escolhido, e isso quem decide testar vai ter que validar na prática, porque não há dado oficial do projeto sobre isso.

Sobre velocidade, o README faz promessas de bom desempenho rodando na CPU. Não vou repetir número de benchmark aqui, porque não tenho como validar a metodologia por trás: é claim do projeto, não resultado que eu confirmei. O que dá pra afirmar com segurança, porque está documentado, é que o carregamento de modelo é dinâmico por engine (carrega sob demanda, descarrega quando ocioso), o que importa mais pra quem tem pouca RAM do que qualquer número de velocidade.

Vale instalar agora ou esperar o projeto amadurecer

O repositório é licenciado em MIT e tem empacotamento documentado pro AUR, .deb, .rpm e Homebrew no macOS, sinal de que já saiu da fase de experimento de fim de semana, mas ainda é jovem o suficiente pra ter arestas, principalmente fora do eixo Hyprland/Sway. Se você usa Hyprland, Sway ou River, o caminho é o mais trilhado pelo próprio README, com bloco de keybinding pronto. Se usa KDE, funciona, mas exige o ajuste pro modo toggle, não é plug-and-play. Se usa GNOME, a documentação é mais rasa e você provavelmente vai precisar investigar além do README. E se depende de ditado por acessibilidade em ambiente misto X11/XWayland, esse não é o momento de trocar de ferramenta sem antes validar o comportamento no seu compositor específico: o risco de frustração é real.

Pra quem é dev ou já convive com configuração manual de dotfiles, dá pra instalar hoje sem medo. Pra quem quer “só funcionar” sem tocar em config.toml, talvez valha esperar o suporte a GNOME ficar tão documentado quanto o de Hyprland.

Fontes consultadas

Este artigo se baseou na leitura do repositório peteonrails/voxtype no GitHub, incluindo README, trecho de instalação e seção de keybindings por compositor, e em conhecimento público sobre o protocolo virtual-keyboard-unstable-v1, parte da especificação de wlr-protocols usada por compositores wlroots como Sway, Hyprland e River, e implementada por ferramentas como wtype. Não há, até a data desta publicação, benchmark independente de acurácia por idioma ou latência que eu tenha conseguido verificar além das afirmações do próprio projeto.