Christian Schaller, który kieruje zespołem programistów komputerów stacjonarnych w Red Hat i zespołem Fedory ds. komputerów stacjonarnych, , odnośnie komponentów desktopowych w Fedorze 31, wspomniał o zamiarze Red Hata zaprzestania aktywnego rozwijania funkcjonalności serwera X.Org i ograniczenia się jedynie do utrzymywania istniejącej bazy kodu i eliminowania błędów.
Obecnie Red Hat wnosi kluczowy wkład w rozwój serwera X.Org i utrzymuje go na swoich barkach, więc jeśli zostanie usunięty z rozwoju, jest mało prawdopodobne, że tworzenie znaczących wydań serwera X.Org będzie kontynuowane. Jednocześnie, pomimo zaprzestania rozwoju, wsparcie X.Org przez firmę Red Hat będzie kontynuowane co najmniej do końca cyklu życia dystrybucji RHEL 8, który potrwa do 2029 roku.
Zastój w rozwoju serwera X.Org można już zaobserwować – pomimo stosowanego wcześniej sześciomiesięcznego cyklu wydawniczego, ostatnia znacząca wersja X.Org Server 1.20 ukazała się 14 miesięcy temu, a przygotowanie wydania 1.21 utknęło w martwym punkcie. Sytuacja może się zmienić, jeśli jakaś firma lub społeczność podejmie się dalszego rozwijania funkcjonalności serwera X.Org, jednak biorąc pod uwagę powszechne przesunięcie znaczących projektów w stronę Waylanda, jest mało prawdopodobne, że znajdą się chętni.
Obecnie firma Red Hat koncentruje się na ulepszaniu środowiska graficznego Wayland. Oczekuje się, że przeniesienie serwera X.Org do trybu konserwacji zostanie zakończone po całkowitym usunięciu zależności od komponentów X.Org i powłoce GNOME Shell będzie działać bez użycia XWayland, co wymaga refaktoryzacji lub usunięcia pozostałych zależności X.org. Takie powiązania zostały prawie wyeliminowane z powłoki GNOME, ale nadal pozostają w demonie ustawień GNOME. W GNOME 3.34 lub 3.36 planowane jest całkowite pozbycie się powiązań z X.Org i uruchomienie XWayland , gdy pojawia się potrzeba komponentów zapewniających kompatybilność z X11.
Wspomniano także o konieczności rozwiązania szeregu z Waylandem, takie jak praca z zastrzeżonymi sterownikami NVIDIA i ulepszanie serwera XWayland DDX, aby zapewnić wysokiej jakości uruchamianie aplikacji X w środowisku opartym na Wayland. Wśród prac przeprowadzonych w ramach przygotowań do Fedory 31 odnotowuje się wdrożenie w XWayland możliwości uruchamiania aplikacji X z uprawnieniami roota. Takie uruchomienie jest wątpliwe z punktu widzenia bezpieczeństwa, ale jest konieczne, aby zapewnić kompatybilność z programami X, które wymagają działania z podwyższonymi uprawnieniami.
Kolejnym celem jest ulepszenie obsługi Waylanda w bibliotece SDL, na przykład w celu rozwiązania problemów ze skalowaniem podczas uruchamiania starszych gier działających na niskich rozdzielczościach ekranu. Istnieje także potrzeba poprawy obsługi Waylanda na systemach z autorskimi sterownikami NVIDIA - o ile Wayland od dawna potrafi pracować na takich sterownikach, o tyle XWayland w tej konfiguracji nie może jeszcze korzystać z narzędzi do sprzętowej akceleracji grafiki 3D (w planach jest zapewniają możliwość pobrania sterownika x.org NVIDIA dla XWayland).
Dodatkowo trwają prace nad zastąpieniem PulseAudio i Jacka serwerem multimediów , który rozszerza możliwości PulseAudio o narzędzia do pracy ze strumieniami wideo i przetwarzania dźwięku z minimalnymi opóźnieniami, uwzględniając potrzeby profesjonalnych systemów przetwarzania dźwięku, a także oferuje zaawansowany model bezpieczeństwa kontroli dostępu na poziomie poszczególnych urządzeń i strumieni . W ramach cyklu rozwojowego Fedory 31 prace skupiają się na wykorzystaniu PipeWire do udostępniania ekranu w środowiskach opartych na Wayland, w tym na wykorzystaniu .
W Fedorze 31 również dodać możliwość uruchamiania aplikacji Qt w sesji GNOME opartej na Wayland przy użyciu wtyczki Qt Wayland zamiast wtyczki XCB przy użyciu X11/XWayland.
Źródło: opennet.ru