Será que finalmente vai dar para usar Wayland em 2026?

• Wayland é a pilha gráfica sucessora do X11, iniciada em 2008, mas o autor avalia que não conseguiu usá-la corretamente em seu sistema por 18 anos
• Em 2025, com o suporte a GBM e explicit sync nos drivers da nVidia, a execução básica passou a ser possível, mas a transição completa ainda é difícil por causa de problemas como a falta de suporte a TILE em monitor 8K
• Houve avanços técnicos importantes no Sway 1.11 e no wlroots 0.19.0, mas ainda existem vários obstáculos no uso real, como latência de entrada, glitches gráficos e problemas de escala no Xwayland
• Aplicativos principais como Chrome e Emacs ainda apresentam problemas de queda de desempenho, diferenças de renderização e instabilidade na aceleração por hardware
• No geral, o Wayland “finalmente entrou no radar para uso prático”, mas para trabalho diário a combinação X11/i3 ainda é mais estável

---

Contexto histórico do Wayland

• O Wayland é um projeto sucessor do servidor X (X11, Xorg), iniciado em 2008, e o autor desenvolveu em 2009 o gerenciador de janelas em mosaico i3 para X11
• No início, só era possível executar o compositor de demonstração Weston, e o GNOME passou a oferecer suporte ao Wayland em 2014, seguido depois pelo KDE
• Aplicativos importantes como Firefox, Chrome e Emacs só podiam usar Wayland por meio de flags experimentais
• As GPUs nVidia por muito tempo não funcionaram no Wayland ou causavam erros gráficos, e os problemas de compatibilidade com monitores 8K também persistiram
• Recentemente, distribuições importantes como Fedora, RHEL e Asahi Linux passaram a adotar o Wayland como pilha de desktop padrão ou única, aumentando a pressão pela migração

Configuração do ambiente de execução do Wayland

• O sistema de testes usa uma nVidia RTX 4070 Ti (PC do rack) e uma RTX 3060 Ti (PC principal)
• Desde o driver nVidia 495 (2021) foi adicionado suporte a GBM, e o recurso explicit sync foi implementado no Sway 1.11 (2025) e no wlroots 0.19.0
• No entanto, por causa da falta de suporte à propriedade TILE no monitor 8K Dell UP3218K, no Sway a tela é mostrada dividida em duas
  • Com um patch de EBADBEEF e a análise do Claude Code, foi descoberto um bug na propriedade SRC_X do DRM, e com um patch de contorno foi possível exibir a tela inteira
• O GNOME oferece suporte a TILE, mas ocorre tearing severo no centro da tela
• No ambiente NixOS 25.11, foram configurados em paralelo GDM, GNOME e Sway, além de ferramentas exclusivas de Wayland como foot, fuzzel e wayland-utils

Resultados do experimento: ambiente Sway

• O Sway é compatível com a maior parte da configuração do i3, e o autor ajustou o layout de teclado NEO e as configurações de entrada e saída
• Principais problemas:
  • Latência no ponteiro do mouse e movimento pouco suave (suspeita de falta de suporte a cursor por hardware da nVidia)
  • Impossibilidade de escalar apps em Xwayland, resultando em exibição borrada ou com ampliação dupla
  • Alguns atalhos são executados duas vezes (ghost key press)
• Em apps GTK, o problema inicial de tamanho excessivo da fonte foi resolvido com gsettings reset
• Como o GTK3 usa apenas configurações do dconf, é preciso definir font-name no dconf para que a renderização fique consistente
• O swaylock, diferente do i3lock, entra em estado de “tela vermelha” ao encerrar e só pode ser liberado com SIGUSR1
• Ferramentas de automação baseadas em i3 IPC têm compatibilidade parcial devido a diferenças no caminho do socket, processos remanescentes e falta de suporte à restauração de layout

Teste dos principais aplicativos

• O terminal foot é leve, mas foram encontrados alguns problemas de diferença de cores, tratamento de Ctrl+Enter, seleção de URL e cores no screen
• O Emacs na versão padrão roda em Xwayland e aparece borrado, enquanto a versão pgtk apresenta latência de entrada e diferenças no espaçamento entre caracteres
• O Chrome perde a aceleração por hardware por causa de falhas no processo de GPU e, ao restaurar janelas, não mantém as informações do workspace anterior
• O compartilhamento de tela funciona via xdg-desktop-portal-wlr, mas há problemas como falta de suporte ao compartilhamento por janela e transmissão em baixa resolução
• Ao ativar a escala de saída, ocorrem glitches em que o conteúdo das janelas se desloca momentaneamente ou fica borrado
• As notificações do dunst e o rofi (2.0.0 ou superior) funcionam normalmente, e a ferramenta de captura de tela grim tem uma função de seleção de janela pouco prática

