Wayland (protokół serwera wyświetlania) - Wayland (display server protocol)

Wayland
Wayland Logo.svg
Wayland-weston 8.0.0-2-2020-08-04.png
Pierwotny autor (autorzy) Kristian Høgsberg
Deweloper(zy) freedesktop.org i in.
Pierwsze wydanie 30 września 2008 ; 13 lat temu ( 2008-09-30 )
Wersja stabilna
Wayland: 1.19, Weston: 8.0 / 27 stycznia 2021 ; 8 miesięcy temu ( 27.01.2021 )
Magazyn
Napisane w C
System operacyjny oficjalne: Linux
nieoficjalne: NetBSD , FreeBSD , DragonFly BSD
Rodzaj
Licencja Licencja MIT
Strona internetowa wayland .freedesktop .org

Wayland to protokół komunikacyjny, który określa komunikację między serwerem wyświetlania a jego klientami, a także implementację tego protokołu w bibliotece C. Serwer wyświetlania korzystający z protokołu Wayland nazywany jest kompozytorem Wayland , ponieważ dodatkowo wykonuje zadania menedżera okien komponowania .

Wayland jest rozwijany przez grupę wolontariuszy początkowo kierowanych przez Kristiana Høgsberga jako darmowy i otwarty przez społeczność projekt mający na celu zastąpienie X Window System nowoczesnym, bezpiecznym, prostszym systemem okienkowym w Linuksie i innych systemach operacyjnych podobnych do Uniksa . Kod źródłowy projektu jest publikowany na warunkach licencji MIT , permisywnej licencji wolnego oprogramowania .

W ramach swoich wysiłków projekt Wayland opracowuje również referencyjną implementację kompozytora Wayland o nazwie Weston .

Przegląd

  1. Evdev moduł jądra Linuksa dostaje zdarzenie i wysyła go do kompozytor Wayland .
  2. Kompozytor Wayland przegląda grafikę, aby określić, w którym oknie powinno zostać odebrane zdarzenie. Scenegraph odpowiada temu, co jest na ekranie, a kompozytor Wayland rozumie transformacje, które mógł zastosować do elementów w scenegraph. W ten sposób kompozytor Wayland może wybrać właściwe okno i przekształcić współrzędne ekranu na lokalne współrzędne okna, stosując transformacje odwrotne. Typy transformacji, które można zastosować do okna, są ograniczone tylko do tego, co może zrobić kompozytor, o ile może obliczyć transformację odwrotną dla zdarzeń wejściowych.
  3. Podobnie jak w przypadku X, gdy klient otrzyma zdarzenie, w odpowiedzi aktualizuje interfejs użytkownika. Ale w przypadku Waylanda renderowanie odbywa się przez klienta za pośrednictwem EGL , a klient po prostu wysyła żądanie do kompozytora, aby wskazać region, który został zaktualizowany.
  4. Kompozytor Wayland zbiera żądania szkód od swoich klientów, a następnie ponownie komponuje ekran. Kompozytor może wtedy bezpośrednio wydać ioctl, aby zaplanować przerzucanie strony za pomocą KMS .

Projekt Wayland Display Server został zapoczątkowany przez programistę Red Hat Kristiana Høgsberga w 2008 roku.

Począwszy od około 2010 r., grafika desktopowa Linuksa przeszła ze „stosu interfejsów renderujących … wszystkie komunikują się z serwerem X , który jest w centrum wszechświata” w kierunku umieszczenia jądra Linuksa i jego komponentów (tj. infrastruktury bezpośredniego renderowania ( DRI) , Direct Rendering Manager (DRM) ) „w środku”, z „systemami okiennymi, takimi jak X i Wayland… w rogu”. Będzie to „znacznie uproszczony system graficzny oferujący większą elastyczność i lepszą wydajność”.

Høgsberg mógł dodać rozszerzenie do X, tak jak zrobiło to wiele ostatnich projektów, ale wolał „[wypychać] X z gorącej ścieżki między klientami a sprzętem” z powodów wyjaśnionych w FAQ projektu:

Tym, co się teraz zmieniło, jest to, że wiele elementów infrastruktury zostało przeniesionych z serwera X do jądra (zarządzanie pamięcią, planowanie poleceń, ustawianie trybu ) lub bibliotek ( cairo , pixman, freetype , fontconfig , pango itp.), a jest ich bardzo mało pozostało to musi się zdarzyć w procesie centralnego serwera. ... [Serwer X ma] ogromną ilość funkcji, które musisz obsługiwać, aby twierdzić, że mówi protokół X, ale nikt nigdy tego nie użyje. ... Obejmuje to tabele kodów, rasteryzację i buforowanie glifów, pliki XLFD (poważnie, XLFD!) i cały interfejs API renderowania rdzenia, który pozwala rysować linie kropkowane, wielokąty, szerokie łuki i wiele innych grafik w stylu lat 80. prymitywne. W wielu przypadkach udało nam się utrzymać nowoczesny serwer X.org, dodając rozszerzenia, takie jak XRandR , XRender i COMPOSITE ... Dzięki Wayland możemy przenieść serwer X i całą jego starszą technologię na opcjonalną ścieżkę kodu. Dojście do punktu, w którym serwer X jest opcją kompatybilności zamiast podstawowego systemu renderowania, zajmie trochę czasu, ale nigdy nie dojdziemy do tego, jeśli [nie] tego nie planujemy.

