Christian Schaller, który kieruje zespołem programistów komputerów stacjonarnych w firmie Red Hat i komputer stacjonarny Fedory, w przeglądzie planów dotyczących składników pulpitu w Fedorze 31, wspomniał o zamiarze firmy Red Hat, aby przestać aktywnie rozwijać funkcjonalność serwera X.Org i ogranicz się tylko do utrzymania istniejącej bazy kodu i debugowania.
Obecnie Red Hat wnosi kluczowy wkład w rozwój serwera X.Org i utrzymuje jego wsparcie, dlatego w przypadku wstrzymania rozwoju jest mało prawdopodobne, aby powstawały znaczące wydania serwera X.Org.
Jednocześnie, pomimo zaprzestania rozwoju, wsparcie Red Hata dla X.Org będzie kontynuowane co najmniej do końca cyklu życia dystrybucji RHEL 8, który potrwa do 2029 roku.
Rozwój X.Org jest już minimalny
Zaobserwowano już zastój w rozwoju serwera X.Org. Pomimo sześciomiesięcznego cyklu wydawniczego, który był używany wcześniej, ostatnia znacząca wersja X.Org Server 1.20 została wydana 14 miesięcy temu i przygotowania do wersji 1.21 utknęły w martwym punkcie.
Sytuacja może ulec zmianie, jeśli jakakolwiek firma lub społeczność zobowiąże się do dalszego zwiększania funkcjonalności serwera X.Org, Ale biorąc pod uwagę powszechne przejście od znaczących projektów do Wayland, jest mało prawdopodobne, aby ktokolwiek się pojawił.
Firma Red Hat obecnie koncentruje się na usprawnieniu pracy na komputerach stacjonarnych w Wayland. Oczekuje się, że serwer X.Org przejdzie w tryb konserwacji po rozwiązaniu problemu całkowitego usunięcia zależności od komponentów X.Org i upewnieniu się, że powłoka Gnome uruchamia się bez użycia XWayland, co wymaga refaktoryzacji lub usunięcia pozostałych linków do X.org.
Te linki są prawie usunięte z Gnome Shell, ale nadal pozostają w ustawieniach Gnome.
W Gnome 3.34 lub 3.36 planowane jest całkowite porzucenie wiązań X.Org i dynamiczna organizacja wydania XWayland, gdy pojawi się potrzeba komponentów, aby zapewnić kompatybilność z X11.
Red Hat woli skupić się na Waylandzie
Wspomina się również o potrzebie rozwiązania szeregu nierozstrzygniętych problemów z Wayland, jak pracować z zastrzeżonymi sterownikami NVIDIA i udoskonalać serwer XWayland DDX, aby zapewnić wysokiej jakości uruchamianie aplikacji X w środowisku opartym na Wayland.
Spośród 31 zadań wykonywanych w ramach przygotowań do Fedory, XWayland implementuje możliwość uruchamiania aplikacji X-ów z uprawnieniami roota. Takie wydanie jest wątpliwe z punktu widzenia bezpieczeństwa, ale jest konieczne, aby zapewnić kompatybilność z programami X, które wymagają podwyższonych uprawnień.
Kolejnym wyzwaniem jest poprawa obsługi Waylanda w bibliotece SDL, na przykład, aby rozwiązać problemy ze skalowaniem podczas uruchamiania starszych gier, które działają w niskich rozdzielczościach ekranu.
Ponadto, Istnieje potrzeba usprawnienia obsługi pracy Waylanda w systemach z zastrzeżonymi sterownikami NVIDIA:
jeśli Wayland może pracować na takich sterownikach przez długi czas, to XWayland w tej konfiguracji nie może jeszcze wykorzystywać możliwości akceleracji sprzętowej dla grafiki 3D (planowane jest zapewnienie możliwości pobierania sterowników x.org NVIDIA dla XWayland).
Ponadto, trwają prace nad zastąpieniem PulseAudio i Jacka PipeWire Media Server, który rozszerza możliwości PulseAudio o przesyłanie strumieniowe wideo i przetwarzanie dźwięku z minimalnym opóźnieniem, biorąc pod uwagę potrzeby profesjonalnych systemów przetwarzania dźwięku, a także oferuje ulepszony model bezpieczeństwa dla indywidualnej kontroli dostępu na poziomie urządzenia.
Wreszcie, jako część cyklu rozwojowego Fedory 31, prace koncentrują się na użyciu PipeWire do udostępniania dostępu do ekranu w środowiskach opartych na Wayland, w tym na użyciu protokołu Miracast.
do W Fedorze 31 planowane jest także dodanie możliwości uruchamiania aplikacji Qt w sesji Waylanda opartej na Gnome. używając wtyczki Qt Wayland zamiast wtyczki XCB używającej X11 / XWayland.