Conclusão: possibilidade de usar Wayland em 2026

• A sessão Wayland/Sway pela primeira vez se aproxima de um nível utilizável na prática, mas ainda há muitos defeitos
• O ambiente X11/i3 oferece baixa latência de entrada no nível de 763μs e estabilidade total
• Ao migrar para Wayland, surgem glitches gráficos, latência de entrada e queda de desempenho em aplicativos principais
• Condições necessárias para uso diário:
  • Correção da duplicação de teclas e dos glitches de transição no Sway
  • Estabilização da aceleração por hardware no Chrome e suporte à restauração de janelas
  • Melhoria da latência de entrada e da renderização no Emacs (pgtk)
• Em conclusão, o Wayland ainda não está pronto para uso diário de trabalho, e o autor pretende continuar usando X11/i3

[GN⁺]

Comentários do Hacker News

• Wayland é apenas um protocolo, então existem várias implementações (GNOME, KDE, wlroots etc.)
  O Xorg tinha uma estrutura em que o desktop era construído sobre uma única base sólida, mas no Wayland cada desktop acaba reinventando a roda
  O Weston é bom como referência, mas inadequado para uso diário
  Acho que precisamos de uma biblioteca padrão que todos os desktops possam usar em comum. O wlroots tenta cumprir esse papel, mas não parece que GNOME ou KDE vão migrar tão cedo
  • Acho que o X.org encontrou o nível certo de abstração. O WM não precisava lidar diretamente com entrada ou saída, e por isso havia simplicidade e boa eficiência energética. O Wayland parece não ter aprendido as lições do X11
  • Eu já usei Sway e Hyprland, e agora uso niri. Sway e niri, baseados em wlroots, são bem decentes, mas ainda têm muitos bugs aleatórios. Problemas de ponteiro em apps Wine, travamentos no compartilhamento de tela, problemas com cor de 10 bits etc. Talvez fique estável por volta de 2027, mas para 20 anos de desenvolvimento parece ter sido ineficiente
  • KDE e GNOME têm cada um sua própria implementação de xdg-desktop-portal, o que gera problemas de compatibilidade. Se for baseado em wlroots, você precisa usar xdg-desktop-portal-wlr; se for Hyprland, xdg-desktop-portal-hyprland.
    A própria estrutura do Wayland, como no documento oficial de arquitetura, parece boa em teoria, mas na prática faltam muitos recursos no nível do protocolo
  • Na verdade, o X também era um protocolo, mas como havia uma implementação única chamada X.org, havia menos confusão. Não é tecnicamente impossível ter uma biblioteca padronizada no nível do wlroots
  • Os desenvolvedores do Wayland originalmente o projetaram como um protocolo só de exibição. Esperavam que protocolos de entrada ou de gerenciamento de janelas fossem feitos por outros grupos, mas isso não deu certo.
    No fim, qualquer tentativa de substituir o Wayland agora pode acabar desperdiçando esforço ao recriar partes que já estão maduras
• Ainda não sei por que eu deveria usar Wayland. O Xorg é estável, e a maioria dos textos de solução de problemas começa com “se estiver usando Wayland, volte para o Xorg”.
  Provavelmente a adoção só vai aumentar de verdade quando as distribuições o impuserem como padrão, como aconteceu com o systemd
  • O usuário comum não tem muito motivo para trocar. Mas o Wayland lida bem com pontos fracos do X11, como escala em múltiplos monitores.
    Do ponto de vista do GNOME e do KDE, uma grande motivação para migrar é reduzir o fardo de continuar mantendo o X11.
    Acho que a meta deste ano é chegar a um nível “sem desvantagens”
  • O Wayland parece oferecer desempenho mais fluido, mas ainda preciso usar Xorg por causa de alguns apps.
    O GNOME 49 no Arch e no Ubuntu já removeu o Xorg do padrão, e o KDE deve seguir o mesmo caminho em breve. A era do Xorg está acabando
  • Antigamente eu precisava editar o xorg.conf manualmente, mas depois de testar Wayland experimentalmente no Ubuntu, migrei de vez. Talvez por causa da GPU AMD, funciona de forma suave e sem problemas
  • A vantagem do Wayland é o fractional scaling
  • Eu preciso usar ferramentas como x2x, xev e xdotool, mas isso é impossível por causa do modelo de segurança do Wayland, então continuo no Xorg
