X11 não morreu por acaso: Wayland é a faxina que o desktop Linux adiou por décadas

O X11 é uma daquelas peças do Linux desktop que parecem eternas porque ficaram tempo demais funcionando bem o suficiente. Não necessariamente bem. Não necessariamente bonito. Não necessariamente seguro. Mas bem o suficiente para a maioria das pessoas abrir um terminal, arrastar uma janela torta, configurar três monitores na base da fé e seguir a vida.

Esse é o tipo de tecnologia que vira infraestrutura invisível. Enquanto funciona, ninguém pensa nela. Quando quebra, parece que metade do sistema operacional foi projetado por arqueólogos com acesso a C e rancor acumulado.

O problema é que o X11 não foi criado para o computador pessoal moderno. Ele nasceu em outro mundo: estações Unix, terminais gráficos, redes locais confiáveis, usuários técnicos, máquinas caras e um modelo em que “rodar um programa em uma máquina e exibir em outra” era uma feature central, não uma curiosidade de nicho. Esse contexto explica muita coisa. Também explica por que tentar encaixar captura de tela segura, sandboxing, monitores com escalas diferentes, GPUs modernas, tablets, VRR, HDR, jogos e aplicativos Electron em cima dessa arquitetura virou um esporte de resistência.

O Wayland não surgiu porque alguém acordou e decidiu trocar uma peça central do desktop Linux só para irritar usuário de Arch com NVIDIA (autodescrição). Embora, olhando alguns fóruns, pareça exatamente isso. Ele surgiu porque o X11 foi acumulando responsabilidades, extensões e remendos até virar uma pilha onde muita coisa moderna funcionava apesar da arquitetura, não por causa dela.

Antes do Wayland, tinha o X; antes do X, tinha outro mundo

O X Window System nasceu no MIT em 1984, dentro do contexto do Project Athena, um projeto criado por MIT, DEC e IBM para oferecer computação distribuída em um ambiente heterogêneo de máquinas e usuários. A ideia era ter um sistema gráfico independente de fabricante, capaz de funcionar em diferentes hardwares e sistemas Unix. A versão 11 do protocolo, o famoso X11, foi lançada em setembro de 1987, e é por isso que até hoje o nome carrega esse número meio fóssil em produção: X11 não é “mais um nome”, é literalmente a versão do protocolo.

O detalhe importante é que o X nasceu como um sistema gráfico de rede. No modelo do X, o “servidor” é o programa que controla a tela, o teclado e o mouse. Os “clientes” são as aplicações que pedem para desenhar janelas e receber eventos. Isso confunde muita gente porque, no uso comum de cliente-servidor, a gente imagina o servidor como a máquina remota e o cliente como o computador do usuário. No X é o contrário: o servidor está onde está o display. O cliente pode estar na mesma máquina ou em outro computador da rede.

Essa inversão fazia sentido. Se você tinha uma workstation gráfica local e queria rodar um software pesado em uma máquina remota, o X permitia que a aplicação remota desenhasse na sua tela local. Era uma arquitetura elegante para o mundo Unix acadêmico e corporativo dos anos 80. O manual do X e a própria história do sistema deixam claro esse foco em uma interface gráfica independente de máquina, sistema e fabricante.

Só que uma boa ideia em 1987 pode virar uma dívida técnica em 2026. Especialmente quando o mundo deixa de ser uma rede local relativamente confiável e vira uma coleção de notebooks, sandboxes, Flatpaks, jogos, GPUs híbridas, telas 4K, compositores, screen sharing no navegador e aplicativos que querem capturar input global porque “produtividade”.

XFree86: quando o desktop Linux precisava de um X que funcionasse em PCs

Nos anos 90, o Linux começou a ganhar espaço em PCs comuns. Só que PC comum não era workstation Unix polida. Era placa de vídeo variada, driver estranho, BIOS suspeita, monitor que talvez informasse as resoluções corretamente e usuário querendo abrir uma interface gráfica sem vender a alma para um fornecedor proprietário.

Nesse cenário, o XFree86 virou peça central. O projeto começou em 1992 a partir do X386, uma implementação do servidor X para PCs compatíveis com IBM PC, e acabou se tornando a implementação dominante do X em Linux e BSD durante boa parte dos anos 90 e começo dos anos 2000. A história curta é: o XFree86 fez o X funcionar onde o Linux desktop estava crescendo, e isso foi enorme. A história longa envolve governança, licença, conflitos de desenvolvimento e aquele tempero clássico de projeto open source importante demais para ter pouca gente decidindo tudo.

