przystajnik

Wayland 11 lat później albo spóźnione życzenia

Mało kto w natłoku spraw codziennych zauważył fakt, że 30 września 2019 roku obchodziliśmy 11 lat protokołu Wayland. Ani to okrągła rocznica, ani też dokładny dzień „obchodów”, czy zatem jest co roztrząsać z takim opóźnieniem? Ano wystarczy szybki rzut oka na działający na naszym komputerze serwer Xorg, aby stwierdzić, że coś poszło nie tak.

wayland

Wayland w teorii

Przyczyny powstania Waylanda i tęsknoty za nowoczesnością giną już powoli w pomroce dekad. Bowiem to właśnie w 2008 roku pracujący nad AIGLX oraz DRI2 Kristian Hoegsberg rozpoczął pracę nad projektem, który miał zmienić scenę i pulpit domowego użytkownika Linuksa (i nie tylko). Zauważył on, że obecnie czynione są ogromne wysiłki, aby usprawnić konstrukcję Xorg o nowoczesne rozwiązania, takie jak kompozytor obrazu, który to nierzadko korzysta z pełni mocy karty graficznej (pamiętacie zmagania, aby Compiz zawsze miał pod ręką najnowsze sterowniki NVIDII?). Dzięki temu możliwe stało się wzbogacanie treści i formy ekranowej. Kompozytor jak sama nazwa wskazuje mógł „składać” to co widzimy z kilku elementów i w rezultacie okna mogły być ładniejsze, mogły się pojawić efekty, transformacje zawartości ekranu, itp. Jednak Kristian poszedł krok dalej i stwierdził, że zamiast „doklejać” do całości kompozytor, dlaczego by nie uczynić go sercem serwera wyświetlania? Jak pomyślał tak zrobił.

cde

Takie były początki – środowisko CDE na Linuksie

Warto tutaj przypomnieć sobie w skrócie genezę serwera Xorg. Jego początki to rok 1984, protokół W a potem X i pragnienie, aby program uruchomiony na dowolnym terminalu wyglądał tak samo. W tych czasach to nie było takie oczywiste, gdyż w ramach „terminali” funkcjonowały przeróżne rozwiązania przeróżnych producentów. X Window System miał umożliwić uruchamianie programów zdalnie i lokalnie z zachowaniem jednolitości wizualnej. Zaimplementowane przez Boba Scheifler z MIT asynchroniczna transmisja danych i koncepcja modelu klient serwer, miały wytyczyć dalszą drogą rozwoju. W 1987 roku wydano jedenastą wersję protokołu X i to dlatego do dzisiaj mamy do czynienia z X11. Całość była udostępniona na wolnej licencji MIT, co zapewniło gwałtowny rozwój tego rozwiązania. A potem… potem zaczęła się polityka.

gnome

GNOME 1.0 w 1999 roku

W styczniu 1988 roku powołano MIT X Consortium jako grupę non-profit a przewodniczył jej Scheifler. W 1993 zerwano z powiązaniami z MIT i wykrystalizowało się X Consortium, Inc. Na początku roku 1997 projekt przeszedł pod skrzydła The Open Group (grupę zajmującą się rozwojem otwartych standardów, posiadająca prawo do nazwy UNIX). Jednak ich wydanie X116.4 miało być darmowe tylko do domowego użytku. Wobec buntu ekipy XFree86 (która była gotowa na sforkowanie projektu), The Open Group przywróciło X11 jako wolne oprogramowanie. Zaraz, XFree86? To wolna implementacja standardu X11 na potrzeby Linuksa, *BSD, Unixa i innych. Przez lata grała główne skrzypce jeżeli chodzi o rozwoju protokołu X11. W 1999 roku The Open Group stworzyło X.Org, która to organizacja miała zająć się rozwojem protokołu X i implementacji. Jednak to nadal XFree86 było głównym rozwiązaniem stosowanym na Linuksach. Dopiero powolony proces zmian w XFree86 (a wręcz blokowanie zgłaszanych poprawek) doprowadził w 2003 roku do kryzysu w wyniku którego większość programistów przeniosła się do X.Org – w tym Keith Packard. W tym samym czasie projekt XFree86 ponownie strzelił sobie w kolana, zmieniając licencję na niezgodną z GNU GPL (XFree86 License 1.1). To dopełniło czarę goryczy i większość dystrybucji rozpoczęło stopniowy proces wdrażania rozwiązań oferowanych przez X.org. Pierwsza wersja sygnowana przez X.Org Foundation, X11R6.7, została wydana 7 kwietnia 2004 roku. Aby ułatwić migrację została oparta na wersji XFree86 4.4 Release Candidate 2 – ostatniej, która nie zawierała jeszcze zmodyfikowanej licencji – oraz X11R6.6 autorstwa X.Org Group.

