Niewątpliwie najważniejszym elementem systemu dla użytkownika domowego jest graficzna obsługa komputera. Właśnie przez taki pryzmat Linux jest odbierany przez początkujących, a wszelkie niedociągnięcia w tej materii negatywnie odbijają się na jego wizerunku. Gdy system z pingwinem w logo dopiero się rodził postanowiono, że do celu wyświetlania okien wykorzysta się powszechnie stosowany już w innych Uniksach X Window System. W mniej więcej takim stanie Linux dotrwał do dziś, jednak sytuacja ta może niedługo ulec radykalnej zmianie.

1. Geneza

W latach 80-tych dwudziestego wieku obsługę komputera przez klawiaturę, zaczęto rozszerzać o innowacyjny gadżet zwany myszą komputerową (niewątpliwie wynalazek na miarę współczesnego iPhone’a). W owych czasach najpowszechniej stosowanymi systemami komputerowymi były Uniksy. Zrodziła się więc potrzeba stworzenia dla nich technologii, która pozwoli na graficzną obsługę komputera, a dzięki temu skorzystania z dobrodziejstw myszy komputerowej. W 1983 roku na Uniwerytecie Stanford zaprojektowano system zarządzania oknami nazwany W (W jak „window” – okno) dla Uniksa System V. Rok później na MIT przeprojektowano system W pozwalając mu na pracę asynchroniczną. Nazwano go systemem X (kolejna po W litera alfabetu). W ciągu pierwszych trzech lat istnienia, X Window System został poddany 10 rewizjom do wersji X11, która jest powszechnie używana do dziś na Uniksach i systemach uniksopodobnych takich jak Linux. Warto też w tym miejscu zaznaczyć, że w Mac OS X pomimo tego, że natywnym systemem renderowania grafiki jest Quartz, to jednak nadal obecny jest tam X Window System zapewniając mu kompatybilność z Uniksowymi aplikacjami. Główne cele, które przyświecały X-om, to:

• Transparentność sieciowa: powstawały w czasach gdy na jednym silnym komputerze pracowało się przy pomocy podłączonych do niego cienkich klientów – obsługa takich klientów musiała być prosta i dopracowana.
• Przenośność kodu: w czasach gdy dla niemalże każdego komputera projektowało się oddzielnego Uniksa portowanie systemu graficznego nie mogło być skomplikowane.
• Warstwa abstrakcji: oddzielenie programu od sprzętu warstwą X-ów miało ułatwić tworzenie aplikacji graficznych – nie trzeba programować pod konkretny sprzęt.

X-y działają na tradycyjnej zasadzie serwer-klient. Dlatego samo oprogramowanie nazywa się serwerem X. Ów serwer uruchamiany jest na konkretnej maszynie, a klientami są komputery, które się z nią komunikują. Oprogramowaniem będącym klientem może być pojedynczy program np. xterm, albo nawet cała sesja np. lightdm (na Ubuntu wywoływany poleceniem „startx”). W dzisiejszych czasach na PC-tach mamy najczęściej do czynienia z sytuacją, gdy jeden komputer jest zarówno serwerem, jak i klientem X-ów. W takim wypadku komunikacja nie odbywa się oczywiście po sieci, ale za pomocą komunikacji międzyprocesowej. Powoduje to skrócenie do minimum czasu potrzebnego na przesyłanie danych. Serwer X pozwala na wykorzystanie możliwości kart graficznych np. EXA i UXA dla grafiki 2D, jak i GLX dla grafiki 3D. Dzięki temu wszelkie operacje mogą korzystać z akceleracji sprzętowej, co jest olbrzymim skokiem naprzód względem wcześniejszych podejść koncentrujących się jedynie na kopiowaniu buforu ramki. Kolejną cechą X-ów jest to, że w żaden sposób nie ograniczają stylu aplikacji graficznych. Nie zarządzają nawet dekoracją okien. To zadanie spada więc na menadżer okien np. Compiza. Brak technicznych barier powoduje jednak, że pisanie aplikacji staje się nie lada wyzwaniem, gdyż programista musi zadbać o każdy jej aspekt. Na szczęście dla serwera X przygotowano wiele bibliotek graficznych, w tym najpowszechniej stosowane GTK+ i Qt. Zajmują się one elementami komunikacji z serwerem X, o których programista nie musi wiedzieć, a dzięki temu stały się bardzo powszechnie stosowanymi narzędziami, na podstawie których zbudowano całe środowiska graficzne takie jak GNOME i KDE.

2. Ograniczenia serwera X