Wayland składa się z protokołu i implementacji referencyjnej o nazwie Weston . Projekt rozwija również wersje GTK i Qt, które renderują się w Wayland zamiast w X. Oczekuje się, że większość aplikacji uzyska wsparcie dla Waylanda poprzez jedną z tych bibliotek bez modyfikacji aplikacji.

Pierwsze wersje Waylanda nie zapewniały przejrzystości sieci , chociaż Høgsberg zauważył w 2010 roku, że przejrzystość sieci jest możliwa. Podjęto próbę jako projekt Google Summer of Code w 2011 roku, ale nie powiodła się. Adam Jackson przewidział zapewnienie zdalnego dostępu do aplikacji Wayland poprzez „zdrapywanie pikseli” (jak VNC ) lub wysyłanie jej „strumienia poleceń renderowania” przez sieć (jak w RDP , SPICE lub X11 ). Od początku 2013 roku Høgsberg eksperymentuje z przezroczystością sieci, używając serwera proxy Wayland, który wysyła skompresowane obrazy do prawdziwego kompozytora. W sierpniu 2017 r. GNOME zobaczyło pierwszą taką implementację serwera VNC do usuwania pikseli pod Waylandem.

Architektura oprogramowania

Architektura protokołu

W architekturze protokołu Wayland klient i kompozytor komunikują się za pośrednictwem protokołu Wayland przy użyciu referencyjnych bibliotek implementacji.

Protokół Wayland opiera się na modelu klient-serwer, w którym klienci to aplikacje graficzne żądające wyświetlania buforów pikseli na ekranie, a serwer (kompozytor) jest usługodawcą kontrolującym wyświetlanie tych buforów.

Implementacja referencyjna Wayland została zaprojektowana jako protokół dwuwarstwowy:

  • Protokół warstwowy lub przewodowy niskiego poziomu , który obsługuje komunikację między procesami między dwoma zaangażowanymi procesami — „klient i kompozytor” — oraz porządkowanie danych, które wymieniają. Warstwa ta jest oparta na wiadomościach i zwykle implementowana przy użyciu usług IPC jądra, w szczególności gniazd domeny uniksowej w przypadku systemów operacyjnych Linux i uniksopodobnych .
  • Zbudowana na nim warstwa wysokiego poziomu, która obsługuje informacje, które klient i kompozytor muszą wymieniać, aby zaimplementować podstawowe funkcje systemu okiennego . Ta warstwa jest zaimplementowana jako „asynchroniczny protokół zorientowany obiektowo”.

Podczas gdy warstwa niskopoziomowa została napisana ręcznie w języku C , warstwa wysokopoziomowa jest automatycznie generowana na podstawie opisu elementów protokołu zapisanego w formacie XML . Za każdym razem, gdy zmienia się opis protokołu tego pliku XML, kod źródłowy C, który implementuje taki protokół, może zostać zregenerowany w celu uwzględnienia nowych zmian, co pozwala na bardzo elastyczny, rozszerzalny i odporny na błędy protokół.

Implementacja referencyjna protokołu Wayland jest podzielona na dwie biblioteki : bibliotekę używaną przez klientów Waylanda libwayland-clientoraz bibliotekę używaną przez kompozytorów Waylanda libwayland-server.

Przegląd protokołów

Protokół Waylanda jest określany jako „asynchroniczny protokół zorientowany obiektowo ”. Obiektowe oznacza, że ​​usługi oferowane przez kompozytora są przedstawiane jako seria obiektów żyjących na tym samym kompozytorze. Każdy obiekt implementuje interfejs, który ma nazwę, szereg metod (zwanych żądaniami ) oraz kilka powiązanych zdarzeń . Każde żądanie i zdarzenie ma zero lub więcej argumentów, każdy z nazwą i typem danych . Protokół jest asynchroniczny w tym sensie, że żądania nie muszą czekać na zsynchronizowane odpowiedzi lub ACK , co pozwala uniknąć opóźnień w obie strony i osiągnąć lepszą wydajność.

Klienci Wayland mogą wykonać żądanie (wywołanie metody) na jakimś obiekcie, jeśli interfejs obiektu obsługuje to żądanie. Klient musi również podać wymagane dane do uzasadnienia takiego żądania. W ten sposób klienci żądają usług od kompozytora. Kompozytor z kolei wysyła informacje z powrotem do klienta, powodując, że obiekt emituje zdarzenia (prawdopodobnie również z argumentami). Zdarzenia te mogą być emitowane przez kompozytora jako odpowiedź na określone żądanie lub asynchronicznie, w zależności od wystąpienia zdarzeń wewnętrznych (takich jak z urządzenia wejściowego) lub zmian stanu. Warunki błędu są również sygnalizowane przez kompozytora jako zdarzenia.

Aby klient mógł wysłać żądanie do obiektu, najpierw musi podać serwerowi numer identyfikacyjny, którego użyje do zidentyfikowania tego obiektu. W kompozytorze istnieją dwa typy obiektów: obiekty globalne i obiekty nieglobalne. Obiekty globalne są ogłaszane przez kompozytora klientom podczas ich tworzenia (a także gdy są niszczone), podczas gdy obiekty nieglobalne są zwykle tworzone przez inne obiekty, które już istnieją w ramach ich funkcjonalności.