gnome

Typowy pulpit GNOME w 2019 roku

Niezła telenowela, nieprawdaż? Obecnie rozwój X.Org to wprowadzanie nowych możliwości (poprzez mechanizm rozszerzeń), dzielenie kodu na mniejsze moduły i próba dotrzymania kroku zmianom cywilizacyjnym.

Jednak nie da się ukryć faktu, że struktura i koncepcje X11 odstają już nieco od tego, czego oczekuje przeciętnych użytkownik. Zmianom uległ tutaj sposób zdalnego uruchamiania programów (VNC?), moc i znaczenie kart graficznych w komputerach domowych, rozwój graficznej strony interfejsu, jego złożoność a także aspekt estetyczny. Większość z nas pamięta szał jaki ogarnął wszystkich po prezentacji tego, co potrafi AIGLX, a potem Compiz. Nowe kompozytory na stałe wmontowały się w strukturę X.Orga.

Jednak po czasie zauważono problemy związane z taką protezą. Chociaż protokół X11 radził sobie w ramach rozszerzeń z takimi nowościami, to jednak obliczono, ile użytkownik jest stratny na przerzucaniu danych pomiędzy menedżerem okien i kompozytorem. Nie na darmo wszystkie współczesne środowiska graficzne posiadają opcję pomiń kompozytor w trybie pełnoekranowym. Chodzi o wydajność, a jak mówimy wydajność to myślimy gry.

I tak oto wracamy do pomysłu z 2008 roku i protokołu Wayland. Jego założenia są słuszne – połączyć w jedno serwer okien i kompozytor (oraz inne wynikające z tego uproszczenia i ulepszenia). W praktyce okazało się, że nie jest to takie oczywiste. Bez odpowiednich sterowników całość nie była już tak efektowna. A wielcy producenci pomysł przejścia na Waylanda potraktowali jak natrętną muchę. Po prostu nie uwzględnili go w sterownikach. Dopiero teraz czynione są odpowiednie kroki i w sterownikach NVIDII i AMD pojawiają się pewne rozwiązania. Jednak lista tego co nie działa wciąż dominuje.

I tak upłynęło 11 lat. Wayland doczekał się kompozytorów Weston czy obsługi w menedżerze okien Mutter czy KWin. Jednak projekt uwikłał się w próbę zachowania zgodności z X.Org by ułatwić migrację. Efektem jest cała masa problemów a mitycznego zysku na wydajności po prostu nie widać.

Wszystkiego najlepszego Waylandzie. Może kiedyś i dla ciebie zaświeci słońce. 

Post navigation