O XFree86 não era só “mais um servidor gráfico”. Na prática, ele virou a referência de desenvolvimento do X no mundo livre. Só que, no início dos anos 2000, o projeto começou a enfrentar críticas de governança e, em 2004, uma mudança de licença no XFree86 4.4 gerou rejeição em várias distribuições e projetos. A partir daí, o X.Org Server tomou o lugar como implementação dominante do X11, usando uma base derivada do XFree86 antes da mudança de licença e uma governança mais aberta. O resumo histórico aparece bem documentado em fontes como a página sobre XFree86 e a história do X.Org Server.

Foi aí que “Xorg” virou sinônimo prático de servidor gráfico no Linux. Tecnicamente, X11 é o protocolo. Xorg é a implementação moderna mais conhecida desse protocolo. Mas no dia a dia muita gente fala “estou usando Xorg” para dizer “minha sessão gráfica é X11”. Não é preciso chamar a polícia dos nomes, mas a diferença importa quando se discute arquitetura.

O X11 é mecanismo, não política

Uma das ideias fundamentais do X é fornecer mecanismo, não política. O X não define como sua interface deve parecer. Ele não decide se a janela tem botão à esquerda, à direita, borda grossa, tema cinza triste ou transparência com gosto duvidoso. Ele oferece primitivas: janelas, eventos, desenho, input, comunicação entre cliente e servidor. A política fica com o window manager, com o toolkit, com o desktop environment e com as convenções ao redor.

Isso explica por que o X conseguiu sobreviver tanto tempo. Ele era extensível. Se faltava algo, criava-se uma extensão. Renderização moderna? Extensão. Composição? Extensão. Input melhor? Extensão. Configuração dinâmica de monitor? Extensão. Sincronização? Extensão. O X virou uma espécie de kernel social do desktop Unix: pequeno no conceito original, enorme na prática, e cercado de mecanismos auxiliares que todo mundo aprendeu a respeitar com medo.

No modelo clássico, o X server controla o hardware de display e input. O window manager decide onde as janelas ficam. Um compositor, quando existe, compõe o conteúdo final da tela com sombras, transparências e efeitos. O cliente gráfico é a aplicação: terminal, navegador, editor, IDE, seja lá qual for o pecado do dia.

O ponto é que essas responsabilidades foram separadas em uma época em que composição não era parte essencial do fluxo. No X moderno, porém, o compositor virou praticamente obrigatório para uma experiência decente. Só que ele foi encaixado por cima de uma arquitetura que não nasceu com ele no centro.

A documentação do Wayland descreve bem essa crítica: no X moderno, o servidor continua no caminho entre clientes, compositor e hardware, mesmo quando parte da responsabilidade real já foi para bibliotecas, drivers do kernel e compositores externos. A própria introdução oficial do Wayland aponta que o X acumulou funções como gerenciamento de display, renderização, composição e interação com drivers, criando complexidade e passos extras.

Como o X11 funciona na prática

No X11, uma aplicação normalmente conversa com o servidor X usando bibliotecas como Xlib ou XCB, diretamente ou por meio de toolkits como GTK, Qt, Motif, wxWidgets e similares. O cliente pede para criar janelas, desenhar elementos, receber eventos de teclado e mouse, manipular propriedades e interagir com outras janelas. O servidor X arbitra esses pedidos e expõe os eventos para os clientes interessados.

Esse modelo tem algumas consequências importantes.

A primeira é a transparência de rede. Como o protocolo foi desenhado para comunicação cliente-servidor, uma aplicação pode rodar em uma máquina e exibir em outra. Isso é parte do DNA do X, não um plugin de última hora. Em ambientes acadêmicos, corporativos e laboratoriais, isso foi extremamente útil. Em 2026, ainda existe gente que depende disso. Nem todo mundo vive dentro de um navegador com tema Dracula e cinco monitores.

A segunda é que os clientes X têm poder demais dentro da sessão. Um cliente autorizado pode observar ou interferir em muito mais do que um aplicativo moderno deveria. Ferramentas de automação, captura de input, seleção global, clipboard e inspeção de janelas funcionam muito bem justamente porque o modelo de segurança é permissivo. Isso é conveniente. Também é assustador. O manual Xsecurity existe porque autorização em X11 sempre foi um assunto delicado; o problema não é só “conectar ou não conectar”, mas o que um cliente autorizado consegue fazer depois que entra.

