Quem joga no Linux via Steam e Proton costuma passar pelo Xwayland quando o jogo ainda é X11. O problema é que, com Escala Fracionada (125%, 133%, 150%) em sessões Wayland, muitos títulos não enxergavam a resolução nativa do monitor ou ficavam com imagem borrada por causa de “double scaling”. Isso começa a mudar com um conjunto de melhorias na emulação RandR que acabou de entrar no master do xserver: o merge request !1578625 foi mesclado em 6 de janeiro de 2026 no commit 44dea3a8.
Resumo técnico
- O que mudou: a emulação RandR do Xwayland passa a listar o modo real do monitor como o primeiro modo (o “preferido”), além de organizar os “fake modes” por tamanho.
- O benefício: fullscreen pode escolher a resolução física do output mesmo quando o compositor usa upscale interno para lidar com Escala Fracionada, reduzindo casos de borrão e de “não existe modo nativo”.
- O commit: MR !1578625, merge em master com 44dea3a8.
O fim dos jogos borrados no Wayland
O cenário clássico é este: o compositor Wayland aplica Escala Fracionada e, para manter compatibilidade com apps X11, acaba rodando o Xwayland com um “truque” de escala. Na prática, a aplicação X11 enxerga um conjunto de modos e dimensões que nem sempre bate com a resolução física do monitor. A consequência aparece rápido em jogos:
- o game lista resoluções “estranhas” (muito baixas ou “lógicas”, não físicas);
- quando tenta fullscreen, ele faz upscale ou downscale e perde nitidez;
- às vezes a resolução nativa nem aparece como opção.

A mudança central do MR é direta e pragmática: o modo real do output agora sempre entra na lista e aparece como o primeiro modo RandR, tratado como preferencial (isso vale para o Xwayland rootless, que é o padrão em Wayland). Com isso, o jogo consegue selecionar 2560×1600, 3840×2160 etc. mesmo quando o compositor está “esticando” a saída por baixo dos panos.
Na prática, essa alteração melhora dois pontos ao mesmo tempo:
- Descoberta de resolução: o modo físico aparece de forma previsível na lista RandR.
- Escolha do modo certo: o “preferido” passa a ser o modo físico, o que ajuda apps que tomam decisões a partir da ordenação.
Mesmo assim, nem todo problema some só com RandR. O próprio autor, Michel Dänzer, comenta que alguns casos que “não pegavam a resolução nativa” eram bugs do cliente (por exemplo, jogos ou camadas SDL usando fullscreen “desktop” em vez de trocar o modo RandR de fato). A boa notícia é que, com o modo físico exposto corretamente, fica mais fácil separar “limitação do stack” de “bug do jogo”.
O debate técnico: wl_output vs xdg_output
A parte mais sensível da discussão não foi “se melhora para jogos”, e sim qual fonte de verdade usar para deduzir o que é “físico” e o que é “lógico” quando há escala e rotação envolvidas.
- Michel Dänzer defende que o wl_output::mode deve representar a resolução física do hardware, seguindo a especificação do protocolo, e que o xdg_output.logical_size é o caminho para o espaço lógico do compositor. Nesse modelo, o compositor não deveria “mentir” no wl_output, e sim ajustar o que for necessário na camada lógica.
- Julian Orth contesta o quanto isso é “limpo” no mundo real, porque muitos compositores aplicam hacks diferentes para a conversa com o Xwayland. Para ele, sem um canal explícito, o Xwayland pode receber valores “coerentes” dentro de uma conexão, porém incompatíveis entre implementações. Ele chega a propor que o caminho correto seria evoluir o xwayland-shell para o compositor informar, de forma inequívoca, qual é o tamanho ideal para fullscreen e como interpretar a escala fracionada.
No fim, a decisão do MR ficou alinhada com o objetivo prático: priorizar a experiência do usuário, especialmente em jogos, com uma regra simples que devolve ao RandR um “modo preferido” que faz sentido para o monitor físico. A mensagem implícita é clara: se algum compositor reporta wl_output de forma “não física”, o bug está do lado do compositor, não do Xwayland.
Outras melhorias: rotação e ordenação
Além do “modo físico preferido”, o MR entrega ajustes que ajudam tanto usuários quanto ferramentas:
- Ordenação dos “fake modes” por tamanho: a lista de modos em saídas como
xrandrfica mais legível, porque os modos emulados agora aparecem organizados por dimensão. - Rotação de output: a emulação RandR passa a funcionar corretamente quando a tela está rotacionada (portrait, por exemplo), algo que tende a quebrar facilmente quando dimensões lógicas e físicas já estão “desalinhadas” por causa de escala.
Essas mudanças não são “cosméticas” para todos os casos. Quando um jogo tenta escolher resoluções com base em listas e preferências, a ordenação e a consistência em rotação ajudam a reduzir comportamento inesperado.
Conclusão
O merge do MR !1578625 coloca no master do xserver um conjunto importante de correções para Xwayland e RandR que atacam um problema recorrente no Wayland: jogos X11 rodando borrados ou sem enxergar a resolução nativa sob Escala Fracionada. A partir de agora, o modo físico do monitor passa a ser exposto de forma mais direta e previsível, e a base para fullscreen 1:1 fica mais viável no dia a dia.
Em termos de disponibilidade, isso já está no branch master e deve chegar às distribuições quando um release do Xwayland/Xorg Server incorporar esses commits. Em distros rolling, a janela costuma ser curta após o release. Em distros com ciclos mais conservadores, pode depender de backport.
FAQ
1) O que é Xwayland e por que jogos precisam dele?
Xwayland é o servidor X (X11) rodando como cliente do Wayland. Muitos jogos e engines ainda usam X11 direta ou indiretamente, então, mesmo em uma sessão Wayland, eles passam pelo Xwayland para desenhar janelas, fullscreen e negociar modos via RandR.
2) Como a escala fracionada afetava jogos no Linux?
Com Escala Fracionada, o compositor precisa conciliar “tamanho lógico” com “pixels físicos”. Em vários setups, a lista de modos e o “modo preferido” vistos via RandR acabavam refletindo dimensões lógicas, não a resolução física do monitor. Resultado: fullscreen com upscale e imagem borrada, ou ausência do modo nativo na lista.
3) Quando essa atualização chega ao Fedora/Ubuntu/Arch?
Ela entra após um lançamento do Xwayland/Xorg Server que traga o commit 44dea3a8 (MR !1578625). Em geral:
Arch e outras rolling tendem a receber pouco tempo depois do release. Fedora costuma integrar cedo (principalmente em branches de desenvolvimento e versões mais novas). Ubuntu depende do ciclo da versão e de eventuais backports, com mais chance de cair primeiro nas versões mais recentes do que em LTS já estabilizadas.
