Wie ist der Linux-Grafikstapel organisiert?

Kann jemand (hoffentlich mit einem Bild) erklären, wie der Linux-Grafikstapel organisiert ist? Ich höre die ganze Zeit über X / GTK / GNOME / KDE usw., aber ich habe wirklich keine Ahnung, was sie tatsächlich tun und wie sie miteinander und mit anderen Teilen des Stapels interagieren. Wie passen Unity und Wayland zusammen?

Das X Window System verwendet eine Client-Server-Architektur. Der X-Server wird auf dem Computer ausgeführt, auf dem das Display angezeigt wird (Monitore + Eingabegeräte), während X-Clients auf jedem anderen Computer ausgeführt werden können und über das X-Protokoll eine Verbindung zum X-Server herstellen können (nicht direkt, sondern mithilfe einer Bibliothek, z. B. Xlib oder das modernere nicht blockierende ereignisgesteuerte XCB). Das X-Protokoll ist erweiterbar und hat viele Erweiterungen (siehe xdpyinfo(1)).

Der X-Server führt nur Operationen auf niedriger Ebene aus, z. B. das Erstellen und Zerstören von Fenstern, Zeichnungsoperationen (heutzutage werden die meisten Zeichen auf dem Client ausgeführt und als Bild an den Server gesendet), Senden von Ereignissen an Fenster usw. Sie können sehen, wie wenig Ein X-Server wird ausgeführt X :1 &(verwenden Sie eine beliebige Nummer, die noch nicht von einem anderen X-Server verwendet wurde) oder Xephyr :1 &(Xephyr führt einen auf Ihrem aktuellen X-Server eingebetteten X-Server aus) und anschließend ausgeführt xterm -display :1 &und wechselt auf den neuen X-Server (möglicherweise müssen Sie die X-Autorisierung einrichten) mit xauth(1)).

Wie Sie sehen, macht der X-Server sehr wenig, zeichnet keine Titelleisten, minimiert / iconifiziert keine Fenster, verwaltet keine Fensterplatzierung ... Natürlich können Sie die Fensterplatzierung auch manuell steuern, indem Sie einen Befehl ausführen wie xterm -geometry -0-0, aber Sie werden in der Regel einen speziellen X-Client haben, der die obigen Dinge tut. Dieser Client wird als Fenstermanager bezeichnet . Es kann immer nur ein Fenstermanager aktiv sein. Wenn Sie immer noch den blanken X - Server der vorherigen Befehle geöffnet haben, können Sie versuchen , einen Window - Manager auf, um sie auszuführen, wie twm, metacity, kwin, compiz, larswm, pawm, ...

Wie bereits erwähnt, führt X nur Operationen auf niedriger Ebene aus und bietet keine Konzepte auf höherer Ebene wie Drucktasten, Menüs, Symbolleisten usw. Diese werden von Bibliotheken bereitgestellt, die als Toolkits bezeichnet werden , z. B. Xaw, GTK, Qt, FLTK usw.

Desktop-Umgebungen sind Sammlungen von Programmen, die eine einheitliche Benutzererfahrung bieten sollen. In Desktop-Umgebungen werden daher in der Regel Panels, Anwendungsstarter, Taskleisten, Control Panels und Konfigurationsinfrastruktur bereitgestellt (zum Speichern von Einstellungen). Einige bekannte Desktop-Umgebungen sind KDE (mit dem Qt-Toolkit erstellt), Gnome (mit GTK), Enlightenment (mit eigenen Toolkit-Bibliotheken), ...

Einige moderne Desktop-Effekte lassen sich am besten mit 3D-Hardware erzielen. Es erscheint also eine neue Komponente, der Composite Manager . Eine X-Erweiterung, die XComposite-Erweiterung, sendet Fensterinhalte an den Composite-Manager. Der Composite Manager konvertiert diese Inhalte in Texturen und verwendet 3D-Hardware über OpenGL, um sie auf vielfältige Weise zu komponieren (Alpha-Blending, 3D-Projektionen, ...).

Vor nicht allzu langer Zeit sprach der X-Server direkt mit Hardwaregeräten. Ein wesentlicher Teil dieser Geräteverwaltung wurde auf den Betriebssystemkern verlagert: DRI (ermöglicht den Zugriff von X- und Direct-Rendering-Clients auf 3D-Hardware ), evdev (einheitliche Schnittstelle für die Verwaltung von Eingabegeräten), KMS (Verschieben der Grafikmoduseinstellung auf den Kernel). , GEM / TTM (Texturspeicherverwaltung).

