X.Org a Wayland — czyli stary król i młody następca tronu

System okien - co to jest?

System okien jest to komponent graficznego interfejsu użytkownika (GUI) odpowiadający nie tylko za obsługę grafiki, ale też za obsługę myszki, klawiatury i innych urządzeń wejściowych. Udostępnia on menedżerom okien prostokątne obszary (zwane oknami), w których następnie rysowane są elementy interfejsu, takie jak przyciski, menu, scrolle itd.

System okien zajmuje się jednak najbardziej niskopoziomowymi rzeczami. Za to co widzimy (wspomniane wyżej elementy interfejsu) odpowiadają inne składniki, takie jak menedżery okien czy biblioteki widżetów. Ogólnie w wielu graficznych systemach operacyjnych zawierających zintegrowane (i niedostępne nigdzie indziej) systemy okien, te składniki są często łączone i nie ma wyraźnej granicy pomiędzy systemem okien a menedżerem okien. Taka granica jest widoczna w najpopularniejszym systemie okien dostępnym na systemy Uniksowe: X Window System (jego najpopularniejszą dzisiaj implementacją jest X.Org). Wayland jednak zwraca się ku komercyjnym rozwiązaniom. Ale zanim przejdziemy do opisu architektury, to najpierw trochę historii.

Historia X Window System oraz Wayland

X Window System (będę go określał w skrócie X/X11) nie jest pierwszym systemem okien operującym na bitmapach. Tak samo na bitmapach operowały systemy operacyjne (a właściwie ich systemy okien) dołączane z komputerami takimi jak: Xerox Alto, Xerox Star, Apple Lisa, Apple Macintosh itd.

Historia X wiąże się z projektem zwanym Project Athena. Był to projekt tworzony wspólnie przez MIT, IBM, Digital Equipment Corporation, który wystartował w 1984 roku, a trwał aż do połowy roku 1991. Jego głównym celem była poprawa jakości edukacji na uniwersytetach. Chciano, żeby użytkownik mógł podejść do dowolnej stacji roboczej i swobodnie przeglądać pliki czy aplikacje bez większych różnic pomiędzy interfejsem a usługą, zupełnie jak w dzisiejszym internecie. Do osiągnięcia tego celu potrzebowano jednak niezależnego od jednej platformy systemu graficznego, który ujednolici produkty różnych producentów.

Problem postanowiono rozwiązać tworząc protokół, który będzie pozwalał uruchamiać zarówno aplikacje lokalnie jak i przez sieć. Na Uniksa sportowano (w połowie 1983 roku) system okien W z systemu operacyjnego V. Jednakże, pracował on sporo wolniej (nawet 5 razy), niż na swoim natywnym systemie operacyjnym. W maju 1984 roku Scheifler zastąpił synchroniczny protokół W asynchronicznym protokołem, który został nazwany X. Pierwsza wersja X została pierwszym systemem okien oferującym prawdziwą niezależność od platformy i producenta.

X zaczął rozwijać się szybko, dzięki pracy Scheifler’a, Gettys’a i Ron’a Newman’a. W styczniu 1985 roku została wydana wersja 6 nowego systemu okien. DEC (Digital Equipment Corporation) postanowiła go wykorzystać w swojej stacji roboczej Ultrix. Ich inżynierowie sportowali X6 na QVSS pracujący na MicroVAX. W drugim kwartale 1985 roku X wraz z wersją 9 dostał obsługę kolorów działającej na VAXstation-II/GPX.

X rozwijał się dalej będąc portowany na coraz to więcej platform. MIT zdecydowało się wydać X10R3 (luty 1986 rok) na wolnej licencji MIT (zwanej też licencją X11), a także zdecydowało się na tej licencji wydawać wszystkie przyszłe wersje. To działanie znacząco zwiększyło popularność X. 15 września 1987 roku wydano jedenastą wersję protokołu, zwaną X11. Ta wersja protokołu do dzisiaj jest stosowana w dzisiejszych implementacjach. Stąd też popularna nazwa: X11.