A terceira é que composição no X é uma camada adicionada. O X originalmente não foi desenhado como um compositor moderno. Quando o desktop passou a exigir transparência, sombras, animações, redirecionamento de janelas e efeitos, a solução foi usar extensões como Composite, Damage, Render, XFixes, RandR, XInput e várias outras. Isso funcionou, mas criou um conjunto de acoplamentos difícil de explicar sem um quadro branco e uma crise existencial.

A quarta é que renderização também mudou de lugar ao longo do tempo. No início, desenhar via primitivas do X fazia mais sentido. Depois vieram Cairo, OpenGL, DRI, Mesa, renderização direta no cliente, buffers compartilhados, GPU moderna. O servidor X foi deixando de ser o lugar natural onde o desenho acontecia e virou mais um intermediário entre partes que já sabiam conversar com o kernel e com a GPU.

O resultado é um sistema impressionante, mas torto. O X11 é uma engenharia brilhante para o problema que ele queria resolver. O problema é que continuamos pedindo para ele resolver problemas que não estavam no contrato original.

O desktop moderno colocou o X11 contra a parede

O desktop Linux moderno exige coisas que parecem simples até você tentar implementar sem quebrar vinte anos de compatibilidade.

Multi-monitor com densidades diferentes não é trivial. Um monitor 4K em escala 150% ao lado de um monitor 1080p em 100% exige que o sistema entenda coordenadas lógicas, coordenadas físicas, buffers, escala por saída e posicionamento sem fingir que tudo é um retângulo global homogêneo. O X11 consegue lidar com muita coisa via RandR e hacks de compositor, mas o modelo não foi feito para isso com naturalidade.

HiDPI e fractional scaling também sofrem por causa dessa herança. Em X11, o toolkit, o compositor, o servidor e a aplicação podem discordar sobre o que é um pixel, o que é uma unidade lógica e quem deve escalar o quê. No Wayland, isso também não é magicamente perfeito, mas pelo menos a arquitetura permite que o compositor tenha controle real sobre outputs, escala e buffers de cada superfície.

Captura de tela é outro exemplo clássico. No X11, capturar a tela era fácil porque os clientes podiam acessar informações globais da sessão com pouca cerimônia. Ferramentas antigas adoravam isso. Usuários também. Segurança, nem tanto. No Wayland, uma aplicação não deve simplesmente ler a tela inteira sem consentimento. Por isso o caminho moderno passa por portals e PipeWire: a aplicação pede permissão, o compositor decide o que pode ser compartilhado, e o stream é entregue de forma controlada. A documentação do ScreenCast portal, do Screenshot portal e do PipeWire portal access control mostra essa mudança de filosofia.

Isso é melhor arquiteturalmente. Também é mais chato. E aqui mora boa parte da briga.

No X11, muitas ferramentas funcionavam porque não havia isolamento forte. No Wayland, algumas deixam de funcionar porque agora precisam pedir permissão, usar protocolo novo, depender do compositor ou esperar um portal amadurecer. Para o usuário, isso parece regressão. Para quem está desenhando o sistema, é uma correção de um erro antigo. Os dois lados têm razão em partes diferentes da frase.

Wayland: menos servidor mágico, mais compositor responsável

O Wayland muda o centro de gravidade. Em vez de um servidor X no meio, um window manager separado e um compositor externo tentando coordenar a bagunça, o compositor Wayland é o display server. Ele recebe input, sabe a geometria real da cena, decide qual superfície está onde, aplica transformações, compõe os buffers e fala com DRM/KMS para apresentar o resultado na tela.

A arquitetura oficial do Wayland explica essa diferença seguindo o caminho de um evento de input até a tela. No X, o kernel envia o evento ao servidor X, o X decide para qual cliente mandar, o cliente redesenha, o servidor comunica dano ao compositor, o compositor recompõe e ainda precisa voltar ao X para apresentar. No Wayland, o kernel envia o evento ao compositor, o compositor sabe qual superfície deve receber o evento, o cliente renderiza em seu buffer e avisa o compositor, que então compõe e agenda o page flip usando KMS.

A mudança central é tirar o servidor X do caminho crítico e colocar o compositor como árbitro de input, superfície e apresentação.

Isso remove etapas. Mais importante: remove ambiguidade de responsabilidade.