• É um equívoco dizer que a Nvidia rejeitou a API GBM do Wayland. O GBM era uma API não oficial interna do Mesa, então a Nvidia não podia implementá-la diretamente.
  Por isso, ela propôs uma alternativa neutra em relação ao fornecedor, chamada EGLStreams.
  Na verdade, o problema foi que o lado do freedesktop não oferecia uma estrutura em que o driver da Nvidia pudesse funcionar
  • Mas então fica a dúvida de como o Mesa, sendo um projeto open source, pode depender de uma API fechada
• Eu uso Wayland no Gnome há anos e não tenho problema nenhum.
  Claro que isso talvez também se deva ao fato de eu não usar Nvidia e ter hardware simples, mas quero enfatizar que o Wayland pode funcionar bem
  • Comigo é a mesma coisa: funciona perfeitamente no Sway (2016) e no KDE Plasma 6. Só rodo jogos da Steam via XWayland. A combinação AMD/Intel é muito mais estável
  • Mesmo com hardware Nvidia, ultimamente ele funciona de forma bem suave. Antes engasgava, mas agora me parece melhor que o Xorg.
    Ainda assim, coisas como controle de posição das janelas ou navegação entre outros apps precisam ser contornadas com extensões do Gnome Shell
  • Como na história de quem não percebia a cintilação de monitores CRT antigamente, esses pequenos incômodos do Wayland — como sensação de entrada ou diferença nas fontes — podem ser percebidos de forma diferente por cada pessoa
• Eu uso Wayland baseado em wlroots/swaywm há alguns anos, e até eGPU funciona perfeitamente.
  Mas isso talvez seja porque meu hardware é AMD. A vida é curta demais para desperdiçá-la com problemas da Nvidia
  • Em compensação, no gráfico integrado da Intel o sway travava com frequência, então voltei para i3+Xorg
  • Usei Nvidia por 23 anos e nunca tive grandes problemas. No fim, acho que é uma questão de escolha pessoal
  • Antes eu também usava bem com Nvidia, e com o patch TILE até tela 5K funcionava direito.
    Migrei para Wayland por causa do suporte a escala em múltiplas saídas, mas depois também voltei atrás
• Migrei recentemente do Windows para Linux, e antes isso era impossível por causa da ausência de fractional scaling.
  Com Wayland isso foi resolvido, o que é uma grande melhora. Mas nem todas as distribuições usam Wayland por padrão, então escolhi o Ubuntu.
  O Firefox via Snap não usava aceleração de hardware, então isso foi um pouco incômodo
  • Para mim também, o fractional scaling é o ponto que mais faz falta no Linux.
    No macOS, mesmo configurando para “parecer 1440p”, fica perfeito, e no Windows fica um pouco borrado.
    No Linux, o X11 é lento, e o Wayland ainda tem atraso de desempenho
• Eu também uso a combinação i3+NixOS+urxvt+zsh+Emacs+rofi+maim+xdotool.
  Trocar esse stack que funciona perfeitamente por Sway teria mais perdas do que ganhos.
  Acho impressionante que o Michael tenha tentado e documentado isso
  • Foi marcante ver o cuidado com que ele registrou os problemas reais
• Não pretendo migrar antes que o gerenciador de janelas (WM) que eu uso ofereça suporte a Wayland.
  O maior problema do Wayland é que vários projetos de WM não conseguem fazer a transição por falta de pessoal.
  Dá para contornar com XWayland, mas não quero adicionar mais uma camada a um ambiente que já funciona perfeitamente
  • Se você usa StumpWM, a versão para Wayland, Mahogany, está sendo desenvolvida ativamente.
    E o Wayback é um projeto para rodar um desktop X11 inteiro sobre Wayland
• Uso Wayland em um notebook Framework e funciona perfeitamente.
  Monitor 4K, alternância para tela única, fractional scaling, tudo sem problema.
  Até em um Chromebook antigo o screen tearing desapareceu e tudo roda de forma suave.
  Ainda não senti nenhuma desvantagem; na verdade, a única é ouvir que ele “está errado”
  • Se funciona bem para você, ótimo, mas também é preciso reconhecer que há pessoas para quem não funciona
  • Só porque você teve sorte e não enfrentou problemas não significa que não existam desvantagens
• Para mim, o Wayland tem só desvantagens e nenhuma vantagem. Acho errada essa estrutura de empurrar a complexidade para outras camadas.
  Vou continuar usando Xorg e Openbox
  • Distribuir a complexidade de um lugar para vários foi uma decisão incompreensível
  • Ainda assim, a manutenção do Xorg está diminuindo, e os principais desenvolvedores estão migrando para Wayland.
    No fim, o Wayland será a única opção ativamente mantida