Angesichts der Komplexität der Gerätehandhabung, die jetzt zum größten Teil außerhalb von X stattfindet, wurde es einfacher, mit vereinfachten Fenstersystemen zu experimentieren. Wayland ist ein Fenstersystem, das auf dem Composite-Manager-Konzept basiert, dh das Fenstersystem ist der Composite-Manager. Wayland nutzt das Device-Handling, das aus X herausgezogen ist, und rendert mit OpenGL.

Unity ist eine Desktop-Umgebung mit einer für Netbooks geeigneten Benutzeroberfläche.

Der traditionelle Stack besteht aus 3 Hauptkomponenten:

• X-Server, der die Anzeige übernimmt
• Fenstermanager, der Fenster in Frames einfügt, Fenster minimiert usw. Dies ist Teil der Trennung des Mechanismus von der Richtlinie in Unix
• Clients, die nützliche Aufgaben wie das Anzeigen der StackExchange-Website ausführen. Sie können das X-Protokoll direkt verwenden (Selbstmord), xlib oder xcb (etwas einfacher) oder ein Toolkit wie GTK + oder QT verwenden.

Die X-Architektur wurde zu einem Netzwerk gemacht, sodass sich die Clients auf einem anderen Host als dem Server befinden können.

So weit, ist es gut. Das war jedoch das Bild von damals. Heutzutage ist nicht die CPU für die Grafik zuständig, sondern die GPU. Es gab verschiedene Versuche, es in das Modell einzubeziehen - und es zu platzieren, wenn der Kernel in größerem Umfang vorhanden ist.

Erstens wurden einige Annahmen hinsichtlich der Verwendung von Grafikkarten getroffen. Zum Beispiel wurde nur das Bildschirm-Rendering angenommen. Ich kann diese Information momentan nicht auf Wikipedia finden, aber DRI 1 ging auch davon aus, dass nur eine Anwendung OpenGL zur gleichen Zeit verwenden wird 2).

Für das indirekte Rendern wurden einige vorübergehende Lösungen vorgeschlagen (für Composite-WM erforderlich):

• XGL - Frühes Angebot, das Anwendungen unterstützt, die direkt mit der Karte kommunizieren
• AIGLX - akzeptierter Vorschlag, der die Netzwerkeigenschaften des OpenGL-Protokolls verwendet
• Proprietäre Lösung von NVidia

Die Arbeiten an einer neueren Architektur (DRI 2) wurden begonnen. Das enthielt:

• In-Kernel-Unterstützung für Memory Handling (GEM / TTM)
• Kernel-Modesetting (KMS), mit dem die Auflösung im Kernel geändert werden kann, um Verzögerungen beim Wechsel zwischen X und Konsole sowie einige andere Funktionen zu vermeiden (z. B. das Anzeigen von Meldungen in Panik, auch wenn X ausgeführt wird - welche IIRC soll implementiert werden).

Irgendwie orthogonal zum Kernel wurden die Arbeiten an Gallium-Treibern begonnen. Die Mesa-Bibliothek wurde als Implementierung von OpenGL auf der CPU gestartet und verwendete dann die GPU-Beschleunigung. Es war schon immer eng mit OpenGL. In OpenGL 3.0 hat sich das Modell erheblich geändert und das Neuschreiben der Bibliothek war unvermeidlich. Sie nutzen jedoch die Gelegenheit, den Code in mehrere Ebenen aufzuteilen, um gemeinsamen Code zu extrahieren und eine Low-Level-API bereitzustellen, mit der verschiedene 3D-APIs darüber implementiert werden können. So kann beispielsweise Wine DirectX direkt für Gallium bereitstellen, anstatt OpenGL zu verwenden API-Schicht (die möglicherweise keine direkten 1-1-Aufrufe hat).

Wayland ist ein Projekt, das das Obige als etwas kompliziert und mit zu "Geschichte" betrachtet. Der Entwurf von 1984 (obwohl stark modifiziert und angepasst) entspricht nicht dem Beginn des 21. Jahrhunderts. laut Befürworter.

Es wird angenommen, dass es eine größere Flexibilität und bessere Leistung bietet, obwohl einige wichtige Funktionen wie die vollständige OpenGL-Unterstützung noch fehlen (und für einige wichtig - Netzwerkunterstützung).

Ein bisschen mehr über Desktop-Umgebungen und Fenstermanager. Der Fenstermanager ist eine Anwendung, die für das Verhalten des Fensters verantwortlich ist - zum Beispiel für die Verwaltung der Arbeitsbereiche, das Zeichnen der Titelleiste (das Ding oben auf dem Bildschirm mit dem Windo-Titel und den Schaltflächen zum Minimieren / Maximieren / Schließen) usw.

Zuerst wurde nur minimales WM verwendet, aber danach wollte der Benutzer Desktop-Umgebungen - dh eine umfassendere Version, die Menüstart, Desktop-Hintergrund usw. umfasste. Die meisten Teile der Desktop-Umgebung sind jedoch kein Fenstermanager, obwohl sie häufig integriert sind.