Interfejsy oraz ich żądania i zdarzenia są podstawowymi elementami, które definiują protokół Wayland. Każda wersja protokołu zawiera zestaw interfejsów wraz z ich żądaniami i zdarzeniami, które powinny znajdować się w dowolnym kompozytorze Wayland. Opcjonalnie kompozytor Wayland może zdefiniować i zaimplementować własne interfejsy, które obsługują nowe żądania i zdarzenia, rozszerzając w ten sposób funkcjonalność poza podstawowy protokół. Aby ułatwić wprowadzanie zmian w protokole, każdy interfejs zawiera oprócz nazwy atrybut „numer wersji”; ten atrybut pozwala na rozróżnienie wariantów tego samego interfejsu. Każdy kompozytor Wayland ujawnia nie tylko dostępne interfejsy, ale także obsługiwane wersje tych interfejsów.

Główne interfejsy Wayland

Interfejsy aktualnej wersji protokołu Wayland są zdefiniowane w pliku protocol/wayland.xml kodu źródłowego Wayland. Jest to plik XML , który zawiera listę istniejących interfejsów w aktualnej wersji, wraz z ich żądaniami, zdarzeniami i innymi atrybutami. Ten zestaw interfejsów to minimum wymagane do zaimplementowania przez dowolnego kompozytora Wayland.

Niektóre z najbardziej podstawowych interfejsów protokołu Wayland to:

  • wl_display  – główny obiekt globalny, specjalny obiekt do enkapsulacji samego protokołu Wayland
  • wl_registry  – globalny obiekt register, w którym kompozytor rejestruje wszystkie globalne obiekty, które chce być dostępne dla wszystkich klientów
  • wl_compositor  – obiekt, który reprezentuje kompozytora i odpowiada za łączenie różnych powierzchni w jedno wyjście
  • wl_surface  – obiekt reprezentujący prostokątny obszar na ekranie, zdefiniowany przez położenie, rozmiar i zawartość piksela
  • wl_buffer  – obiekt, który po dołączeniu do obiektu wl_surface udostępnia swoją wyświetlaną zawartość
  • wl_output  – obiekt reprezentujący wyświetlany obszar ekranu
  • wl_pointer , wl_keyboard , wl_touch  – obiekty reprezentujące różne urządzenia wejściowe, takie jak wskaźniki czy klawiatury
  • wl_seat  – obiekt reprezentujący stanowisko (zestaw urządzeń wejścia/wyjścia) w konfiguracjach wielostanowiskowych

Typowa sesja klienta Wayland rozpoczyna się od otwarcia połączenia z kompozytorem za pomocą obiektu wl_display . Jest to specjalny obiekt lokalny, który reprezentuje połączenie i nie znajduje się na serwerze. Używając swojego interfejsu klient może zażądać globalnego obiektu wl_registry od kompozytora, gdzie znajdują się wszystkie globalne nazwy obiektów, i powiązać te, którymi klient jest zainteresowany. Zwykle klient wiąże przynajmniej obiekt wl_compositor, z którego będzie żądał jednego lub więcej obiektów wl_surface, aby pokazać wyjście aplikacji na wyświetlaczu.

Interfejsy rozszerzeń Wayland

Kompozytor Wayland może definiować i eksportować własne dodatkowe interfejsy. Ta funkcja służy do rozszerzenia protokołu poza podstawową funkcjonalność zapewnianą przez podstawowe interfejsy i stała się standardowym sposobem implementacji rozszerzeń protokołu Wayland. Niektórzy kompozytorzy mogą zdecydować się na dodanie niestandardowych interfejsów, aby zapewnić wyspecjalizowane lub unikalne funkcje. Kompozytor referencji Waylanda, Weston, wykorzystał je do zaimplementowania nowych eksperymentalnych interfejsów jako podłoża testowego dla nowych koncepcji i pomysłów, z których niektóre później stały się częścią podstawowego protokołu (takie jak interfejs wl_subsurface dodany w Wayland 1.4).

Protokoły rozszerzające do protokołu podstawowego

Protokół XDG-Shell

Protokół XDG-Shell (zobacz freedesktop.org dla XDG) to rozszerzony sposób zarządzania powierzchniami w ramach kompozytorów Wayland (nie tylko Weston). Tradycyjnym sposobem manipulowania (maksymalizacji, minimalizowania, pełnoekranowego itp.) powierzchni jest użycie funkcji wl_shell_*() , które są częścią podstawowego protokołu Wayland i działają w libwayland-client . Wręcz przeciwnie, implementację protokołu xdg-shell ma zapewnić kompozytor Wayland. Tak więc znajdziesz nagłówek xdg-shell-client-protocol.h w drzewie źródłowym Westona. Każdy kompozytor Wayland ma zapewnić własną implementację.

Od czerwca 2014 r. protokół XDG-Shell nie był wersjonowany i nadal jest podatny na zmiany.