O cliente Wayland não pede ao servidor para desenhar botões. Ele desenha seu conteúdo em buffers próprios, usando Cairo, OpenGL, Vulkan, software rendering, GTK, Qt ou o que for apropriado, e entrega esses buffers ao compositor. O compositor não precisa saber como a aplicação desenhou. Ele precisa saber como compor as superfícies.

Na prática moderna, isso envolve Mesa, EGL, Vulkan, GBM, dma-buf, DRM, KMS, libinput e protocolos Wayland complementares. A documentação oficial menciona troca de buffers via dma-buf e integração com EGL/Vulkan no caminho de renderização acelerada. Ou seja: Wayland não é “um servidor gráfico pequeno que substitui tudo”. Wayland é um protocolo menor porque várias responsabilidades foram para os lugares onde já deveriam estar: kernel, bibliotecas gráficas, toolkits e compositores.

Isso é bonito no desenho. No dia a dia, significa que cada compositor precisa implementar uma parte relevante da experiência. Mutter, KWin, wlroots, Weston e compositores independentes não são skins diferentes em cima de um servidor universal. Eles são implementações reais do display server. É por isso que “funciona no GNOME” não significa automaticamente “funciona no Sway”, e “funciona no KDE” não significa automaticamente “funciona no Hyprland”. O protocolo comum existe, mas a política e as extensões importam muito.

Mutter, KWin, wlroots e Weston: Wayland não é um bloco único

O Weston é a implementação de referência do Wayland. Ele é importante para demonstrar o protocolo, testar ideias e servir como base conceitual, mas não é o desktop que a maioria das pessoas usa. A documentação do Weston deixa claro esse papel de compositor de referência e ambiente de desenvolvimento.

No GNOME, quem faz o trabalho pesado é o Mutter. Ele começou como window manager e compositor no mundo X11, mas evoluiu para ser o compositor Wayland do GNOME Shell. O projeto tem documentação própria em mutter.gnome.org e código no GitLab do GNOME. Quando alguém diz “Wayland no GNOME”, na prática está falando do comportamento do Mutter, do GNOME Shell, do GTK, dos portals e das decisões do projeto GNOME.

No KDE Plasma, o papel equivalente é do KWin. Ele funciona como window manager no X11 e compositor no Wayland, e é uma das peças centrais do Plasma. O código fica no repositório do KWin. O KDE costuma expor mais opções ao usuário e historicamente tem uma postura diferente do GNOME em relação a configuração, protocolos e compatibilidade. Isso aparece na experiência Wayland também.

Já o wlroots é outra história. Ele não é um desktop environment, mas uma biblioteca modular para construir compositores Wayland. Sway, river e vários compositores independentes se apoiaram ou se apoiam nesse tipo de fundação. A documentação do wlroots mostra bem a quantidade de peças envolvidas: backends DRM, libinput, renderização, output management, screencopy, xdg-shell, xwayland, tablet, pointer constraints, tearing control e assim por diante.

Esse ponto é importante porque muita discussão sobre Wayland erra ao tratar o sistema como se fosse uma implementação única. Wayland é protocolo e ecossistema. Mutter, KWin e wlroots tomam decisões diferentes. Às vezes a limitação está no protocolo. Às vezes está no compositor. Às vezes está no toolkit. Às vezes está no aplicativo. Às vezes está na NVIDIA. E às vezes está no usuário tentando usar uma ferramenta de 2009 como se o modelo de segurança de 2026 fosse pedir desculpa.

XWayland: a ponte que segura o mundo antigo

A transição para Wayland só é minimamente possível porque existe o XWayland. Ele é um servidor X que roda como cliente Wayland. Aplicações X11 continuam falando X11, mas em vez de controlar diretamente uma sessão X tradicional, elas são apresentadas como superfícies dentro do compositor Wayland.

Isso resolve uma parte enorme da compatibilidade. Aplicações antigas, toolkits que ainda usam X11, jogos, softwares proprietários e ferramentas que nunca foram portadas podem continuar abrindo. Sem XWayland, Wayland teria sido uma tese acadêmica bonita e uma migração praticamente inviável para o desktop real.

Mas XWayland tem limites. Ele não transforma aplicações X11 em aplicações Wayland nativas. Ele preserva compatibilidade, mas não dá a elas acesso irrestrito ao compositor Wayland. Algumas integrações globais, automações, captura de input, inspeção de janelas e comportamentos específicos do X11 continuam limitados ou dependem de protocolos adicionais.