W styczniu 1988 roku powołano MIT X Consortium jako grupę non‑profit z Scheifler’em na czele. Jej celem było ustalanie kierunku rozwoju X w neutralnej atmosferze, zarówno biorąc pod uwagę komercyjne jak i edukacyjne interesy. W 1993 grupa ostatecznie odłączyła się od MIT i na jej miejsce powołano X Consortium, Inc. (korporacje typu non‑profit). W 1995 wzieła pod swoje skrzydła toolkit Motif oraz jedno z najstarszych środowisk Uniksowych – Common Desktop Environment, w skrócie CDE. Na początku roku 1997 przekazano zarządzanie dalszym losem X do The Open Group (grupę zajmującą się rozwojem otwartych standardów. Posiada ona też prawa do nazwy UNIX). Wydana przez nich wersja X116.4 przestała być wolnym oprogramowaniem – była darmowa do użytku tylko niekomercyjnego. Na skutek nacisku, głównie ze strony XFree86 (było gotowe na fork), The Open Group się ugięła i przywróciła X11 jako wolne oprogramowanie.

Jedna z pierwszych popularnych implementacji X11 nazywała się XFree86. Powstała ona w 1992 roku z projektu X386. Dostarczała ona implementację X11 dla komputerów kompatybilnych z IBM PC dla systemów Uniksowych. W połowie roku 1999 The Open Group powołało X.Org, które dostało pod nadzór X11R6.5.1 i wszystkie późniejsze. Jednakże rosnąca popularność Linuksa i dostarczanego razem z nim XFree86 spowodowała, że to XFree86 wprowadzało innowacje i nowości w X11. Na skutek zachęt różnych producentów dołączyło do The Open Group jako honorowy członek bez konieczności płacenia grupie. W 2003 roku X.Org praktycznie pozostawał nieaktywny, a główny prym w rozwoju X11 wiódł XFree86. Jedną z ważniejszych osób uczestniczących w rozwoju implementacji XFree86 był Keith Packard.

Niestety, zmiana licencji części kodu XFree86 w lutym 2004 roku na bardziej restrykcyjną licencje zakończyła jego panowanie. Nowa licencja została uznana przez Free Software Foundation oraz Debiana za niekompatybilną z GNU GPL. Nie spodobało się to środowisku Open Source, które uznało to za pogwałcenie tradycji X11, jako wolnego i niezależnego systemu okien. Krótko po tym rózne osoby należące do X.Org oraz do freedesktop.org powołali X.Org Foundation, do którego dołączył m.in. Keith Packard, a The Open Group przekazało nowej organizacji prawa i nadzór nad domeną x.org. Sforkowano także ostatnią wersję XFree86 na wolnej licencji i nową implementację nazwano X.Org Server. Wielu deweloperów wcześniejszej implementacji przeniosło się także do nowej. Pomimo, że rozwój XFree86 trwał jeszcze kilka lat (ostatnią wersje wydano 15 grudnia 2008 roku), to jednak na zawsze utracił swoją popularność i został zastąpiony X.Org Server. Nowy serwer stał najpopularniejszą implementacją X11 i do dzisiaj jest rozwijany i używany. Jest głównym systemem okien w większości systemów uniksowych (np. Linux, *BSD), a jego porty znaleźć można nawet na systemach takich jak Microsoft Windows, które z Uniksem mają niewiele wspólnego.

Jednakże trudno dostosować jest pomysł z ubiegłego wieku do wymagań dzisiejszych czasów. X11 z czasem stawał się coraz trudniejszy do rozwoju. Dodawano do niego rozszerzenia mające zapewnić obsługę nowego sprzętu i zaspokoić wymagania dzisiejszych konsumentów. Trzeba to było jednak robić tak, by zachować wsteczną kompatybilność. W X11 znajdziemy kilka API do obsługi jednej rzeczy. Na temat problemów trapiących X11 pojawił się news na portalu dobreprogramy, znajdziecie go tutaj. I tu właśnie wkracza Wayland. Kristian Hoegsberg, deweloper X.Org, który pracował nad AIGLX oraz DRI2 rozpoczął prace nad Waylandem w 2008 roku, jako poboczny projekt obok swojej pracy w Red Hat. Jako cel projektu Hoegsberg określił:

Różnice w architekturze X.Org oraz Wayland

Oba projekty, pomimo że odpowiadają za to samo, to jednak różnią się mocno założeniami.

Architektura: W X11 menedżer kompozycji to osobna, opcjonalna aplikacja. Wayland łączy ze sobą serwer wyświetlania oraz menedżer kompozycji, a także przyjmuje część funkcji menedżera okien, który w X11 jest osobną aplikacją działającą po stronie klienta.

Kompozycja: W X11 obsługa kompozycji jest opcjonalna, lecz w Waylandzie jest już obowiązkowa. Ponadto w X11 kompozycja jest aktywna, czyli kompozytor musi pobrać wszystkie dane pikseli, co powoduje opóźnienia. Kompozycja w Waylandzie jest pasywna, a więc kompozytor może bezpośrednio pobierać dane pikseli od klientów.

Wyświetlanie: Serwer X11 jest sam w stanie wyświetlać dane, Wayland jednak nie posiada żadnego API do wyświetlania, lecz część zadań przekazuje klientom (wyświetlanie fontów, widgetów itd.). Dekoracje okna mogą być wyświetlane zarówno po stronie serwera (przez kompozytor) jak i po stronie klienta (przez toolkit).

Bezpieczeństwo: Wayland izoluje wejście i wyjście każdego okna, zachowując integralność, czego nie potrafi X11. Ponadto więcej rzeczy w Waylandzie jest wykonywane po stronie klienta, co wymaga uruchomienia mniejszej ilości kodu z prawami administratora, niż w X11.

Komunikacja między procesami: X11 oferuje metody komunikacji pomiędzy procesami. Używane są m.in. do implementacji drag-and-drop (transferu danych pomiędzy oknami). Protokół Waylanda nie posiada żadnych metod komunikacji i implementacja takowych musi być zrealizowana przez środowisko graficzne, bądź przez trzecie projekty.

Sieć: X11 został zaprojektowany jako transparentny sieciowo, co oznacza, że nie ma dla niego różnicy, czy serwer i klienci działają na tej samej maszynie, czy komunikują się przez sieć. Wayland sam w sobie nie jest transparentny sieciowo i nie posiada metod komunikacji przez sieć. Zdalna obsługa musi być zaimplementowana przez kompozytor.

W X11 jest wyraźny podział pomiędzy serwerem wyświetlania, a menedżerem okien czy menedżerem kompozycji (chociaż część menedżerów okien X11, jak Mutter czy KWin, posiadają wbudowane menedżery kompozycji). W Waylandzie nie funkcjonuje taki podział. Serwer wyświetlania, menedżer okien i menedżer kompozycji to teraz jedna aplikacja zwana kompozytorem Waylanda. Jest to podejście podobne do stosowanego dzisiaj w Microsoft Windows czy OS X (macOS). Pomimo, że zwiększa to skomplikowanie, to jednak zwiększa też wydajność, bowiem kompozytory operują znacznie bliżej sprzętu, niż menedżery okien X11. Serwerem okien w przypadku X11 nazywamy serwer X (np. X.Org Server), w przypadku Waylanda jest to kompozytor (np. Weston). To serwer odpowiada za wyświetlanie wszystkiego i obsługę urządzeń wejściowych. Przyjmuje także żądania klientów. Klientem w X11 jest menedżer okien, oraz aplikacje na nim działajace, w Waylandzie jest to aplikacja pracująca na danym kompozytorze. Warto też wspomnieć o innej różnicy – X11 celował w bycie niezależnym od systemu. Wayland to projekt Linuksowy i robi użytek z mechanizmów dostępnych w jego kernelu – nie jest więc tak łatwo portowalny na inne platformy, jak X11.

Sytuacja Waylanda dzisiaj

