Christian Schaller, que lidera a equipe de desenvolvimento de desktop da Red Hat e o desktop Fedora, em uma revisão dos planos para componentes de desktop no Fedora 31, mencionou a intenção da Red Hat de parar de desenvolver ativamente a funcionalidade do servidor X.Org e se limitar apenas a manter a base de código existente e depuração.
Atualmente, a Red Hat faz uma contribuição importante para o desenvolvimento do servidor X.Org e mantém seu suporte, portanto, no caso de suspensão do desenvolvimento, é improvável que a formação de lançamentos significativos do servidor X.Org continue.
Ao mesmo tempo, apesar da interrupção do desenvolvimento, o suporte da Red Hat ao X.Org continuará pelo menos até o final do ciclo de vida da distribuição do RHEL 8, que durará até 2029.
O desenvolvimento do X.Org já é mínimo
A estagnação no desenvolvimento do servidor X.Org já foi observada. Apesar do ciclo de lançamento de seis meses que foi usado anteriormente, a última versão significativa do X.Org Server 1.20 foi lançada 14 meses atrás e a preparação para a versão 1.21 está paralisada.
A situação pode mudar se qualquer empresa ou comunidade concordar em continuar aumentando a funcionalidade do servidor X.Org, Mas, dada a mudança generalizada de projetos significativos para Wayland, é improvável que haja alguém.
A Red Hat está atualmente se concentrando em melhorar o trabalho de desktop baseado no Wayland. Espera-se que o servidor X.Org seja colocado em modo de manutenção após resolver o problema de remover completamente as dependências dos componentes do X.Org e certificar-se de que o shell Gnome seja iniciado sem usar o XWayland, o que requer refatoração ou remoção dos links restantes para o X.org.
Esses links são quase removidos do Gnome Shell, mas ainda permanecem nas configurações do Gnome.
No Gnome 3.34 ou 3.36, é planejado abandonar completamente os vínculos do X.Org e organizar o lançamento do XWayland dinamicamente, quando surgir a necessidade de componentes para garantir a compatibilidade do X11.
A Red Hat prefere concentrar seus esforços em Wayland
A necessidade de resolver uma série de questões pendentes com Wayland também é mencionada, como trabalhar com drivers proprietários NVIDIA e refinar o servidor XWayland DDX para garantir o lançamento de qualidade de aplicativos X em um ambiente baseado em Wayland
Dos 31 trabalhos em preparação para o Fedora, o XWayland está implementando a capacidade de executar aplicativos X com privilégios de root. Tal versão é questionável do ponto de vista da segurança, mas é necessária para garantir a compatibilidade com os programas X, que requerem privilégios elevados.
Outro desafio é melhorar o suporte do Wayland na biblioteca SDL, por exemplo, para resolver problemas de dimensionamento ao executar jogos mais antigos que são executados em resoluções de tela baixas.
Além disso, É necessário melhorar o suporte para o trabalho de Wayland em sistemas com drivers proprietários NVIDIA:
se o Wayland puder trabalhar nesses drivers por muito tempo, então o XWayland nesta configuração ainda não pode usar recursos de aceleração de hardware para gráficos 3D (está planejado para fornecer a capacidade de baixar drivers NVIDIA x.org para XWayland).
Além disso, o trabalho está em andamento para substituir o PulseAudio e Jack pelo PipeWire Media Server, que expande as capacidades do PulseAudio com streaming de vídeo e processamento de áudio com latência mínima, levando em consideração as necessidades dos sistemas de processamento de som profissional, além de oferecer um modelo de segurança aprimorado para controle de acesso individual no nível do dispositivo.
Finalmente, como parte do ciclo de desenvolvimento do Fedora 31, o trabalho foca no uso do PipeWire para compartilhar o acesso à tela em ambientes baseados no Wayland, incluindo o uso do protocolo Miracast.
Pára O Fedora 31 também está planejado para adicionar a capacidade de lançar aplicativos Qt em uma sessão do Wayland baseada no Gnome. usando o plugin Qt Wayland ao invés do plugin XCB usando X11 / XWayland.