Esse é o ponto que muita gente confunde: XWayland é uma camada de compatibilidade, não uma máquina do tempo. Ele é excelente para rodar aplicações antigas. Ele não existe para manter vivo todo modelo de poder global do X11 dentro de uma sessão Wayland.

Segurança: a vantagem mais desconfortável do Wayland

O argumento de segurança do Wayland é simples: uma aplicação gráfica não deve poder espionar todas as outras por padrão.

No X11, o modelo tradicional permite uma convivência muito íntima entre clientes. Essa intimidade viabiliza ferramentas úteis, mas também cria uma superfície ruim para isolamento. Keyloggers, captura de tela, leitura de clipboard, enumeração de janelas e automação global são muito mais fáceis quando a sessão inteira compartilha um modelo permissivo.

No Wayland, o compositor é o árbitro. Um cliente não recebe input que não é dele. Não captura a tela inteira sem passar pelo compositor ou por um portal. Não injeta input global como se fosse dono do desktop. Isso melhora o isolamento entre aplicações, especialmente em um mundo com Flatpak, sandboxing e aplicativos baixados de fontes variadas.

Só que segurança quase sempre cobra aluguel em conveniência. Ferramentas antigas de screenshot, color picker, macro, automação, compartilhamento de tela e acesso remoto quebraram ou precisaram ser reescritas. O caminho moderno envolve portals para screenshot, portals para screencast, portals para atalhos globais, portals para captura de input e integração com PipeWire.

Isso não é regressão acidental. É a consequência de parar de tratar qualquer aplicação da sessão como confiável por definição.

Desempenho, latência e tearing: sem milagre, mas com arquitetura melhor

Um erro comum é vender Wayland como “mais rápido” de forma genérica. Não é tão simples. Dependendo do compositor, driver, toolkit, jogo e hardware, o resultado pode variar. Mas a arquitetura do Wayland permite reduzir etapas e evitar alguns caminhos desnecessários que existem no X moderno.

A documentação do Wayland destaca justamente isso: no X com compositor, o servidor pode virar um intermediário extra entre aplicação, compositor e hardware. No Wayland, o compositor recebe buffers dos clientes e apresenta usando KMS, com menos idas e vindas. Isso pode ajudar em latência e previsibilidade, mas não transforma automaticamente todo desktop em uma nave.

Jogos são um caso interessante. Por muito tempo, jogadores reclamaram de latência, tearing, VRR, suporte de driver, XWayland e comportamento diferente entre compositores. Algumas dessas críticas eram bem justas. O suporte melhorou muito, especialmente com trabalho em XWayland, Mesa, drivers NVIDIA mais recentes, protocolos de tearing control, VRR e melhorias em KWin e Mutter. Mas jogos continuam sendo uma área onde detalhes importam: fullscreen, frame pacing, captura de mouse, HDR, VRR, múltiplos monitores e overlays não são brinquedos simples.

A parte honesta é: X11 ainda pode parecer mais previsível para alguns setups específicos, principalmente porque tudo já foi remendado durante décadas. A parte igualmente honesta é: muitos recursos modernos estão sendo feitos primeiro, melhor ou exclusivamente pensando em Wayland.

Multi-monitor, HiDPI e fractional scaling: onde a conta chega

Se tem um lugar onde a arquitetura pesa, é em monitor.

No X11, a sessão tende a operar sobre uma ideia global de tela. Extensões como RandR melhoraram muito o gerenciamento de outputs, rotação, resolução e hotplug, mas o modelo continua carregando a herança de um espaço global onde várias coisas assumem propriedades uniformes demais.

No Wayland, o compositor conhece os outputs e controla a composição final. Isso permite lidar melhor com monitores diferentes, escalas diferentes, transformações e densidades distintas. Não significa que fractional scaling seja perfeito. No GNOME, KDE e wlroots, houve e ainda há diferenças de implementação, bugs, escolhas de qualidade versus performance e detalhes em aplicações XWayland. Mas o modelo arquitetural favorece esse tipo de problema moderno.

Em XWayland, por exemplo, aplicações X11 podem sofrer com escala porque continuam presas ao mundo X. Uma aplicação Wayland nativa pode negociar escala e buffers de forma mais adequada com o compositor. Uma aplicação XWayland pode precisar ser escalada pelo compositor, pelo toolkit ou por alguma combinação que nem sempre fica nítida. É daí que nascem muitos relatos de “no Wayland ficou borrado” ou “no Xorg ficava melhor”. Às vezes é culpa do Wayland. Às vezes é culpa da aplicação ainda não ser Wayland nativa. Às vezes é o preço de manter compatibilidade com o passado.

