O Mutter é o gerenciador de janelas e compositor oficial do ambiente GNOME, atuando como a “ponte” entre o sistema operacional e o que você vê na tela. Ele é responsável por renderizar janelas, gerenciar efeitos visuais e garantir que a comunicação com o hardware gráfico (via Wayland ou X11) ocorra sem falhas.
Principais novidades
A grande mudança desta atualização é que o VRR (Variable Refresh Rate) deixou de ser considerado uma funcionalidade experimental. Após anos de testes, o suporte para taxas de atualização variáveis agora é um recurso nativo e estável, integrado diretamente às configurações de tela do GNOME.
- VRR fora do “experimental”: Você não precisa mais usar comandos via terminal ou ferramentas como o gsettings para habilitar o suporte. O recurso agora aparece por padrão nas configurações de energia/tela, embora permaneça desativado inicialmente para evitar problemas em monitores com implementação de VRR deficiente.
- Prioridade para taxas fixas: O backend agora prefere modos de taxa de atualização fixa quando o VRR não está em uso, evitando oscilações desnecessárias.
- Limpeza de código: Foi removido o suporte para desativar o VRR via regras de
udev, simplificando a pilha de renderização nativa. - Correções de logs: O sistema agora só reporta falta de suporte a VRR no log se o conector do monitor for realmente capaz de utilizá-lo, reduzindo o “ruído” em arquivos de log de sistemas antigos.
Impacto e repercussão
A promoção do VRR para o status estável é um marco para os usuários de Linux voltados a jogos e produtividade de vídeo. De acordo com discussões recentes no GitLab do GNOME e fóruns técnicos, essa mudança prepara o GNOME 50 para competir diretamente com o KDE Plasma, que já possuía uma implementação de VRR mais acessível.
Entretanto, nem tudo são flores: contribuidores notaram que a interface do usuário ainda pode exibir o intervalo de VRR incorretamente em algumas TVs (como a Samsung S95B). Isso ocorre porque o Mutter tenta ler o campo EDID do monitor, que nem sempre reflete a realidade de tecnologias como HDMI VRR ou FreeSync. Usuários com hardware topo de linha podem notar que o sistema indica um range de 24Hz–120Hz, enquanto o hardware real opera de forma estável apenas entre 48Hz–120Hz.
O Problema: O conflito de dados no EDID
O EDID (Extended Display Identification Data) é o “currículo” que o seu monitor envia para o PC. O Mutter atualmente lê o campo padrão chamado Monitor Range Limits. O problema é que este campo é antigo e, muitas vezes, impreciso para tecnologias modernas.
1. A falha na leitura do Range
Muitas TVs e monitores modernos possuem múltiplos “perfis” de frequência. Uma TV pode informar via EDID que suporta de 24Hz a 120Hz para fins de sincronia de cinema (24fps), mas o seu módulo FreeSync ou HDMI VRR só consegue estabilizar a imagem entre 48Hz e 120Hz.
- O que o Mutter faz: Lê o primeiro valor (24Hz).
- O resultado: O sistema tenta forçar o VRR em frequências baixas demais, causando o famoso flicker (piscar de tela) ou perda de sinal.
2. Extensões ignoradas (VSDB)
O comentário técnico destaca que o Mutter não está priorizando os blocos de dados específicos de fornecedores (VSDB – Vendor Specific Data Blocks), como os da AMD ou do fórum HDMI. Esses blocos contêm os limites reais de operação do VRR, que são mais restritos e precisos do que os limites gerais do monitor.
Como os patches pretendem corrigir isso
Embora o VRR tenha sido promovido a estável, os desenvolvedores já discutem os próximos passos para refinar essa detecção:
- Priorização de DisplayPort: Para conexões DP, o Mutter deve passar a exigir a flag Range limits only para confiar nos dados do EDID.
- Parsing de Blocos HDMI: Há uma necessidade urgente de implementar um “parser” que ignore o range genérico quando um bloco de dados HDMI VRR ou FreeSync estiver presente.
- Fallback Seguro: Em vez de aceitar o valor mínimo de 24Hz, o sistema pode passar a adotar um “piso” mais conservador (como 40Hz ou 48Hz) se não houver certeza absoluta sobre a capacidade do hardware, evitando falhas visuais para o usuário leigo.
O que isso significa para você?
Se você possui um monitor gamer ou uma TV OLED de última geração:
- A interface pode mentir: Você verá um range de frequência nas configurações que seu monitor não suporta totalmente no modo VRR.
- Instabilidade em baixos FPS: Se o jogo cair para 30 FPS e o seu monitor só suportar VRR a partir de 48Hz, você pode notar artefatos visuais porque o Mutter ainda não sabe exatamente onde a “janela de segurança” do seu hardware termina.
Resumo Técnico da Investigação
| Fonte de Informação | Confiabilidade para VRR | Status no Mutter |
| EDID Standard | Baixa (Geralmente amplo demais) | Usado atualmente |
| HDMI Forum VSDB | Alta (Define o range real da TV) | Em discussão para implementação |
| AMD/FreeSync VSDB | Alta (Define o range para monitores) | Em discussão para implementação |
Resumo técnico
- Status do Recurso: Transição de
experimental-featurespara funcionalidade estável de primeira classe. - Kernel/Backends: Refinamento no
backends/nativepara remover redundâncias de configuração de hardware. - KMS/GPU: Verificação de capacidade de conector aprimorada para evitar falsos positivos de erro no driver.
- Refatoração: Separação de lógicas de comparação entre taxas de atualização e modos de monitor para evitar bugs de arredondamento.
Disponibilidade
Esta atualização faz parte do ciclo do GNOME 50. Usuários de distribuições rolling release, como Arch Linux e openSUSE Tumbleweed, devem receber as atualizações assim que a versão final do GNOME 50 for empacotada. Para usuários de Fedora 42 (previsão) e Ubuntu, a funcionalidade deve chegar nas próximas grandes atualizações de versão das distros.