Jak zorganizowany jest stos grafiki Linuksa?

Czy ktoś może wyjaśnić (mam nadzieję, że ze zdjęciem), jak zorganizowany jest stos grafiki Linuksa? Cały czas słyszę o X / GTK / GNOME / KDE itp., Ale tak naprawdę nie mam pojęcia, co tak naprawdę robią i jak współdziałają ze sobą oraz innymi częściami stosu. Jak pasują Unity i Wayland?

System X Window korzysta z architektury klient-serwer. Serwer X działa na komputerze z wyświetlaczem (monitory + urządzenia wejściowe), podczas gdy klienci X mogą działać na dowolnym innym komputerze i łączyć się z serwerem X za pomocą protokołu X (nie bezpośrednio, ale raczej za pomocą biblioteki, takiej jak Xlib lub bardziej nowoczesny, nieblokujący XCB sterowany zdarzeniami). Protokół X ma być rozszerzalny i ma wiele rozszerzeń (patrz xdpyinfo(1)).

Serwer X wykonuje tylko operacje niskiego poziomu, takie jak tworzenie i niszczenie okien, wykonywanie operacji rysowania (obecnie większość rysunków odbywa się na kliencie i wysyłana jako obraz do serwera), wysyłanie zdarzeń do okien, ... Możesz zobaczyć, jak mało serwer X działa, uruchamiając X :1 &(użyj dowolnej liczby, która nie jest jeszcze używana przez inny serwer X) lub Xephyr :1 &(Xephyr uruchamia serwer X osadzony na bieżącym serwerze X), a następnie uruchamiając xterm -display :1 &i przełączając się na nowy serwer X (może być konieczne skonfigurowanie autoryzacji X za pomocą xauth(1)).

Jak widać, serwer X robi bardzo mało, nie rysuje pasków tytułowych, nie minimalizuje / ikonizuje okna, nie zarządza rozmieszczeniem okien ... Oczywiście można sterować rozmieszczeniem okien ręcznie uruchamiając polecenie jak xterm -geometry -0-0, ale zwykle będziesz mieć specjalnego klienta X wykonującego powyższe czynności. Ten klient nazywa się menedżerem okien . Jednocześnie może być aktywny tylko jeden menedżer okien. Jeśli nadal masz otwarte goły serwer X poprzednich poleceń, można spróbować uruchomić menedżer okien na nim, jak twm, metacity, kwin, compiz, larswm, pawm, ...

Jak powiedzieliśmy, X wykonuje tylko operacje niskiego poziomu i nie zapewnia koncepcji wyższego poziomu, takich jak przyciski, menu, paski narzędzi, ... Są one dostarczane przez biblioteki zwane zestawami narzędzi , np .: Xaw, GTK, Qt, FLTK, ...

Środowiska pulpitu są kolekcjami programów zaprojektowanych w celu zapewnienia jednolitego interfejsu użytkownika. Środowiska pulpitu zazwyczaj zapewniają panele, programy uruchamiające aplikacje, tace systemowe, panele sterowania, infrastrukturę konfiguracji (gdzie zapisać ustawienia). Niektóre dobrze znane środowiska graficzne to KDE (zbudowane przy użyciu zestawu narzędzi Qt), Gnome (przy użyciu GTK), Oświecenie (przy użyciu własnych bibliotek narzędzi), ...

Niektóre nowoczesne efekty pulpitu najlepiej wykonywać przy użyciu sprzętu 3D. Pojawia się nowy komponent, menedżer kompozytów . Rozszerzenie X, rozszerzenie XComposite, wysyła zawartość okna do menedżera kompozytów. Menedżer kompozytów konwertuje te treści na tekstury i używa sprzętu 3D za pomocą OpenGL do komponowania ich na wiele sposobów (mieszanie alfa, projekcje 3D, ...).

Nie tak dawno temu serwer X rozmawiał bezpośrednio z urządzeniami sprzętowymi. Znaczna część obsługi tego urządzenia została przeniesiona do jądra systemu operacyjnego: DRI (umożliwiający dostęp do sprzętu 3d przez X i klientów bezpośredniego renderowania), evdev (zunifikowany interfejs do obsługi urządzeń wejściowych), KMS (przeniesienie ustawienia trybu graficznego na jądro) , GEM / TTM (zarządzanie pamięcią tekstur).