NVIDIA: o vilão conveniente, mas não o único

Durante anos, NVIDIA foi uma das maiores fontes de atrito na adoção do Wayland. O ecossistema Linux gráfico livre se desenvolveu muito em torno de Mesa, DRM, KMS, GBM e drivers abertos. A NVIDIA, com driver proprietário e escolhas diferentes, incluindo EGLStreams por um período, tornou tudo mais difícil.

Isso mudou bastante. Drivers recentes da NVIDIA melhoraram o suporte a GBM e Wayland, e distribuições passaram a confiar mais nesse caminho. A própria página de mudança do Fedora KDE para Plasma 6 cita que drivers NVIDIA recentes suportam GBM para Wayland e que o Fedora KDE se sentia confortável para remover a sessão X11 no Plasma 6, mantendo XWayland para aplicações X11 (Fedora KDE Plasma 6).

Mas é bom evitar o clichê preguiçoso de jogar tudo na NVIDIA. Há problemas que são do protocolo. Há problemas que são do compositor. Há problemas que são do toolkit. Há problemas que são de aplicações antigas. E há problemas que são do simples fato de que o Linux desktop é uma federação de projetos independentes tentando parecer um produto coeso.

Spoiler: às vezes não parece.

”Por que tanta resistência ao Wayland?”

A resistência ao Wayland não é só birra. Tem gente que depende de fluxos que o X11 fazia muito bem.

Acesso remoto via X11 forwarding é um exemplo óbvio. O Wayland não tenta replicar a transparência de rede do X11 no protocolo base. O modelo moderno prefere outros caminhos: RDP, VNC, PipeWire, portals, compositor-specific remoting, aplicações web, SSH com forwarding de protocolo de aplicação, ou simplesmente rodar a aplicação onde ela está. Para alguns casos, isso é melhor. Para outros, é pior. Se você dependia de ssh -X como parte central do fluxo, Wayland parece uma perda real.

Automação também sofreu. No X11, ferramentas podiam observar janelas, capturar teclas, mover mouse, injetar eventos e manipular a sessão com liberdade. No Wayland, isso precisa passar por protocolos controlados, portals ou APIs específicas do compositor. Para acessibilidade e automação legítima, isso exigiu reconstruir infraestrutura. Para ferramentas rápidas e sujas, isso quebrou a festa.

Screen sharing foi outra dor famosa. Durante bastante tempo, compartilhar tela em Wayland era uma experiência variável: funcionava no GNOME, quebrava no browser, dependia de PipeWire, dependia do portal, dependia do Flatpak, dependia do compositor, dependia de alguma flag esquecida. Hoje está muito melhor, mas a cicatriz comunitária ficou. Quando uma pessoa perde uma call porque o compartilhamento de tela não funciona, ela não quer ouvir palestra sobre arquitetura correta. Ela quer que a porcaria da tela apareça.

Acessibilidade também é um ponto sensível. Leitores de tela, ampliação, input alternativo, automação assistiva e inspeção de UI precisam de integração profunda. O X11 permitia várias abordagens por ser permissivo. Wayland exige caminhos explícitos e seguros. A direção é correta, mas a transição não é grátis.

Por que os defensores do Wayland dizem que ele é inevitável

O argumento pró-Wayland é que o X11 já cumpriu seu papel. Não porque seja inútil, mas porque virou o lugar errado para resolver problemas modernos.

A própria documentação do Wayland resume a tese: ao longo do tempo, funcionalidades que ficavam no X foram movidas para bibliotecas, toolkits e kernel; o que sobra para o servidor gráfico moderno é apresentar superfícies e arbitrar input. O compositor já precisa entender a cena final, então faz sentido ele ser o display server (Wayland Architecture).

Distribuições e desktops estão seguindo essa leitura. O Fedora tornou Wayland padrão no GNOME desde o Fedora 25, com fallback para Xorg quando necessário (Wayland By Default). O Fedora KDE decidiu ir além no Plasma 6 e não oferecer sessão X11, mantendo XWayland para compatibilidade de aplicações (Fedora KDE Plasma 6). O Fedora também documentou a remoção dos pacotes de sessão X11 do GNOME como parte do alinhamento com o esforço upstream de aposentadoria da sessão X11 (Wayland-only GNOME).