xdg_shell jest protokołem mającym na dłuższą metę zastąpić wl_shell, ale nie będzie częścią podstawowego protokołu Waylanda. Rozpoczyna się jako niestabilny interfejs API, który początkowo ma być używany jako miejsce rozwoju, a gdy funkcje zostaną zdefiniowane zgodnie z wymaganiami kilku powłok pulpitu, można go wreszcie uczynić stabilnym. Dostarcza głównie dwa nowe interfejsy: xdg_surface i xdg_popup. Interfejs xdg_surface implementuje okno w stylu pulpitu, które można przenosić, zmieniać rozmiar, maksymalizować itp.; zawiera żądanie utworzenia relacji dziecko/rodzic. Interfejs xdg_popup implementuje wyskakujące okienko/menu w stylu pulpitu; xdg_popup jest zawsze przejściowy dla innej powierzchni, a także ma niejawny chwyt.

Protokół IVI-Shell

IVI-Shell to rozszerzenie podstawowego protokołu Wayland, przeznaczone dla urządzeń informacyjno-rozrywkowych w pojazdach (IVI).

Model renderowania

Kompozytor Wayland i jego klienci używają EGL do rysowania bezpośrednio do bufora ramki ; Serwer X.Org z XWayland i Glamour .

Protokół Wayland nie obejmuje renderowania API. Zamiast tego Wayland stosuje model bezpośredniego renderowania , w którym klient musi renderować zawartość okna do bufora, który można udostępnić kompozytorowi. W tym celu klient może wybrać wykonanie całego renderowania samodzielnie, użyć biblioteki renderującej, takiej jak Cairo lub OpenGL , lub polegać na silniku renderującym bibliotek widżetów wysokiego poziomu z obsługą Wayland, takich jak Qt lub GTK . Klient może również opcjonalnie użyć innych specjalistycznych bibliotek do wykonywania określonych zadań, takich jak Freetype do renderowania czcionek .

Wynikowy bufor z wyrenderowaną zawartością okna jest przechowywany w obiekcie wl_buffer . Wewnętrzny typ tego obiektu jest zależny od implementacji. Jedynym wymaganiem jest to, że dane treści muszą być udostępniane między klientem a kompozytorem. Jeśli klient korzysta z renderera programowego (CPU), a wynik jest przechowywany w pamięci systemowej , wówczas klient i kompozytor mogą używać pamięci współdzielonej do implementacji komunikacji buforowej bez dodatkowych kopii. Protokół Wayland już natywnie dostarcza tego rodzaju bufor pamięci współdzielonej przez interfejsy wl_shm i wl_shm_pool . Wadą tej metody jest to, że kompozytor może potrzebować dodatkowej pracy (zwykle w celu skopiowania udostępnionych danych na GPU), aby je wyświetlić, co prowadzi do wolniejszej wydajności grafiki.

Najbardziej typowym przypadkiem jest to, że klient renderuje bezpośrednio do bufora pamięci wideo przy użyciu akcelerowanego sprzętowo (GPU) interfejsu API, takiego jak OpenGL , OpenGL ES lub Vulkan . Klient i kompozytor mogą współdzielić ten bufor przestrzeni GPU za pomocą specjalnego programu obsługi, aby się do niego odwoływać. Ta metoda pozwala kompozytorowi uniknąć dodatkowego kopiowania danych przez siebie z bufora pamięci głównej metoda klient-kompozytor-GPU, co skutkuje szybszą wydajnością grafiki i dlatego jest preferowana. Kompozytor może dodatkowo zoptymalizować kompozycję końcowej sceny, która ma być pokazana na ekranie, używając tego samego interfejsu API przyspieszania sprzętowego, co klient API.

Po zakończeniu renderowania we współdzielonym buforze klient Wayland powinien poinstruować kompozytora, aby zaprezentował wyrenderowaną zawartość bufora na ekranie. W tym celu klient wiąże obiekt bufora, który przechowuje wyrenderowaną zawartość z obiektem powierzchni i wysyła żądanie „zatwierdź” do powierzchni, przenosząc efektywną kontrolę nad buforem do kompozytora. Następnie klient czeka, aż kompozytor zwolni bufor (sygnalizowany przez zdarzenie), jeśli chce ponownie użyć bufora do renderowania innej klatki lub może użyć innego bufora do renderowania nowej klatki, a po zakończeniu renderowania powiązać ten nowy bufor na powierzchnię i zatwierdź jego zawartość. Procedura używana do renderowania, w tym liczba zaangażowanych buforów i zarządzanie nimi, jest całkowicie pod kontrolą klienta.

Porównanie z innymi systemami okiennymi

Różnice między Waylandem a X

Istnieje kilka różnic między Waylandem i X w odniesieniu do wydajności, łatwości konserwacji kodu i bezpieczeństwa:

Architektura
Kierownik kompozycja jest odrębną, dodatkową cechą X, natomiast łączy serwera Wayland wyświetlacza i kompozytor w jednej funkcji. Zawiera również niektóre zadania menedżera okien , który w X jest oddzielnym procesem po stronie klienta.
Komponowanie
Kompozycja jest opcjonalna w X, ale obowiązkowa w Wayland. Komponowanie w X jest „aktywne”; oznacza to, że kompozytor musi pobrać wszystkie dane pikseli, co wprowadza opóźnienie. W Wayland komponowanie jest „pasywne”, co oznacza, że ​​kompozytor otrzymuje dane pikseli bezpośrednio od klientów.
Wykonanie
Sam serwer X jest w stanie wykonać renderowanie, chociaż może być również poinstruowany, aby wyświetlić renderowane okno wysłane przez klienta. W przeciwieństwie do tego Wayland nie udostępnia żadnego interfejsu API do renderowania, ale przekazuje klientom takie zadania (w tym renderowanie czcionek, widżetów itp.). Dekoracje okien mogą być renderowane po stronie klienta (np. przez zestaw narzędzi graficznych) lub po stronie serwera (przez kompozytora).
Bezpieczeństwo
Wayland izoluje dane wejściowe i wyjściowe każdego okna, osiągając w obu przypadkach poufność, integralność i dostępność; oryginalny projekt X nie ma tych ważnych funkcji bezpieczeństwa, chociaż niektóre rozszerzenia zostały opracowane, aby to złagodzić. Ponadto, ponieważ zdecydowana większość kodu działa w kliencie, mniej kodu musi być uruchamiane z uprawnieniami roota , co poprawia bezpieczeństwo, chociaż wiele popularnych dystrybucji Linuksa pozwala teraz na uruchamianie X bez uprawnień roota.
Komunikacja między procesami
Serwer X zapewnia podstawową metodę komunikacji między klientami X, później rozszerzoną o konwencje ICCCM . Ta komunikacja klient-klient X jest używana przez menedżery okien, a także do implementowania sesji X , selekcji, przeciągania i upuszczania oraz innych funkcji. Protokół rdzeń Wayland nie obsługuje komunikację między klientami Wayland w ogóle, a odpowiadającą funkcjonalność (w razie potrzeby) powinny być realizowane przez środowisk graficznych (takich jak KDE lub GNOME), lub przez osobę trzecią (na przykład za pomocą natywnego IPC z podstawowy system operacyjny).
Sieć
X Window System to architektura zaprojektowana w swej istocie do pracy w sieci. Wayland sam w sobie nie zapewnia przejrzystości sieci; jednak kompozytor może zaimplementować dowolny protokół zdalnego pulpitu w celu uzyskania zdalnego wyświetlania. Ponadto prowadzone są badania nad strumieniowaniem i kompresją obrazu Wayland, które zapewniłyby zdalny dostęp do bufora ramek podobny do tego, jaki zapewnia VNC .

Kompatybilność z X

XWayland to serwer X działający jako klient Wayland, dzięki czemu może wyświetlać natywne aplikacje klienckie X11 w środowisku kompozytora Wayland. Jest to podobne do sposobu, w jaki XQuartz uruchamia aplikacje X w natywnym systemie okien macOS . Celem XWayland jest ułatwienie przejścia ze środowisk X Window System do Wayland, zapewniając w międzyczasie możliwość uruchamiania nieportowanych aplikacji. XWayland został włączony do X.Org Server w wersji 1.16.

Widget toolkity, takie jak Qt 5 i GTK 3, mogą przełączać swoje graficzne zaplecze w czasie wykonywania, pozwalając użytkownikom wybrać w czasie ładowania, czy chcą uruchomić aplikację przez X, czy przez Wayland. Qt 5 zapewnia -platformopcję wiersza poleceń do tego efektu, podczas gdy GTK 3 pozwala użytkownikom wybrać żądany back-end GDK poprzez ustawienie GDK_BACKEND zmiennej środowiskowej Unix .

Kompozytorzy Wayland

Typowe elementy okna . Ani Wayland, ani X11 nie określają, jakie oprogramowanie jest odpowiedzialne za renderowanie dekoracji okien . Weston wymaga, aby były one rysowane przez klienta, ale KWin zaimplementuje dekorację po stronie serwera.

Serwery wyświetlania, które implementują protokół serwera wyświetlania Wayland, są również nazywane kompozytorami Wayland, ponieważ dodatkowo wykonują zadania menedżera okien komponowania .

  • Weston  – referencyjna implementacja kompozytora Wayland; Weston wdraża dekoracje po stronie klienta
  • Lipstick – mobilny framework powłoki graficznej , który implementuje kompozytor Wayland; jest używany w Sailfish OS , Nemo Mobile i AsteroidOS
  • Enlightenment zażądał pełnego wsparcia Waylanda od wersji 0.20, ale obecnie trwają prace nad stworzeniem kompletnego kompozytora Waylanda
  • KWin ma prawie pełne wsparcie Wayland od 2021 r.
  • Mutter utrzymuje osobną gałąź do integracji Wayland dla GNOME 3.9 (we wrześniu 2013)
  • Clayland – prosty przykład kompozytora Waylanda używającego Clutter
  • Westeros – biblioteka kompozytorów Wayland, która umożliwia aplikacjom tworzenie własnych wyświetlaczy Wayland, co umożliwia zagnieżdżanie i osadzanie aplikacji innych firm
  • wlroots – modułowa implementacja Waylanda, która działa jako baza dla innych kompozytorów, w szczególności Sway
  • Sway – kafelkowy kompozytor Wayland i zamiennik drop-in dla menedżera okien i3 dla X11
  • gamescope – część SteamOS, zastępująca wcześniejszy steamcompmgr

Weston

Weston jest referencyjną implementacją kompozytora Wayland, również opracowanego w ramach projektu Wayland. Jest napisany w C i opublikowany na licencji MIT . Weston ma oficjalne wsparcie tylko dla systemu operacyjnego Linux ze względu na zależność firmy Weston od pewnych funkcji jądra Linux , takich jak ustawianie trybu jądra , Graphics Execution Manager (GEM) i udev , które nie zostały zaimplementowane w innych systemach uniksopodobnych systemy. W systemie Linux obsługa sprzętu wejściowego opiera się na evdev , podczas gdy obsługa buforów opiera się na Generic Buffer Management (GBM). Jednak w 2013 roku ogłoszono prototypowy port Weston do FreeBSD .