Dzięki złożoności obsługi urządzeń, które obecnie znajdują się głównie poza X, łatwiej było eksperymentować z uproszczonymi systemami okien. Wayland to system okien oparty na koncepcji menedżera kompozytów, tzn. Systemem okien jest menedżer kompozytów. Wayland korzysta z obsługi urządzeń, która wyszła z X i renderuje przy użyciu OpenGL.

Jeśli chodzi o Unity, jest to środowisko komputerowe zaprojektowane z interfejsem użytkownika odpowiednim dla netbooków.

Tradycyjny stos składa się z 3 głównych elementów:

• Serwer X, który obsługuje wyświetlanie
• Menedżer okien, który umieszcza okna w ramkach, obsługuje minimalizowanie okien itp. Jest to część oddzielenia mechanizmu od polityki w Uniksie
• Klienci, którzy wykonują przydatne zadanie, wyświetlając witrynę Stackexchange. Mogą używać protokołu X bezpośrednio (samobójstwo), używać xlib lub xcb (nieco łatwiej) lub korzystać z zestawu narzędzi, takiego jak GTK + lub QT.

Architektura X została utworzona jako sieć, dzięki czemu klienci mogą znajdować się na osobnym hoście, a następnie na serwerze.

Jak na razie dobrze. To był jednak obraz z dawnych lat. Obecnie to nie procesor obsługuje grafikę, ale GPU. Podejmowano różne próby włączenia go do modelu - i miejsca, w którym jądro pojawia się w większym stopniu.

Po pierwsze, przyjęto pewne założenia dotyczące używania karty graficznej. Na przykład przyjęto tylko renderowanie na ekranie. Nie mogę teraz znaleźć tych informacji na Wikipedii, ale DRI 1 również założyło, że tylko jedna aplikacja będzie korzystać z OpenGL w tym samym czasie (nie mogę od razu zacytować, ale mogę wykopać błąd tam, gdzie był blisko jako WONTFIX z notatką, aby czekać na DRI 2).

Zaproponowano kilka rozwiązań tymczasowych do renderowania pośredniego (potrzebne w przypadku kompozytowego WM):

• XGL - wczesna propozycja wspierająca aplikacje komunikujące się bezpośrednio z kartą
• AIGLX - zaakceptowana propozycja korzystająca z właściwości sieciowych protokołu OpenGL
• Autorskie rozwiązanie NVidia

Rozpoczęto prace nad nowszą architekturą (DRI 2). To obejmowało:

• Obsługa wbudowanego jądra do obsługi pamięci (GEM / TTM)
• Ustawienie trybu jądra (KMS) pozwalające na zmianę rozdzielczości w jądrze, dzięki czemu unika się opóźnień podczas przełączania między X i konsolą i kilku innych funkcji (takich jak wyświetlanie komunikatu w trybie paniki nawet, gdy X jest uruchomiony - które IIRC jest planowane do wdrożenia).

W jakiś sposób ortogonalne przejście do jądra rozpoczęto prace nad sterownikami Gallium. Biblioteka Mesa rozpoczęła się jako implementacja OpenGL na CPU, a następnie zaczęła korzystać z akceleracji GPU. Zawsze były dokręcone do OpenGL. W OpenGL 3.0 model znacznie się zmienił, a przepisanie biblioteki było nieuniknione. Korzystają jednak z okazji, aby podzielić kod na kilka warstw wyodrębniających wspólny kod i udostępniających niskopoziomowy interfejs API, który pozwala na implementację różnych interfejsów API 3D na nim - pozwalając na przykład Wine, aby DirectX rozmawiał bezpośrednio z Gallium zamiast przechodzić przez OpenGL Warstwa API (która może nie mieć bezpośrednich wywołań 1-1).

Wayland to projekty, które uważają to za nieco skomplikowane i ze zbyt „historią”. Projekt z 1984 roku (choć wysoce zmodyfikowany i dostosowany) nie odpowiada początkowi 21 wieku. według zwolenników.

Zakłada się, że oferuje większą elastyczność i lepszą wydajność, chociaż wciąż brakuje niektórych ważnych funkcji, takich jak pełne wsparcie OpenGL (i ważne dla niektórych - obsługa sieci).

Nieco więcej na temat środowisk pulpitu i menedżerów okien. Menedżer okien jest aplikacją odpowiedzialną za zachowanie okna - na przykład odpowiada za zarządzanie przestrzeniami roboczymi, rysowanie paska tytułowego (rzecz na górze ekranu z tytułem windo i przyciskami minimalizacji / maksymalizacji / zamykania) itp.