KDE Plasma 6 tornou Wayland a sessão padrão. GNOME empurrou cada vez mais o caminho Wayland. wlroots consolidou um ecossistema inteiro de compositores independentes. PipeWire e portals amadureceram. XWayland segurou compatibilidade. O resultado é que Wayland deixou de ser “o futuro” e virou “o presente, com bugs de presente”.

A frase parece piada, mas é a melhor descrição da transição. X11 é o passado ainda necessário. Wayland é o presente ainda irregular. O futuro é quando essa distinção parar de importar para a maioria dos usuários.

O que ainda falta

Wayland já é perfeitamente usável para muita gente. Eu diria mais: em vários setups, é a melhor opção hoje. Mas “usável para muita gente” não é o mesmo que “substitui X11 em todos os casos”.

Ainda existem áreas que merecem atenção.

A primeira é padronização de protocolos entre compositores. GNOME, KDE e wlroots nem sempre implementam as mesmas extensões, ou implementam em ritmos diferentes. Isso afeta atalhos globais, captura de tela, captura de input, gerenciamento de janelas, protocolos de layer shell, virtual keyboard, remote desktop e recursos avançados. O ecossistema melhora, mas a fragmentação existe.

A segunda é acessibilidade. Um desktop moderno precisa permitir automação assistiva sem abrir de novo o buraco de segurança do X11. Isso exige APIs formais, permissões, integração com toolkits e colaboração entre compositores. Não dá para tratar acessibilidade como “depois a comunidade resolve”.

A terceira é automação legítima. Existem casos reais para macros, ferramentas de produtividade, key remapping avançado, streaming, KVM via software, controle remoto e testes automatizados de UI. Wayland precisa oferecer caminhos seguros para isso, e não apenas dizer “no X11 era inseguro”. Era mesmo. Mas o usuário ainda precisa trabalhar.

A quarta é compatibilidade com aplicações antigas e proprietárias. XWayland ajuda muito, mas não resolve tudo. Enquanto existirem softwares que dependem de comportamentos específicos do X11, algumas pessoas vão manter sessões Xorg por necessidade, não nostalgia.

A quinta é consistência de experiência. Quando uma feature funciona no GNOME, falha no KDE e depende de plugin no compositor wlroots da semana, o usuário não pensa “que diversidade arquitetural fascinante”. Ele pensa outra coisa, geralmente com mais palavrões.

X11 merece respeito, não culto

O X11 não é lixo. Essa é a crítica fácil de quem confunde modernização com ingratidão. O X11 carregou o Unix gráfico, o Linux desktop, ambientes acadêmicos, estações de trabalho, aplicações científicas, desktops inteiros, toolkits e gerações de usuários por décadas. Poucas peças de software sobrevivem tanto tempo sendo irrelevantes.

Mas respeito não significa culto.

O X11 foi excelente para um mundo onde rede local, estações Unix e separação entre mecanismo e política eram o centro da história. O desktop atual tem outros problemas: isolamento, composição obrigatória, GPUs modernas, múltiplos monitores heterogêneos, sandboxing, captura de tela consentida, aplicativos empacotados, segurança entre clientes, jogos, touch, tablets, HDR, VRR e acessibilidade integrada.

Dá para continuar remendando Xorg? Em alguns casos, sim. E provavelmente ele ainda vai existir por muito tempo, nem que seja via XWayland, sistemas legados, desktops menores ou usuários com necessidades específicas. Mas como caminho principal do desktop Linux, o X11 virou uma base cara demais para sustentar.

Wayland não é perfeito. Às vezes é irritante. Às vezes uma ferramenta antiga quebra e a explicação correta parece deboche. Às vezes o compositor que você escolheu implementa metade do que você precisa e chama o resto de “fora de escopo”. Às vezes o futuro chega com cara de issue aberta.

Mas a direção faz sentido.

A transição do X11 para Wayland não é a troca de um protocolo por outro. É a troca de uma filosofia: sair de uma sessão gráfica permissiva, global e historicamente remendada para um modelo onde o compositor é o centro, clientes são mais isolados, buffers são compartilhados de forma explícita e permissões passam a existir de verdade.

No fundo, o drama é simples: o X11 funcionava porque confiava demais. O Wayland irrita porque desconfia mais.

E, para um desktop moderno, talvez a parte irritante seja justamente a parte certa.