18 comments for “Wayland 11 lat później albo spóźnione życzenia

  1. Vallendalf Val
    11 października, 2019 at 10:52

    Proszę wykreślić AMD. Tylko Nvidia jest z tyłu – dokładnie 🙂
    Aż się boję co NVIDIA zrobi z Blenderem –

  2. 11 października, 2019 at 11:13

    Mam stare sterowniki radeon… Więc nawet nie próbuję. Ale zdaję sobie sprawę, że niektórzy używają i sobie chwalą. Sam bym też tak chciał.

    Amdgpu i Intel z racji swojego podejścia do struktury sterowników rzeczywiście szybciej reagują na zmiany. Ale czy jest idealnie…

  3. icywind
    11 października, 2019 at 10:14

    „Ano wystarczy szybki rzut oka na działający na naszym komputerze serwer
    , aby stwierdzić, że coś poszło nie tak.”
    Chyba twoim. U mnie działa Wayland
    „Dopiero teraz czynione są odpowiednie kroki i w sterownikach NVIDII i AMD pojawiają się pewne rozwiązania”
    Proszę wykreślić AMD. Tylko Nvidia jest z tyłu

  4. icywind
    11 października, 2019 at 12:36

    Mam RX 570, otwarte sterowniki i działa bez zarzutu. Tak samo Intel Skylake na laptopie.
    Jakiegoś wielkiego skoku odnośnie wydajności czy płynności nie odczuwam, ale nie pracuje też na ziemniaku.
    Jak ktoś się obraca w światku Ubuntu to można odnieść wrażenie, że Waylanda nie ma, ale wszyscy wielcy gracze używają go jako domyślnego (oczywiście jeśli wybierzesz Gnome jako twoje środowisko) Fedora, RedHat, Debian, OpenSuse.

    Lista tego co nie działa jest krótsza z każdym wydaniem.
    https://fedoraproject.org/wiki/Wayland_features

    Za największy problem wskazałbym to:
    https://wiki.gnome.org/Initiatives/Wayland/GnomeShell/GnomeShell4

  5. pavbaranov
    11 października, 2019 at 21:12

    Nie ma znaczenia, czy radeon, czy amdgpu. Problemem jest – jak zwykle – inne podejście NVidii.
    I powiem tak – Plasma nie wspierała ich pomysłów – KWin_Wayland działał wyśmienicie. Obecnie dołożyli coś do NVidii – Plasma na Waylandzie przestała działać. Cóż – powtórzę za pewnym Panem: Fuck you, NVidia.

  6. pavbaranov
    11 października, 2019 at 21:12

    Proste co zrobi – Blender będzie poprawnie działał tylko na GPU NVidii.

  7. 11 października, 2019 at 21:45

    404 na drugim linku.

  8. 11 października, 2019 at 21:46

    Wayland jako protokół powinien być uniwersalny. Niezależnie od platformy.Pytanie, która platforma go potrzebuje.

    Odpowiedź jest prosta. Każda. Bo każda forma optymalizacji ‚dane klienta < -> to co widzimy’ na ekranie jest pożądana. Problemem jest oczywiście wygodnictwo producentów sprzętu. Po co pisać sterowniki pod coś nowego, skoro stare jako tako działa. Nie widziałem co prawda porównania wydajności pod waylandem gier na amdgpu i nvidii – ale nie sądzę, żeby różnice były dramatyczne. Bo ciągle musimy babrać się w zgodności wstecznej i nikomu nie zależy na postępie.

    Ale plusem tych wszystkich rozważań jest mała ilość gier dla Linuksa (nawet pomimo inwazji Steama) i faktem, że przeciętny linuksowiec robi co innego na swoim komputerze 🙂

  9. 11 października, 2019 at 21:46

    Uważaj, bo jeszcze działacze wymuszą, żebyś ustąpił ze wszystkich piastowanych stanowisk 🙂

    Nie ma porozumienia na linii wizjonerzy – producenci. I nie będzie, bo zupełnie odmienne są cele obydwu grup.

  10. Artanis
    11 października, 2019 at 22:22

    Dzięki za dawkę historii w pigułce. Używam Linuksa od około 2004 roku i załapałem się na zastępowanie XFree (używałem go trochę na Debianie Sarge, dopiero Etch wrzucił X.org, o ile dobrze pamiętam), ale w sumie ominęła mnie jakoś historia i powód tej migracji.

  11. pavbaranov
    11 października, 2019 at 22:22

    Już ustąpiłem 🙂
    To nie jest jednak problem: wizjonerzy vs. producenci. Problemem i to dużym jest jeden z graczy, który idzie pod prąd. Zawsze. Od kiedy pamiętam. Może w istocie wyjściem z impasu jest certyfikowanie sprzętu na zasadzie „for linux without NVidia GPU”?

  12. pavbaranov
    11 października, 2019 at 21:22

    Z całym szacunkiem, ale w istocie… telenowela. Zadane przez Ciebie w ankiecie pytanie jest jednak mocno niedookreślone bowiem, czy Wayland zastąpi X11 zależy od tego na czym. Na desktopie? Tak, ale nie do końca. Podstawowe, główne DE na to przejdą. Reszta nadal będzie tkwić w Xach. Na serwerze – niekoniecznie. Ba, raczej nie. Niestety mocno miesza NVidia, która przyjęła swój sposób widzenia waylandowego świata, który psuje wszystko co popsuć można. Innymi słowy: chcesz używać linuksa – nie używaj GPU NVidii. Wyautowana z tego świata (a to również i to duże pieniądze) może zaczęłaby myśleć poważnie o standardach. Jeśli nie – to …. z tego świata.

  13. Asmita
    12 października, 2019 at 0:43

    „Bo ciągle musimy babrać się w zgodności wstecznej i nikomu nie zależy na postępie.”

    Niestety, sam postęp to trochę za mało. Można albo zapewniać wsteczną kompatybilność, albo wydać nowe wersje wszystkich programów, które muszą zostać zmodyfikowane w wyniku zmian. Trudno mi sobie wyobrazić, żeby ktokolwiek, kto nie używa GNU/Linuxa jako systemu serwerowego, pozostał przy nim w sytuacji, gdy całe oprogramowanie zależne od Xorg zostałoby wyrzucone do kosza.

  14. pavbaranov
    12 października, 2019 at 7:00

    Jeśli się nie mylę, to sytuacja taka nie grozi. Oprogramowanie, przynajmniej to, które obecnie jest dostępne i działa natywnie na Wayland, potrafi również działać pod Xami natywnie.
    Na serwerach natomiast pewnie długo jeszcze będzie królować X.org.

  15. icywind
    12 października, 2019 at 11:37
  16. pavbaranov
    12 października, 2019 at 12:26

    Wayland popełnił jeden zasadniczy błąd moim zdaniem. Stworzył swoje skróty, które być może dla kogoś, kto dopiero wejdzie (w przyszłości) w świat linuksa z Waylandem będą oczywiste. Dzisiaj, gdy pojawia się jakiś zonk (a pojawia się często) próba przejścia z Waylanda do TTY to coś, co przypomina wyjście z vi przez równie niedoświadczonego użytkownika. Dlaczego to wszystko musiało być inne? Już samo to, konieczność uczenia się na nowo czegoś, co się „ma w palcach” powoduje, że jeśli mam możliwość – wybieram Xy. Prościej.
    Druga kwestia to pewne przyzwyczajenia z Xów, które powodują, że najlepiej nawet działająca sesja jakiegoś DE w Waylandzie może być postrzegana jako ułomna. Mniej możliwości konfiguracji DE to początek góry lodowej (piszę o Plazmie).
    Trzecia. Problemem nie są nawet aplikacje. Te współczesne, na Qt5 czy Gtk3 działają w większości natywnie w sesji Waylanda. Niestety ślamazarzą się jeszcze projekty na Gtk2, z czego chyba najważniejszym jest GIMP. Zanim ten się pojawi na Gtk3 to pewnie już Gtk4 będzie 🙂 Niemniej jednak i one przez XWayland są w stanie być obsłużone w Waylandzie w miarę prawidłowo. Problem to nieliczna ilość kompozytorów, a jeszcze mniejsza funkcjonalnych i działających. Mamy Muttera, który powoduje, że GNOME3 tu działa, choć ma w niektórych miejscach problemy i – o ile wiem – stąd pomysł stworzenia Gtk4 i w ślad za tym GNOME4. Jest KWin, ale ten też ma swoje problemy z Waylandem. Jest Sway będący „wersją” i3 dla Waylanda i… ? No właśnie w zasadzie tyle. Drobne, porzucane pomysły, które działają lub nie. Średnia perspektywa jeśli chodzi o sesje Waylanda w MATE, Cinnamon, Xfce i innych. Ślamarnie rozwiajające się Liri, które albo się pokocha, albo wcale. I Weston, który jedyny chyba działa w 100% prawidłowo, ale z uwagi na swój charakter, trudno w nim poszukiwać rozwiązań na miarę współczesnego DE. Można powiedzieć i tak nieźle, bo jakiś wybór jest (GNOME, Plasma), ale jak to wytłumaczyć komuś, kto ma ochotę używać np. Xfce, czy Cinnamona?
    Ogólnie? Cokolwiek na Wayland jest na dłuższą metę po prostu nieużywalne w porównaniu do tego samego na X11.

  17. Dariusz Knocinski
    22 października, 2019 at 15:51

    Używam X11 od 1993 roku i jestem z tego rozwiązania na tyle zadowolony, że nadal pierwsze co robię w nowej Fedorze to blokuję używanie Waylanda 😉

  18. ratus
    24 października, 2019 at 19:04

    Jesli Wayland zdominuje desktop, tym samym ubite zostaną zarządcy okien, takie jak i3, IceWm, Fluxbox – czyli „folklor”, który sprawia, że Linux nie jest „innym Windowsem”. Będzie nudno. Szkoda. Ale ucieszą sie ci, co lubia monopole i marzy im się „jedynie słuszny” system.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Translate »