Xwayland corrige problema de jogos borrados com escala fracionada no Wayland

Mudança no RandR prioriza o modo físico e melhora fullscreen no Steam e Proton.

Por
Emanuel Negromonte
Emanuel Negromonte é Jornalista, Mestre em Tecnologia da Informação e atualmente cursa a segunda graduação em Engenharia de Software. Com 14 anos de experiência escrevendo sobre...
8 min

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:

  1. Descoberta de resolução: o modo físico aparece de forma previsível na lista RandR.
  2. 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 xrandr fica 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

Compartilhe este artigo
Sair da versão mobile