Weston obsługuje szerokopasmową ochronę treści cyfrowych (HDCP).

Weston polega na GEM, aby współdzielić bufory aplikacji między kompozytorem a aplikacjami. Zawiera system wtyczek "powłok" dla typowych funkcji pulpitu, takich jak stacje dokujące i panele. Klient jest odpowiedzialny za rysunek swoich obramowań okiennych i ich dekoracji. Do renderowania Weston może użyć OpenGL ES lub biblioteki pixman do renderowania oprogramowania . Pełna implementacja OpenGL nie jest używana, ponieważ w większości obecnych systemów zainstalowanie pełnych bibliotek OpenGL spowodowałoby również zainstalowanie GLX i innych bibliotek obsługi X Window System jako zależności.

Interfejs zdalnego dostępu dla Weston został zaproponowany w październiku 2013 r. przez pracownika RealVNC .

Maynard

Maynard (w styczniu 2017)

Maynard jest powłoką graficzną i został napisany jako wtyczka do Westona, podobnie jak powłoka GNOME została napisana jako wtyczka do Mutter .

Fundacja Raspberry Pi we współpracy z Collabora wydała Maynarda i pracuje nad poprawą wydajności i zużycia pamięci.

libinput

libinput został stworzony, aby skonsolidować stos wejściowy w wielu kompozytorach Wayland.

Kod Westona do obsługi urządzeń wejściowych (klawiatury, wskaźniki, ekrany dotykowe itp.) został podzielony na własną osobną bibliotekę o nazwie libinput , której obsługa została po raz pierwszy połączona w Weston 1.5.

Libinput obsługuje urządzenia wejściowe dla wielu kompozytorów Wayland, a także zapewnia ogólny sterownik wejściowy X.Org Server . Jego celem jest zapewnienie jednej implementacji dla wielu kompozytorów Wayland ze wspólnym sposobem obsługi zdarzeń wejściowych przy jednoczesnym zminimalizowaniu liczby niestandardowych kompozytorów kodu wejściowego, które muszą zawierać. libinput zapewnia wykrywanie urządzeń (poprzez udev ), obsługę urządzeń, przetwarzanie zdarzeń urządzeń wejściowych i abstrakcję.

Wersja 1.0 libinput była następstwem wersji 0.21 i zawierała obsługę tabletów, zestawów przycisków i gestów touchpada. Ta wersja utrzyma stabilne API/ABI.

Ponieważ GNOME/GTK i Frameworki KDE 5 wprowadziły wymagane zmiany, Fedora 22 zastąpi sterowniki evdev i Synaptics X.Org libinput.

W wersji 1.16 serwer X.Org uzyskał wsparcie dla biblioteki libinput w postaci wrappera o nazwie xf86-input-libinput .

Moduł bezpieczeństwa Wayland

Wayland Security Module to propozycja, która przypomina interfejs Linux Security Module , który można znaleźć w jądrze Linuksa .

Niektóre aplikacje (zwłaszcza te związane z dostępnością ) wymagają uprzywilejowanych możliwości, które powinny działać z różnymi kompozytorami Wayland. Obecnie aplikacje pod Wayland generalnie nie są w stanie wykonywać żadnych wrażliwych zadań, takich jak robienie zrzutów ekranu lub wstrzykiwanie zdarzeń wejściowych. Deweloperzy Wayland aktywnie poszukują wykonalnych sposobów bezpiecznej obsługi uprzywilejowanych klientów, a następnie projektowania dla nich uprzywilejowanych interfejsów.

Wayland Security Module to sposób na delegowanie decyzji dotyczących bezpieczeństwa w ramach kompozytora do scentralizowanego silnika decyzyjnego dotyczącego bezpieczeństwa.

Przyjęcie

Protokół Wayland został zaprojektowany tak, aby był prosty, więc dodatkowe protokoły i interfejsy muszą być zdefiniowane i zaimplementowane w celu uzyskania całościowego systemu okienkowego. Od lipca 2014 roku trwają prace nad tymi dodatkowymi interfejsami. Tak więc, podczas gdy zestawy narzędzi już w pełni obsługują Wayland, twórcy powłok graficznych współpracują z programistami Wayland, tworząc niezbędne dodatkowe interfejsy.

Dystrybucje Linuksa na komputery stacjonarne

Od 2020 roku większość dystrybucji Linuksa obsługuje Waylanda po wyjęciu z pudełka, niektóre godne uwagi przykłady to:

  • Fedora począwszy od wersji 25 (wydanej 22 listopada 2016) używa Waylanda dla domyślnej sesji pulpitu GNOME 3.22, z X.Org jako rezerwą, jeśli sterownik graficzny nie obsługuje Waylanda. Fedora używa Waylanda jako domyślnego dla sesji pulpitu KDE od wersji 34 (wydanej 27 kwietnia 2021)
  • Ubuntu dostarcza Waylanda domyślnie w Ubuntu 17.10 (Artful Aardvark). Ubuntu powrócił do X.Org dla Ubuntu 18.04 LTS, ponieważ Wayland nadal ma problemy z udostępnianiem ekranu i aplikacjami zdalnego pulpitu i nie odzyskuje się również po awariach menedżera okien. Ubuntu domyślnie dostarcza Waylanda w 21.04.
  • Red Hat Enterprise Linux dostarcza Wayland jako domyślną sesję w wersji 8, wydanej 7 maja 2019 r.
  • Debian dostarcza Waylanda jako domyślną sesję dla GNOME od wersji 10, wydanej 6 lipca 2019 r.
  • Slackware Linux zawierał Waylanda 20 lutego 2020 r. w wersji rozwojowej, -current, która ostatecznie stanie się wersją 15.0.
  • Manjaro domyślnie dostarcza Waylanda w edycji Gnome Manjaro 20.2 (Nibia) (wydanej 22 listopada 2020 r.).