Z opisu działania X-ów, który przedstawiłem powyżej zapewne byliście już w stanie wyciągnąć wnioski, że gdy serwer i klient znajdują się na jednej maszynie, to ścieżka komunikacji jest niepotrzebnie tak długa. Tak więc, gdy klient wysyła sygnał, to jest on odbierany przez serwer. Serwer następnie przesyła sygnał do sterowników. Sterowniki korzystając ze sprzętu go przetwarzają, zwracają rezultat serwerowi, który dopiero wtedy wysyła go do klienta. Nie stanowi to problemu, gdy owym sygnałem jest kliknięcie myszki. Jeżeli jednak mówimy o złożonej grafice 3D, to opóźnienia z tego wynikające stają się poważnym problemem. Z tego powodu w 1998 rozszerzono możliwości X-ów o tak zwane DRI (Direct Rendering Infrastructure). Jak sama nazwa wskazuje technologia ta pozwala na bezpośrednie renderowanie grafiki, czyli z pominięciem serwera X. Jej zastosowanie okazało się mieć zbawienne skutki dla wydajności, a wszelkie aplikacje 3D zaczęły z niej intensywnie korzystać. Dynamiczny rozwój doprowadził do wydania w 2007 roku ulepszonej wersji technologii – DRI2. Znaleźliśmy się więc w szczególnie dziwnej sytuacji. Teraz dla Linuksa potrzebne są w zasadzie 2 niezwiązane ze sobą sterowniki do karty graficznej. Jeden (DDX) zajmujący się wolnymi operacjami obsługi serwera X, np. obsługą okien, oraz drugi (DRI) zajmujący się szybkim przetwarzaniem grafiki. Zaczęły też pojawiać się pytania – skoro tak wydajnie przetwarza się grafikę z pominięciem X-ów, to czy w ogóle ich potrzebujemy?

Wymiana karty graficznej na uruchomionym systemie faktycznie mogła się nie mieścić w głowie inżynierów z lat 80-tych, jednak na takiej zasadzie działają właśnie układy hybrydowe stosowane powszechnie we współczesnych laptopach. Serwer X nie był więc przygotowany do takich zastosowań, a dzisiaj wielu użytkowników z tego powodu pokutuje. Samo dostosowanie X-ów do takiego sprzętu okazuje się być olbrzymim wyzwaniem i nie wiadomo, czy w ogóle uda się je w pełni zrealizować.

Takich bagaży swojej przeszłości serwer X niesie ze sobą wiele. Żeby aplikacja mogła komunikować się z serwerem musi mieć zaimplementowane wiele antycznych funkcji, z których i tak nie będzie korzystać. Niektórzy mogą mówić, że nie warto się tym przejmować, skoro bezpośrednio z X-ami komunikuje się jedynie biblioteka graficzna i menadżer okien. Jednak czemu developerzy tych programów mają marnować czas na implementowanie niepotrzebnych i skomplikowanych funkcji? A co jeżeli jakiś developer np. Compiza popełni błąd i aplikacja z niego korzystająca odczuje tego skutki? Wszyscy zdajemy sobie sprawę z problemów z wydajnością Unity. Być może dałoby się im zapobiec, gdyby Compiz mógł być dużo prostszym programem.

Warto też poruszyć kwestię bezpieczeństwa. Znowu naleciałości z czasów UMS (User Mode Setting) powodują, że serwer X musi zostać uruchomiony z prawami roota (administratora). Nie muszę chyba nikogo przekonywać, że przyznawanie programowi większych uprawnień, niż niezbędne minimum, to zawsze jest luka w bezpieczeństwie.

Między innymi te powody zmotywowały programistów do wypracowania nowoczesnego sposobu wyświetlania grafiki na Linuksie. Tak właśnie zaczyna rodzić się Wayland.

3. Wayland

