O servidor X.Org pode estar com os dias contados. Pelo menos em relação à Red Hat que tem como objetivo parar o desenvolvimento do servidor. O anúncio foi feito por Christian Schaller, que dirige a área de trabalho equipe de desenvolvimento Red Hat e de desktop Fedora. Ele propôs uma revisão de planos para componentes de desktop no Fedora 31. Ele disse disse que a intenção da Red Hat é parar de desenvolver funcionalidades do servidor X.Org. Segundo ele, é preciso limitar-se apenas à manutenção da base de código existente e à eliminação de erros. Então, a Red Hat deve parar desenvolvimento do servidor X.Org.
Porém, atualmente, a Red Hat faz uma contribuição fundamental para o desenvolvimento do servidor X.Org e mantém o seu apoio. Portanto, a suspensão do desenvolvimento deve impactar diretamente os lançamentos significativos de servidor X.Org.
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
O impasse no desenvolvimento do servidor X.Org já foi observado. 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 publicada há 14 meses e a preparação para a versão 1.21 está paralisada.
A situação pode mudar se uma empresa ou comunidade estiver empenhada em aumentar a funcionalidade do servidor X.Org. No entanto, dada a mudança generalizada para projetos significativos Wayland, é pouco provável que alguém ainda resolva investir.
A Red Hat está atualmente se concentrando em melhorar o trabalho de desktop baseado em Wayland. Então, espera-se que o servidor X.Org seja colocado em modo de manutenção. Isso depois de resolver o problema de eliminar completamente os componentes dependências X.Org. Além disso, é preciso garantir que o GNOME Shell comece a usar XWayland ainda não utilizado. Portanto, requer a refatoração ou remoção dos links restantes para o X.org. Esses links já foram quase removidos do Shell, porém ainda permanecem na configuração do Gnome.
Somente a partir do Gnome 3.34 ou 3.36, é que está previsto para se livrar completamente das ligações de X.Org e organizar o lançamento do XWayland dinamicamente. No entanto, quando a necessidade surge, haverá componentes para garantir a compatibilidade com o X11.
A Red Hat prefere concentrar seus esforços no Wayland
A necessidade de resolver uma série de problemas pendentes Wayland, também é mencionada. Assim como trabalhar com drivers proprietários NVIDIA e refinar o servidor XWayland DDX para garantir a liberação de aplicações baseadas em X de qualidade no ambiente de Wayland.
Notícias Relacionadas
Dos 31 trabalhos que estão sendo feitos em preparação para o Fedora, o XWayland está implementando a capacidade de executar aplicativos X com privilégios de root. Essa versão é questionável do ponto de vista da segurança. Porém é necessário garantir a compatibilidade com programas X, que exigem privilégios elevados.
Outro desafio é melhorar o suporte do Wayland na biblioteca SDL, por exemplo, para resolver problemas de escala ao executar jogos antigos que executam resoluções baixas de tela.
Além disso, há uma necessidade de melhorar o suporte para o trabalho da Wayland em sistemas com drivers NVIDIA proprietários:
Se Wayland pode trabalhar por muito tempo nesses controladores, então o XWayland nesta configuração ainda não pode usar recursos de aceleração de hardware para gráficos 3D. Planeja-se fornecer a capacidade de download de drivers x.org NVIDIA para XWayland.
Outros trabalhos em andamento
Além disso, há um trabalho para substituir PulseAudio e Jack com servidor de mídia PipeWire, que expande as capacidades do PulseAudio com streaming de vídeo e processamento de áudio com latência mínima. Isso tendo em conta as necessidades dos sistemas de processamento de áudio profissional, além de oferecer um modelo de segurança aprimorado para o controle de acesso no nível de dispositivo individual.
Finalmente, como parte do ciclo de desenvolvimento do Fedora 31, o trabalho se concentra no uso do PipeWire para compartilhar o acesso à tela em ambientes baseados em Wayland, incluindo o uso do protocolo Miracast.
Para o Fedora 31 também está planejada a habilidade de iniciar aplicativos Qt em uma sessão Wayland baseada no Gnome usando o plugin Qt Wayland ao invés do plugin XCB usando X11/XWayland.