Znani wcześnie adoptujący:

  • RebeccaBlackOS to dystrybucja Linuksa oparta na debianie na żywo USB, która pozwala w wygodny sposób wypróbować prawdziwy pulpit Waylanda bez konieczności wprowadzania jakichkolwiek modyfikacji w głównym systemie operacyjnym komputera. Jest używany od 2012 roku do prezentacji Waylanda.

Obsługa zestawu narzędzi

Zestawy narzędzi wspierające Waylanda obejmują:

  • Clutter ma pełne wsparcie Wayland.
  • EFL ma pełną obsługę Wayland, z wyjątkiem selekcji.
  • GTK 3.20 ma pełną obsługę Waylanda.
  • Qt 5 ma pełną obsługę Wayland i może być używany do pisania zarówno kompozytorów Wayland, jak i klientów Wayland.
  • Obsługa SDL dla Waylanda zadebiutowała w wydaniu 2.0.2 i była domyślnie włączona od wersji 2.0.4.
  • GLFW 3.2 obsługuje Waylanda.
  • FreeGLUT ma początkową obsługę Waylanda.

Środowiska komputerowe

Środowiska graficzne w trakcie przenoszenia z X do Wayland obejmują GNOME , KDE Plasma 5 i Enlightenment .

W listopadzie 2015 roku ogłoszono Enlightenment e20 z pełnym wsparciem Waylanda. GNOME 3.20 było pierwszą wersją, która miała pełną sesję Waylanda. GNOME 3.22 zawiera znacznie ulepszoną obsługę Wayland w GTK, Mutter i GNOME Shell. GNOME 3.24 dostarczało wsparcie dla własnościowych sterowników NVidia pod Waylandem.

Wsparcie Waylanda dla KDE Plasma zostało opóźnione do czasu wydania Plasmy 5, chociaż wcześniej KWin 4.11 otrzymał eksperymentalną obsługę Waylanda. Wersja 5.4 Plasmy była pierwszą z sesją Waylanda. W 2020 roku Klipper został przeniesiony do Wayland, a kolejne wydanie 5.20 w październiku 2020 roku ma na celu poprawę przesyłania i nagrywania ekranu.

Inne oprogramowanie

Inne oprogramowanie obsługujące Waylanda obejmuje:

  • Inteligentna magistrala wejściowa pracuje nad obsługą Waylanda, może być gotowa na Fedorę 22.
  • RealVNC opublikował podgląd programisty Wayland w lipcu 2014 r.
  • Maliit to framework metody wprowadzania , który działa pod Waylandem.
  • kmscon obsługuje Waylanda z wlterm.
  • Mesa ma zintegrowane wsparcie Wayland.
  • Eclipse został złożony do uruchomienia na Wayland podczas GSoC -Project w 2014 roku.
  • Vulkan WSI (Okno System Interface) to zestaw API służą podobnemu celowi jak EGL robi dla OpenGL ES lub GLX dla OpenGL. Vulkan WSI zawiera wsparcie dla Waylanda od pierwszego dnia: VK_USE_PLATFORM_WAYLAND_KHR. Klienci Vulkan mogą działać na niezmodyfikowanych serwerach Wayland, w tym Weston, GENIVI LayerManager, Mutter / GNOME Shell, Enlightenment i innych. WSI umożliwia aplikacjom wykrywanie różnych procesorów graficznych w systemie i wyświetlanie wyników renderowania GPU w systemie okienkowym.
  • SPURV , warstwa kompatybilności dla aplikacji na Androida do uruchamiania w dystrybucjach Linuksa przy użyciu Wayland

Sprzęt mobilny i wbudowany

Weston działa na postmarketOS

Sprzęt mobilny i wbudowany obsługujący Wayland obejmuje:

Historia

Wayland używa bezpośredniego renderowania w EGL .

Kristian Høgsberg, grafik Linuksowy i programista X.Org, który wcześniej pracował nad AIGLX i DRI2 , założył Wayland jako projekt w wolnym czasie w 2008 roku, pracując dla Red Hata . Jego deklarowanym celem był system, w którym „każda klatka jest idealna, przez co mam na myśli to, że aplikacje będą w stanie kontrolować renderowanie na tyle, że nigdy nie zobaczymy rozrywania, opóźnień, przerysowywania ani migotania”. Høgsberg jechał przez miasto Wayland w stanie Massachusetts, gdy podstawowe pojęcia „skrystalizowały się”, stąd nazwa.

W październiku 2010 Wayland stał się projektem freedesktop.org . W ramach migracji poprzednia Grupa dyskusyjna Google została zastąpiona listą mailingową wayland-devel jako centralny punkt dyskusji i rozwoju projektu.