Po pierwsze użyto tylko minimalnej WM, ale później użytkownik zaczął chcieć środowiska pulpitu - tj. Bardziej funkcjonalną wersję, która obejmowała uruchomienie menu, tło pulpitu itp. Jednak większość części środowiska pulpitu nie jest menedżerem okien, chociaż często są one zintegrowane.

Po pewnym czasie wprowadzono kompozyt WM, który wykorzystuje OpenGL i renderowanie pośrednie do swojej pracy. Zapewniają nie tylko efekty graficzne, ale także umożliwiają łatwiejszą implementację niektórych funkcji ułatwień dostępu (takich jak lupa).

Po pierwsze, naprawdę nie ma stosu graficznego dla Linuksa. Linux nie ma możliwości wyświetlania graficznego.

Jednak aplikacje Linuksa mogą korzystać z wyświetlaczy graficznych i istnieje do tego szereg różnych systemów. Najpopularniejsze z nich są zbudowane na X oknach.

X jest protokołem sieciowym, ponieważ w środku stosu protokołów X można mieć sieć jako standardowy komponent. Spójrzmy na konkretny przypadek użycia. Fizyk z Berlina chce przeprowadzić eksperyment w CERN w Szwajcarii na jednym z zderzaczy cząstek jądrowych. Loguje się zdalnie i uruchamia program do analizy danych na jednej z superkomputerowych macierzy CERN i wyświetla wyniki na ekranie.

W Berlinie fizyk ma urządzenie X-terminal, na którym działa oprogramowanie X-server, które umożliwia graficzne wyświetlanie zdalnym aplikacjom. Oprogramowanie serwera X ma bufor ramki, który komunikuje się ze sterownikiem określonego urządzenia dla określonego sprzętu. Oprogramowanie X-server obsługuje protokół X. Tak więc warstwy mogą być graficznie urządzenie-> sterownik urządzenia-> bufor ramki-> X serwer-> protokół X.

Następnie w Szwajcarii aplikacja łączy się z wyświetlaczem za pomocą protokołu X i wysyła komendy graficzne, takie jak „narysuj prostokąt” lub „mieszanka alfa”. Aplikacja prawdopodobnie korzysta z biblioteki graficznej wysokiego poziomu, która z kolei prawdopodobnie będzie oparta na bibliotece niższego poziomu. Na przykład aplikacja może być napisana w Pythonie przy użyciu zestawu narzędzi WxWidget, który jest zbudowany na GTK, który korzysta z biblioteki o nazwie Kair do podstawowych graficznych poleceń rysunkowych. Może być również OPENGL również na szczycie Kairu. Warstwy mogą wyglądać tak: WxWidgets-> GTK-> Cairo-> X Toolkit-> protokół X. Najwyraźniej jest to protokół pośrodku, który łączy rzeczy, a ponieważ Linux obsługuje również gniazda UNIX, całkowicie wewnętrzny transport danych, te dwa rodzaje rzeczy mogą działać na jednym komputerze, jeśli chcesz.

X odnosi się do protokołu i wszelkich podstawowych elementów architektury, takich jak X-serwer, który obsługuje wyświetlacz graficzny, urządzenie wskazujące i klawiaturę.

GTK i QT to dwie biblioteki GUI ogólnego przeznaczenia, które obsługują okna, okna dialogowe, przyciski itp.

GNOME i KDE to dwa środowiska pulpitu, które zarządzają oknami na graficznym pulpicie, zapewniają przydatne aplety i inne rzeczy, takie jak paski przycisków. Pozwalają także wielu aplikacjom na komunikację przez serwer X (urządzenie X-terminal), nawet jeśli aplikacje działają na różnych komputerach zdalnych. Na przykład kopiowanie i wklejanie jest formą komunikacji między aplikacjami. GNOME jest zbudowany na bazie GTK. KDE jest oparte na QT. Możliwe jest uruchamianie aplikacji GNOME na pulpicie KDE lub aplikacji KDE na pulpicie GNOME, ponieważ wszystkie one działają z tym samym bazowym protokołem X.

To jest jego organizacja, dowiesz się więcej z tego obrazu, że z kilku stron tekstu:

Linux na komputerze stacjonarnym i niektóre serwery to wciąż cała grafika bufora X i ramki. Pod oknem X - pojawia się GTK + i Qt, TAK ZARÓWNO używa systemu X, ponownie istnieje wiele środowisk graficznych - Gnome, KDE używa X wyświetlacza i ich powłok itp.

Przy okazji, był ostatni film z linux conf (http://blip.tv/file/4693305/). Keith Packard z Intela mówił o X i GL * To było interesujące.