Zacząć należałoby od kardynalnej uwagi. Wayland to nie jest serwer wyświetlania. Powstał w końcu właśnie po to, żeby zlikwidować niepotrzebną warstwę jaką jest serwer X. Wayland to jedynie protokół (X-y to serwer oraz protokół) komunikacji pomiędzy jądrem systemu a menedżerem okien (menedżerem kompozycji – żeby być precyzyjnym). Nawet na współczesnych X-ach sam menedżer okien głównie zajmuje się tym co, gdzie i jak jest wyświetlane. Wayland zrzuca na niego dodatkowo kilka niezbędnych funkcji, ale dzięki temu serwer X staje się zupełnie zbyteczny i nie musi być instalowany. Takim referencyjnym menadżerem okien proponowanym przez Waylanda jest Weston, ale oczywiście każdy inny też może zostać dostosowany do korzystania z tego protokołu. Na szczególną uwagę zasługuje to, że Wayland nie potrzebuje żadnych specyficznych sterowników. Korzysta z tych, które są już dostępne w jądrze systemu (DRI, itp.) oraz z wbudowanych w jądro mechanizmów obsługi wydarzeń. Mamy więc też ładny podział uprawnień. Sterowniki pracują w przestrzeni jądra (zapewniając dodatkowo maksymalną wydajność), natomiast menedżer kompozycji i jego okna działają w przestrzeni użytkownika (i nie wymagają żadnych dodatkowych uprawnień). Dodatkowo cała wyświetlana grafika jest przetwarzana jedynie przy pomocy mechanizmów DRI. Nie ma znaczenia czy wyświetlane jest 3D, czy 2D – wszystko będzie działać z maksymalną wydajnością. Ba – nawet menedżer okien nie wie co jego okna wyświetlają (wie tylko w którym miejscu ekranu to robią). Owocuje to maksymalnym „skróceniem formalności” przed dostarczeniem obrazu na ekran. Należy też podkreślić, że Wayland zachowuje wsteczną kompatybilność względem X-owych aplikacji. W momencie, w którym taki program zostaje uruchamiony, to dla niego uruchomi się też serwer X (jako klient menadżera okien) i będzie odpowiadał za wyświetlanie danego okna. Tak więc migracja na Waylanda nie będzie wiązać się z utratą cennych aplikacji. Canonical doskonale widzi potencjalne zalety wynikające z tej technologii dla domowego użytkownika. Będzie starał się jak najszybciej dokonać migracji (chociaż jeszcze nie w Ubuntu 12.10), dzięki czemu ma zamiar uzyskać stabilniejsze i wydajniejsze środowisko graficzne.

4. Ograniczenia Waylanda

Nie wszystko jest jednak tak różowe. Przynajmniej w początkowej fazie adaptacja Waylanda będzie wiązała się z kilkoma wyrzeczeniami, które trzeba wyraźnie zaznaczyć.

Zamknięte sterowniki do grafik AMD i NVIDIA nie wspierają protokołu Wayland i nie wygląda na to, żeby w najbliższym czasie miały to robić. Dopiero, gdy producenci tych kart graficznych staną przed faktyczną sytuacją migracji, to być może zainteresują się dostosowaniem swoich sterowników do tego rozwiązania. Póki co pozostają dla Waylanda jedynie otwarte sterowniki intel, radeon i nouveau.

Najbardziej krytykowaną jednak cechą Waylanda jest to, że jego architektura powoduje utratę transparentności sieciowej. Osobiście jednak nie uważam tego za poważny problem, gdyż nadal będzie można zdalnie pracować w środowisku graficznym korzystając z innych powszechnych technologii, takich jak chociażby VNC.

Brak natywnego OpenGL. Niestety dobrze przeczytaliście. Nie bez kozery API OpenGL dla Linuksa nazywa się GLX. Po prostu serwer X jest już wpisany w ten interfejs i nie da się tego obejść. Póki co Wayland natywnie korzysta z OpenGL ES. Twórcy tego API byli na szczęście na tyle rozsądni (zapewne z powodu Androida, który z X-ów nie korzysta), że nie zależy ono od serwera X. W przyszłości trzeba będzie wypracować zapewne nowe API (WaylandGL?), które pozwoli na pełne korzystanie z OpenGL na Waylandzie. Oznacza to że nawet po wprowadzeniu nowego protokołu, aplikacjom, które chcą skorzystać z pełnego OpenGL pozostaną jedynie X-y.

Należy też wspomnieć, że silne związanie Waylanda z Linuksowymi mechanizmami jądra czyni go praktycznie nieprzenośnym na inne Uniksy. Jest to więc rozwiązanie wyłącznie dla Linuksa.

5. Podsumowanie

Wydanie Wayland 1.0 odbędzie się w najbliższym czasie. Nie jest to jednak moment, w którym X-y zostaną nagle zabite, a raczej wyznacza początek czasu, gdy protokół będzie utrzymywał wsteczną kompatybilność. Mam nadzieję, że powyższy artykuł pozwolił wam przybliżyć tematykę zarówno serwera X, jak i nadchodzącego Waylanda. Znajomość zagadnienia zapewne przyda się w czasie tranzytowym. Zrozumienie potrzeby zmian i korzyści z nich płynących powinno zatem ograniczyć obawy związane z nowym sposobem wyświetlania grafiki w Linuksie.