Biblioteki klienta i serwera Wayland zostały początkowo wydane na licencji MIT , podczas gdy kompozytor referencyjny Weston i niektórzy przykładowi klienci korzystali z Powszechnej Licencji Publicznej GNU w wersji 2 . Później cały kod GPL został ponownie licencjonowany na podstawie licencji MIT „aby ułatwić przenoszenie kodu między implementacją referencyjną a rzeczywistymi bibliotekami”. W 2015 roku odkryto, że tekst licencji używany przez Wayland był nieco inną i starszą wersją licencji MIT, a tekst licencji został zaktualizowany do aktualnej wersji używanej przez projekt X.Org (znanej jako MIT Expat License ).

Wayland współpracuje ze wszystkimi sterownikami kompatybilnymi z Mesa z obsługą DRI2, a także sterownikami Androida za pośrednictwem projektu Hybris .

Wydania

Wydania majora Waylanda i Westona
Wersja Data Główne cechy
Wayland Weston
Stara wersja, nie jest już utrzymywana: 0,85 9 lutego 2012 Pierwsze wydanie.
Stara wersja, nie jest już utrzymywana: 0,95 24 lipca 2012 Rozpoczęto stabilizację API.
Stara wersja, nie jest już utrzymywana: 1,0 22 października 2012 Stabilny interfejs API wayland-klient.
Stara wersja, nie jest już utrzymywana: 1,1 15 kwietnia 2013 Renderowanie oprogramowania. FBDEV, backendy RDP.
Stara wersja, nie jest już utrzymywana: 1.2 12 lipca 2013 Stabilny interfejs API serwera wayland. Zarządzanie kolorem. Podpowierzchnie. Zaplecze Raspberry Pi .
Stara wersja, nie jest już utrzymywana: 1,3 11 października 2013 Więcej formatów pikseli. Obsługa powiązań językowych. Obsługa sterowników Androida za pośrednictwem libhybris .
Stara wersja, nie jest już utrzymywana: 1,4 23 stycznia 2014 Nowe interfejsy wl_subcompositor i wl_subsurface. Wiele formatów bufora ramki. wsparcie logowania dla bezrootowanego Westona.
Stara wersja, nie jest już utrzymywana: 1,5 20 maja 2014 libinput. Powłoka pełnoekranowa.
Stara wersja, nie jest już utrzymywana: 1,6 19 września 2014 libinput domyślnie.
Stara wersja, nie jest już utrzymywana: 1,7 14 lutego 2015 Obsługa rozszerzenia prezentacji Wayland i ról powierzchniowych. Protokół powłoki IVI .
Stara wersja, nie jest już utrzymywana: 1,8 2 czerwca 2015 Oddzielne nagłówki dla rdzenia i wygenerowanego protokołu. Odśwież harmonogram. Nazwane wyjścia. Transformacje wyjściowe. API do strzelania powierzchniowego.
Stara wersja, nie jest już utrzymywana: 1,9 21 września 2015 Zaktualizowana licencja. Zaktualizowana licencja. Nowa platforma testowa. Trzygłowicowy kompozytor DRM. rozszerzenie linux_dmabuf.
Stara wersja, nie jest już utrzymywana: 1.10 17 lutego 2016 Funkcjonalność przeciągania i upuszczania, pogrupowane zdarzenia wskaźnika. Wideo 4 Linux 2, wprowadzanie dotykowe, ulepszenia debugowania.
Stara wersja, nie jest już utrzymywana: 1.11 1 czerwca 2016 Nowa procedura ładowania kopii zapasowych, nowa logika konfiguracji. Opakowania proxy, zmiany w pamięci współdzielonej, dokumentacja HTML generowana przez Doxygen.
Stara wersja, nie jest już utrzymywana: 1.12 21 września 2016 Poprawiono obsługę debugowania. libweston i libweston-desktop. Blokowanie wskaźnika i zamknięcie. Obsługa wskaźnika względnego.
Stara wersja, nie jest już utrzymywana: 1.13 24 lutego 2017 Zmieniono ABI firmy Weston, dlatego nowa wersja została nazwana 2.0.0 zamiast 1.13.0.
Stara wersja, nie jest już utrzymywana: 1,14 8 sierpnia 2017 Weston 3.0.0 został wydany w tym samym czasie.
Stara wersja, nie jest już utrzymywana: 1.15 9 kwietnia 2018 Weston 4.0.0 został wydany w tym samym czasie.
Stara wersja, nie jest już utrzymywana: 1,16 24 sierpnia 2018 Weston 5.0.0 został wydany w tym samym czasie.
Stara wersja, nie jest już utrzymywana: 1,17 20 marca 2019 Weston 6.0.0 został wydany w tym samym czasie.
Stara wersja, nie jest już utrzymywana: 1,18 2 sierpnia 2019 Weston 7.0.0 został wydany miesiąc później.
Aktualna stabilna wersja: 1.19 27 stycznia 2021
Westona 8 24 stycznia 2020
Westona 9 4 września 2020
Legenda:
Stara wersja
Starsza wersja, nadal utrzymywana
Ostatnia wersja
Najnowsza wersja zapoznawcza
Przyszłe wydanie

Zobacz też

Bibliografia

Zewnętrzne linki