Nach einiger Zeit wurde das Composite-WM eingeführt, das OpenGL und indirektes Rendering verwendet, um seine Arbeit zu erledigen. Sie bieten nicht nur grafische Effekte, sondern ermöglichen auch die einfachere Implementierung einiger Eingabehilfen (z. B. Lupe).

Erstens gibt es wirklich keinen Linux-Grafikstack. Linux hat keine grafischen Darstellungsmöglichkeiten.

Linux-Anwendungen können jedoch grafische Darstellungen verwenden, und dafür gibt es eine Reihe unterschiedlicher Systeme. Die gängigsten sind alle auf X-Fenstern aufgebaut.

X ist ein Netzwerkprotokoll, da Sie in der Mitte eines X-Protokollstapels ein Netzwerk als Standardkomponente haben können. Schauen wir uns einen bestimmten Anwendungsfall an. Ein Berliner Physiker will am CERN in der Schweiz ein Experiment mit einem der Teilchenkollider durchführen. Er meldet sich remote an, führt ein Datenanalyseprogramm auf einem der CERN-Supercomputer-Arrays aus und zeichnet die Ergebnisse auf seinem Bildschirm auf.

In Berlin verfügt der Physiker über ein X-Terminal-Gerät, auf dem eine X-Server-Software ausgeführt wird, die Remoteanwendungen eine grafische Anzeige ermöglicht. Die X-Server-Software verfügt über einen Framebuffer, der mit dem spezifischen Gerätetreiber für die spezifische Hardware kommuniziert. Und die X-Server-Software spricht das X-Protokoll. Die Ebenen können also grafische Geräte-> Gerätetreiber-> Frame Buffer-> X Server-> X Protokoll sein.

In der Schweiz stellt die Anwendung dann über das X-Protokoll eine Verbindung zu einem Display her und sendet grafische Anzeigebefehle wie "Rechteck zeichnen" oder "Alphamischung". Die Anwendung verwendet wahrscheinlich eine Grafikbibliothek auf hoher Ebene, und diese Bibliothek wird wahrscheinlich wiederum auf einer Bibliothek auf niedrigerer Ebene basieren. Zum Beispiel kann die Anwendung in Python mit dem WxWidget-Toolkit geschrieben werden, das auf GTK aufbaut und eine Bibliothek namens Cairo für die wichtigsten grafischen Zeichenbefehle verwendet. Möglicherweise gibt es auch OPENGL auf Kairo. Die Ebenen könnten folgendermaßen aussehen: WxWidgets-> GTK-> Cairo-> X Toolkit-> X-Protokoll. Natürlich ist es das Protokoll in der Mitte, das die Dinge verbindet, und da Linux auch UNIX-Sockets unterstützt, einen vollständig internen Transport für Daten, können diese beiden Arten von Dingen auf einem Computer ausgeführt werden, wenn Sie möchten.

X bezieht sich auf das Protokoll und auf alles, was für die Architektur von grundlegender Bedeutung ist, z. B. den X-Server, auf dem die grafische Anzeige, das Zeigegerät und die Tastatur ausgeführt werden.

GTK und QT sind zwei allgemeine GUI-Bibliotheken, die Fenster, Dialoge, Schaltflächen usw. unterstützen.

GNOME und KDE sind zwei Desktop-Umgebungen, die die Fenster auf dem grafischen Desktop verwalten, nützliche Applets und Dinge wie Schaltflächenleisten bereitstellen. Sie ermöglichen auch die Kommunikation mehrerer Anwendungen über den X-Server (X-Terminal-Gerät), selbst wenn die Apps auf verschiedenen Remotecomputern ausgeführt werden. Kopieren und Einfügen ist beispielsweise eine Form der Interapplikationskommunikation. GNOME basiert auf GTK. KDE baut auf QT auf. Und es ist möglich, GNOME-Apps auf einem KDE-Desktop oder KDE-Apps auf einem GNOME-Desktop auszuführen, da alle mit demselben zugrunde liegenden X-Protokoll arbeiten.

Dies ist seine Organisation, aus diesem Bild lernen Sie mehr als aus mehreren Textseiten:

Linux auf dem Desktop und einigen Servern ist immer noch alles X- und Frame-Buffer-Grafik. Unter X-Window -Es kommt GTK + und Qt, JA, BEIDES verwendet X-System, wieder gibt es viele Desktop-Umgebungen - Gnome, KDE verwendet X-Display und ihre Shells usw.

Übrigens gab es ein aktuelles Video von Linux Conf (http://blip.tv/file/4693305/). Keith Packard von Intel sprach über X und GL * Es war interessant.