Wayland jest w ciągłym rozwoju i jest podawany jako następca X11. Część popularnych toolkit’ów posiada już wsparcie dla niego, m.in. GTK+3, Qt5, SDL, GLFW itd. Nieco gorzej wygląda sprawa w środowiskach na Waylanda. Poza Westonem, będącym przykładowym kompozytorem (został stworzony po to, by twórcy kompozytorów mieli przykład jak powinien być napisany kompozytor Waylanda), swoje wsparcie dla niego mają też Mutter (menedżer okien GNOME3) oraz KWin (menedżer okien KDE), oraz wiele innych. Z dużych środowisk, które uruchomimy dziś na Waylandzie (nadal trwają pracę nad portem, więc nie wszystko może pracować jak należy) należy wymienić GNOME3, KDE Plasma 5 oraz Enlightenment. Dostępnych jest też część pomniejszych środowisk, jak np. Hawaii Desktop Environment. Tizen oraz Sailfish OS są zbudowane z użyciem Waylanda.

Nieco gorzej wygląda sprawa ze sterownikami. Obecnie Wayland działa tylko na otwartych sterownikach. Fglrx (zwany też Catalyst, bądź Crimson) został porzucony przez AMD i zastąpiony nowym, więc obsługi Waylanda nie dostanie nigdy. Nowy sterownik AMD (zwany AMDGPU-Pro) również nie obsługuje Waylanda, uruchomimy go jednak na otwartej wersji tego sterownika. nVidia wprawdzie dodała wsparcie do Waylanda w swoim zamkniętym sterowniku, jednak nie uruchomimy na nim żadnego środowiska – nVidia nie zaimplementowała GBM (wykorzystywanego przez chyba każdy kompozytor Waylanda), twierdząc, że EGL‑Streams to lepszy pomysł. Intel posiada wyłącznie otwarte sterowniki, tak więc nie ma żadnego problemu z obsługą nowego systemu okien. Warto wspomnieć, że dzięki libhybris, Wayland potrafi obsłużyć sterowniki Androida.

Wayland posiada znacznie mniej natywnego oprogramowania niż X11. Aplikacje budowane z użyciem np. GTK+3 lub Qt5 takie wsparcie posiadają, jednak masę oprogramowania używa ich starszych wersji, bądź innych toolkit’ów bez wsparcia dla nowego protokołu. W celu rozwiązania tego problemu stworzono Xwayland. Jest to specjalna wersja X.Org Server, która została przerobiona tak, że pracuje jako klient Waylanda. Dzięki temu możliwe jest uruchomienie aplikacji X11. To rozwiązanie, pomimo niektórych problemów, pracuje całkiem sprawnie. Zdecydowana większosć aplikacji działa bez problemu dzięki temu – zdarzają się jednak aplikacje problematyczne.

Waylanda możemy zainstalować na chyba każdej popularnej dystrybucji Linuksa. Póki co żadna popularna dystrybucja nie używa go jako domyślnego. Jako pierwsza z taką inicjatywą wyszła Fedora – w wersji 25 domyślnie będzie używać Waylanda. Jak wspomniałem wcześniej, systemy mobilne takie jak. Tizen czy Sailfish OS również go używają.

Zakończenie

To już koniec tego wpisu. Czy Wayland zastąpi wysłużone „iksy”? Moim zdaniem jak najbardziej, tylko będzie to proces, który potrwa jeszcze kilka lat. System okien w Linuksie potrzebuje rewolucji i czegoś, co sprosta wymaganiom XXI wieku. Przede wszystkim najważniejsze jest wsparcie producentów, którzy napiszą sterowniki. Kto chce może używać Waylanda dzisiaj, o ile używa otwartych sterowników i zadowoli się środowiskami dostępnymi na ten system okien. Na powszechne wykorzystywanie przyjdzie nam jednak poczekać jeszcze trochę.

Źródła

Schemat okna

Logo X Window System

CDE

Schemat GUI

Weston

Logo Waylanda

Źródło