Christian Schaller, som leder skrivbordsutvecklingsteamet på Red Hat och Fedora Desktop Team, i en granskning av planer för skrivbordskomponenter i Fedora 31, nämnde Red Hats avsikt att sluta aktivt utveckla X.Org-serverfunktionalitet och begränsas endast till att underhålla den befintliga kodbasen och felsökning.
För närvarande ger Red Hat ett nyckelbidrag till utvecklingen av X.Org-servern och bibehåller sitt stöd, därför är det osannolikt att bildningen av betydande utgåvor av X.Org-servern kommer att fortsätta, i händelse av att utvecklingen avbryts.
Samtidigt, trots att utvecklingen upphört, kommer Red Hats stöd för X.Org att fortsätta åtminstone till slutet av RHEL 8-distributionslivscykeln, som kommer att pågå till 2029.
Utvecklingen av X.Org är redan minimal
Stagnationen i utvecklingen av X.Org-servern har redan observerats. Trots den tidigare använda sexmånaders releasecykeln, den senaste betydande versionen av X.Org Server 1.20 släpptes för 14 månader sedan och förberedelserna för version 1.21 stagnerar.
Situationen kan förändras om något företag eller någon gemenskap åtar sig att fortsätta utöka funktionaliteten på X.Org-servern, men med tanke på den omfattande förskjutningen av betydande projekt mot Wayland, är det osannolikt att det kommer att finnas någon.
Red Hat fokuserar för närvarande på att förbättra den Wayland-baserade skrivbordsarbetsstationen. X.Org-servern förväntas gå in i underhållsläge efter att ha löst problemet med att helt ta bort X.Org-komponentberoenden och säkerställa att Gnome-skalet startar utan att använda XWayland, vilket kräver omstrukturering eller ta bort eventuella återstående länkar till X.org.
Dessa länkar tas nästan bort från Gnome-skalet men finns fortfarande kvar i Gnome-inställningarna.
I Gnome 3.34 eller 3.36 är det planerat att bli av med X.Org-bindningar helt och att dynamiskt släppa XWayland, när behovet av komponenter uppstår för att säkerställa kompatibilitet med X11.
Red Hat föredrar att fokusera sina ansträngningar på Wayland
Behovet av att lösa en rad pågående problem med Wayland nämns också, som att arbeta med NVIDIAs proprietära drivrutiner och förfina XWayland DDX-servern för att säkerställa kvalitetslansering av X-applikationer i en Wayland-baserad miljö.
Av de 31 jobb som görs som förberedelse för Fedora, implementerar XWayland möjligheten att köra X-applikationer med root-privilegier. En sådan lansering är tveksam ur säkerhetssynpunkt, men det är nödvändigt att säkerställa kompatibilitet med X-program, som kräver förhöjda privilegier.
En annan utmaning är att förbättra Wayland-stödet i SDL-biblioteket, till exempel för att lösa skalningsproblem när du kör äldre spel som körs med låg skärmupplösning.
Dessutom, det finns ett behov av att förbättra stödet för Wayland som arbetar med system med NVIDIAs proprietära drivrutiner:
om Wayland kan arbeta med sådana drivrutiner under lång tid, kan XWayland i den här konfigurationen fortfarande inte använda hårdvaruacceleration för 3D-grafik (det är planerat att ge möjligheten att ladda ner x.org NVIDIA-drivrutiner för XWayland).
Dessutom, arbete pågår för att ersätta PulseAudio och Jack med PipeWire mediaserver, som utökar kapaciteten hos PulseAudio med videoströmning och ljudbearbetning med minimal latens, med hänsyn till behoven hos professionella ljudbehandlingssystem, samt erbjuder en förbättrad säkerhetsmodell för åtkomstkontroll på enhetsnivå.
Slutligen, som en del av utvecklingscykeln för Fedora 31, fokuseras arbetet på användningen av PipeWire för skärmdelning i Wayland-baserade miljöer, inklusive användningen av Miracast-protokollet.
till Fedora 31 är också planerat att lägga till möjligheten att starta Qt-applikationer i en Gnome-baserad Wayland-session. använder Qt Wayland plugin istället för XCB plugin med X11/XWayland.