Wie funktioniert die Anzeige von Linux?

Linux-Anzeige

Das Anzeigesystem von Linux verwendet mehrere Technologien, Protokolle, Erweiterungen, Anwendungen, Server (Daemon), Treiber und Konzepte, um beispielsweise das Fenstersystem zu erreichen:Xorg, Wayland, X11, OpenGL, RandR, XrandR, Bildschirmauflösung, DPI, Anzeigeserver , etc. Dies kann überwältigend sein, um es vollständig zu verstehen, aber jede Seite davon ist für einen bestimmten Zweck gedacht und sie werden nicht alle zusammen gleichzeitig verwendet.

X-Protokoll

Das X Window System, X11 (X Version 11) ist ein Fenstersystem für Bitmap-Anzeigen, das auf Unix-ähnlichen Betriebssystemen üblich ist. X bietet das Grundgerüst für eine GUI-Umgebung:Zeichnen und Verschieben von Fenstern auf dem Anzeigegerät und Interaktion mit Maus und Tastatur. X schreibt die Benutzeroberfläche nicht vor, dies wird von einzelnen Programmen gehandhabt. Daher variiert das visuelle Styling von X-basierten Umgebungen stark; verschiedene Programme können radikal unterschiedliche Schnittstellen darstellen. X entstand 1984 am Project Athena am Massachusetts Institute of Technology (MIT). Das X-Protokoll befindet sich seit September 1987 in Version 11 (daher "X11"). Die X.Org Foundation leitet das X-Projekt mit der aktuellen Referenzimplementierung , X.Org Server, verfügbar als kostenlose Open-Source-Software unter der MIT-Lizenz und ähnlichen freizügigen Lizenzen.

X-Implementierung

Die meisten Linux-Distributionen verwenden X.Org Server Dies ist die kostenlose Open-Source-Implementierung des Anzeigeservers für das X Window System (X11), die von der X.Org Foundation verwaltet wird. Xorg/X allein unterstützt nicht mehrere bereitgestellte Funktionen wie Skalierung oder Rendering, für das Xorg verwendet Erweiterungen wie XFixes, RandR (RandR wird von xrandr verwaltet Es kann beispielsweise Schwenken, Auflösung oder Skalierung), GLX (OpenGL-Erweiterung), Rendern oder Zusammensetzen einrichten, wodurch ein ganzer Unterbaum der Fensterhierarchie in einen Off-Screen-Puffer gerendert wird. Anwendungen können dann den Inhalt davon übernehmen Puffer speichern und tun, was sie wollen, der Off-Screen-Puffer kann automatisch in das übergeordnete Fenster eingefügt werden oder von externen Programmen zusammengeführt, die als Compositing Manager bezeichnet werden wie einige Fenstermanager selbst Compositing durchführen tun; Z.B. Compiz, Enlightenment, KWin, Marco, Metacity, Muffin, Mutter und Xfwm. Für andere "Nicht-Compositing " Fenstermanager, ein eigenständiger zusammengesetzter Manager kann verwendet werden, Beispiel:Picom, Xcompmgr oder Unagi. Von Xorg unterstützte Erweiterungen kann aufgelistet werden mit:xdpyinfo -display :0 -queryExtensions | awk '/^number of extensions:/,/^default screen number/' .

Andererseits Wayland ist als einfacherer Ersatz für Xorg/X11 gedacht, einfacher zu entwickeln und zu warten, aber ab 2020 ist die Desktop-Unterstützung für Wayland außer Gnome noch nicht vollständig fertig (z. B. KDE Kwin und Wayland-Unterstützung); Auf der Distributionsseite verwendet Fedora standardmäßig Wayland. Beachten Sie, dass Wayland und Xorg gleichzeitig arbeiten können, dies kann je nach verwendeter Konfiguration der Fall sein. XWayland ist eine Reihe von Patches über die Codebasis des X.Org-Servers, die einen X-Server implementieren, der auf dem Wayland-Protokoll läuft. Die Patches werden von den Wayland-Entwicklern für die Kompatibilität mit X11-Anwendungen während des Übergangs zu Wayland entwickelt und gepflegt und wurden 2014 in Version 1.16 des X.Org-Servers integriert. Wenn ein Benutzer eine X-Anwendung innerhalb von Weston ausführt, ruft es auf XWayland, um die Anfrage zu bedienen.

Der ganze Umfang

Ein Display-Server oder Windows-Server ist ein Programm (wie Xorg oder Wayland), dessen Hauptaufgabe es ist, die Eingabe und Ausgabe seiner Clients zum und vom Rest des Betriebssystems, der Hardware und untereinander zu koordinieren. Der Display-Server kommuniziert mit seinen Clients über das Display-Server-Protokoll, ein Kommunikationsprotokoll, das netzwerktransparent oder einfach netzwerkfähig sein kann. Beispielsweise sind X11 und Wayland Kommunikationsprotokolle für Anzeigeserver.

Wie im Diagramm zu sehen ein Fenstermanager ist ein weiteres wichtiges Element der Desktop-Umgebung, bei der es sich um eine Systemsoftware handelt, die die Platzierung und das Erscheinungsbild von Fenstern innerhalb eines Fenstersystems in einer grafischen Benutzeroberfläche steuert. Die meisten Fenstermanager sind so konzipiert, dass sie helfen, eine Desktop-Umgebung bereitzustellen. Sie arbeiten in Verbindung mit dem zugrunde liegenden Grafiksystem, das die erforderliche Funktionsunterstützung für Grafikhardware, Zeigegeräte und eine Tastatur bereitstellt, und werden häufig unter Verwendung eines Widget-Toolkits geschrieben und erstellt. KDE verwendet KWin als Fenstermanager (es hat ab 2020 eine eingeschränkte Unterstützung für Wayland), ähnlich verwendet Gnome 2 Metacity und Gnome 3 verwendet Mutter als Fenstermanager.

Ein weiterer wichtiger Aspekt eines Windows-Managers ist der Compositor oder Compositing Window Manager , ein Fenstermanager, der Anwendungen einen Off-Screen-Puffer für jedes Fenster bereitstellt. Der Fenstermanager setzt die Fensterpuffer zu einem Bild zusammen, das den Bildschirm darstellt, und schreibt das Ergebnis in den Anzeigespeicher. Zusammensetzende Fenstermanager können zusätzliche Verarbeitungen an gepufferten Fenstern durchführen, animierte 2D- und 3D-Effekte wie Mischen, Überblenden, Skalieren, Drehen, Duplizieren, Biegen und Verzerren, Mischen, Verwischen, Umleiten von Anwendungen und Übersetzen von Fenstern in eine von mehreren Anzeigen anwenden und virtuelle Desktops. Die Computergrafiktechnologie ermöglicht das Rendern visueller Effekte in Echtzeit, z. B. Schlagschatten, Live-Vorschauen und komplexe Animationen. Da der Bildschirm doppelt gepuffert ist, flimmert er bei Updates nicht. Zu den am häufigsten verwendeten Compositing-Window-Managern gehören:Linux, BSD, Hurd und OpenSolaris-Compiz, KWin, Xfwm, Enlightenment und Mutter. jeder hat seine eigene Implementierung, zum Beispiel der KWin's Compositor von KDE haben viele Funktionen/Einstellungen wie Animationsgeschwindigkeit, Tearing-Verhinderung (vsync), Fenster-Thumbnails, Skalierungsmethode und können OpenGLv2/OpenGLv3 oder XRender verwenden als Rendering-Backend zusammen mit Xorg. (XRender/Render nicht zu verwechseln mit XRandR/RandR).

OpenGL (Open Graphics Library) ist eine sprach- und plattformübergreifende Anwendungsprogrammierschnittstelle (API) zum Rendern von 2D- und 3D-Vektorgrafiken. Die API wird normalerweise verwendet, um mit einer Grafikverarbeitungseinheit (GPU) zu interagieren, um ein hardwarebeschleunigtes Rendern zu erreichen. OpenGL ist eine Rendering-Bibliothek, die mit Xorg, Wayland oder jeder Anwendung, die sie implementiert, verwendet werden kann. Die OpenGL-Installation kann mit glxinfo | grep OpenGL überprüft werden .

Die Anzeige Auflösung oder Anzeigemodi eines Computermonitors oder Anzeigegeräts ist die Anzahl unterschiedlicher Pixel in jeder Dimension, die angezeigt werden können. Es wird normalerweise als Breite × Höhe angegeben, mit der Einheit in Pixel:1024 × 768 bedeutet beispielsweise, dass die Breite 1024 Pixel und die Höhe 768 Pixel beträgt. xrandr kann verwendet werden, um eine neue Bildschirmauflösung hinzuzufügen oder zu rendern/simulieren.

Die DPI steht für Punkte pro Zoll und ist ein Maß für räumliches Drucken/Anzeigen , insbesondere die Anzahl der einzelnen Punkte, die innerhalb einer Spanne von 1 Zoll (2,54 cm) in einer Linie platziert werden können. Computerbildschirme haben keine Punkte, aber Pixel, das eng verwandte Konzept ist Pixel pro Zoll oder PPI und somit wird DPI mit dem PPI-Konzept implementiert. Der Standard 96 DPI-Maß bedeutet 96x96 vertikal und horizontal. Ist die Einstellung X DPI (dot per inch) nur für die Textskalierung gedacht? QA ist sehr informativ.

Notizen

Einige GUI-Tools von KDE: systemsettings5> Anzeige, kcmshell5 xserver und kinfocenter .

Referenzen

Links und Quellen: 1,2,3,4,5,6,7,8,9,10,11 und 12.

Die Frage ist ziemlich weit gefasst, und es könnte viel mehr zu diesem Thema geschrieben werden, als diese Antwort abdeckt. Ich habe versucht, eine historische Perspektive auf die Entwicklung der Linux-Grafik zu geben. Grafik, Fenstersysteme und grafische Benutzeroberflächen (GUIs) unter Linux haben seit Anfang der 1990er Jahre, als das X Window System (X11) auf Linux portiert wurde, viele Änderungen erfahren.

Das X Window System

Das X Window System wurde in den 1980er Jahren am MIT entwickelt. Der Name X11 bezieht sich auf die Protokollversion 11 des X-Protokolls, aber X10 wurde auch außerhalb des MIT verwendet, bevor es 1987 durch Version 11 ersetzt wurde.

Das X Window System wurde entwickelt, um auf Grafiksystemen zu funktionieren, die in den 1980er Jahren auf dem neuesten Stand der Technik waren. Eine typische Workstation hatte einen einzelnen Frame-Puffer, der mit einem einfachen CRT-Controller verbunden war, der den Inhalt des Frame-Puffers auf einem Anzeigemonitor anzeigte. Die Datenverarbeitung vor der Ära der PCs und Workstations wurde über Terminals mit serieller Leitung ("dumm") durchgeführt, die mit zentralen Computern verbunden waren, die sich in Computermaschinenräumen befanden. Dieser historische Kontext beeinflusste das Design von X11:Grafische Anwendungen konnten auf entfernten Computern ausgeführt werden, wobei der Benutzer über Terminals mit Grafikfähigkeiten mit dem Programm interagierte. Das "Terminal" könnte eine Workstation oder ein dediziertes X-Terminal sein.

X11 wurde als Server-Client-System konzipiert. Der X-Server war der einzige Teil, der direkt mit der Grafikhardware kommunizierte. Die X-Clients sind Anwendungsprogramme, die unter Verwendung des X-Protokolls mit dem Server kommunizieren, entweder unter Verwendung eines lokalen Unix-Domain-Sockets oder einer TCP/IP-Verbindung. Das X-Protokoll wird vom Client verwendet, um Anforderungen an den Server zu senden und Ereignismeldungen vom Server zu empfangen.

Anfragen beinhalten Nachrichten für:

• Fenstererstellung
• Mapping/Unmapping eines Fensters:Fenster sichtbar/unsichtbar machen
• Zeichnen auf dem Fenster:Zeichnen Sie Pixel, Linien, Bögen, Ovale, Pixmaps usw.
• Anzeigen von Text mit einer bestimmten Schriftart, Größe und Stil
• Verschieben und Ändern der Größe von Fenstern, Ändern der Stapelreihenfolge von Fenstern usw.

Clients empfangen Nachrichten (keine vollständige Liste):

• Antworten auf Anfragen
• Tastendruck- und Mausklick-Ereignisse
• Ereignisse anzeigen (ein Bereich eines Fensters muss neu gezeichnet werden)
• Gewinn-/Verlustereignisse konzentrieren

Um es dem Benutzer zu ermöglichen, die Fenster auf dem Bildschirm zu handhaben, z. B. ein Fenster zu verschieben, in der Größe zu ändern, zu schließen, anzuheben und abzusenken, wird eine spezielle Anwendung namens Fenstermanager bereitgestellt. Der Fenstermanager kann auch Fensterdekorationen wie Ränder, Titelleisten und globale Menüs anzeigen.

Man könnte sagen, der X11-Server ist ziemlich "hoch", da er alle Arten von Ressourcen handhabt (oder zumindest traditionell handhabt):Fenster, Schriftarten, Pixmaps, Farbkarten, grafische Kontexte (Dinge wie Vordergrund-/Hintergrundfarbe, Linienbreite usw ). Darüber hinaus kümmert sich der Server um Dinge wie Eltern-Kind-Beziehungen von Fenstern und die Stapelreihenfolge von Fenstern.

Das X-Protokoll ist so konzipiert, dass es erweiterbar ist. Dem X-Server kann beigebracht werden, neue Tricks auszuführen, und dem Protokoll werden neue Opecodes hinzugefügt, damit der Server diese Tricks ausführt. Beispielsweise führt die XRender-Erweiterung eine Möglichkeit ein, mit Transparenz umzugehen ("Alpha-Blending"). Diese Erweiterung wurde hauptsächlich eingeführt, um geglättete Schriftarten zu unterstützen, wurde aber auch für Desktop-Effekte wie Schlagschatten auf Fenstern verwendet. Die Erweiterung RandR ("Resize and Rotate") ermöglicht es, das Root-Fenster auf dem Bildschirm in der Größe zu ändern, zu drehen und zu spiegeln. Dadurch können Sie den Bildschirm mit einem auf dem Kopf stehenden Projektor projizieren oder einen geneigten Monitor verwenden.

Die GLX-Erweiterung (OpenGL Extension to the X Window System) ermöglicht es, OpenGL in einem vom X-Server bereitgestellten Fenster zu verwenden. Die Aufrufe von OpenGL sind in X-Protokollanforderungen eingebettet.

Irgendwann in der Entwicklung von X11 wurde die Handhabung von Schriftarten auf den Client verschoben. Die Gründe für diese Änderung werden in New Evolutions in the X Window System diskutiert.

Direktes Rendern

In den frühen 2000er Jahren hatte sich die Display-Hardware weit von den einfachen Schwarz-Weiß-Bitmap-Displays entfernt, die es gab, als die Entwicklung von X in den 1980er Jahren begann. Der relative X11-Overhead des IPC-Modells (Inter-Process Communication) war zu groß geworden, selbst wenn ein lokaler Socket verwendet wurde. Die Lösung hierfür bestand darin, das Prinzip aufzugeben, dass der X-Server der einzige Teil ist, der direkt mit der Hardware kommuniziert, und die Clients direkt mit der Grafikkarte sprechen zu lassen. Die Direct Rendering Infrastructure (DRI) war geboren.

DRI ermöglicht es einer X-Client-App, den X-Server zu umgehen und direkt auf dem Grafikadapter zu rendern. Da neben dem traditionellen X-Server mehrere Direct-Rendering-Anwendungen gleichzeitig aktiv sein können, wurde eine Kernel-Komponente namens Direct Rendering Manager eingeführt, um den Zugriff auf die Hardware zu vermitteln. Es gibt drei Versionen der DRI-Architektur, das ursprüngliche DRI (veraltet), DRI2 und DRI3.

Compositing-Window-Manager

Die nächste Innovation, die in die Linux-Grafikszene eindrang, war der Compositing Window Manager. Traditionell war jede X-Client-Anwendung dafür verantwortlich, ihre Fenster (teilweise oder das ganze Fenster) bei Bedarf neu zu zeichnen. Der X-Server hat der Anwendung ein Expose-Ereignis gesendet, wenn ein Repaint erforderlich war, weil das Fenster auf dem Bildschirm abgebildet wurde oder wenn es nicht mehr von einem anderen Fenster verdeckt wird. Wenn ein überlappendes Fenster entfernt wird, wird das Fenster darunter freigelegt. Wenn dieser Bereich nicht neu gezeichnet wird, werden die alten Inhalte weiterhin angezeigt. https://en.wikipedia.org/wiki/Visual_artifact

Ein Compositing Window Manager ändert dies. Anwendungen rendern in ihre eigenen Off-Screen-Puffer, von denen jeder eine Art separater Bildschirm mit exklusivem Zugriff durch die Anwendung ist, die den Puffer besitzt. Es ist die Aufgabe des zusammengesetzten Fenstermanagers, diese Puffer in Fenstern auf einem realen Bildschirm anzuzeigen, wobei alle Fenster abgeschnitten werden, die von anderen Fenstern verdeckt oder teilweise außerhalb des Bildschirms liegen. Der Fenstermanager zeigt eine "Zusammensetzung" der Fenster an.

Ein Compositing-Manager kann in der Regel auch animierte Effekte wie Skalieren, Warping, Verblassen, Rotieren, Weichzeichnen der Fenster anzeigen. Zum Beispiel kann das Bewegen eines Fensters es zum Wackeln bringen oder virtuelle Desktops können an der Seite eines rotierenden Würfels angezeigt werden.

Kernel-Modus-Einstellung

Der X-Server kümmerte sich traditionell auch um die Einstellung der Modi des Grafikadapters, wie Auflösung und Bildwiederholfrequenz. Die Moduseinstellung wurde inzwischen in eine Linux-Kernelkomponente namens Kernel Mode Setting (KMS) verschoben. Dies löste viele Probleme beim Umschalten zwischen den virtuellen Konsolen von Linux.

Evdev

Auch der X-Server hatte Kenntnis von den Eingabegeräten und beispielsweise musste der Maustyp in der X-Konfiguration angegeben werden. Der X-Server wurde von dieser Aufgabe durch die Einführung des evdev-Subsystems des Linux-Kernels entlastet, das eine generische Input-Event-Schnittstelle bereitstellt.

Wayland

Mit all diesen Entwicklungen sind viele der vom X-Server ausgeführten Aufgaben außerhalb des X-Servers verlagert worden. Beim direkten Rendern verwenden Clients das X-Protokoll nicht mehr. Dank KMS muss sich der X-Server nicht mit der Low-Level-Programmierung von Grafikkarten herumschlagen. Mit evdev wurde die Handhabung von Eingabegeräten im X-Server vereinfacht. Wenn Sie einen Compositing-Fenstermanager verwenden, der Fenster neu anordnet und verzerrt, hat der X-Server keine Ahnung mehr, was auf dem Bildschirm vor sich geht. "Der Fenstermanager ist der neue X-Server".

Wayland entstand aus der Erkenntnis, dass der X-Server-Prozess nur noch wenig zu tun hatte, und durch das Weglassen des Mittelsmanns (des X-Servers) konnte ein viel einfacheres Desktop-Grafiksystem erreicht werden. Abwärtskompatibilität wird über Xwayland bereitgestellt, einen modifizierten Xorg-Server, der Top-Level-X-Fenster mit Wayland-Oberflächen anzeigt.

Genau genommen ist Wayland nur ein Protokoll, das definiert, wie Clients mit dem Display-Server kommunizieren. Das Wayland-Protokoll ist ganz anders als das X-Protokoll:Das Wayland-Protokoll definiert keine Nachrichten zum Zeichnen von Grafiken oder Text und behandelt auch keine Schriftarten.

In der Wayland-Architektur werden der Window-Manager und der Display-Server zu einer Softwarekomponente, dem Compositing-Window-Manager, verschmolzen. Kunden können über eine Softwarebibliothek, die das Wayland-Protokoll verwendet, eine Oberfläche zum Zeichnen anfordern. Eine "Oberfläche ist ein Objekt, das einen rechteckigen Bereich auf dem Bildschirm darstellt, der durch Position, Größe und Pixelinhalt definiert ist".

Clients rendern in Puffer außerhalb des Bildschirms, die dann an eine Oberfläche angehängt werden und eine Ausgabe auf dem Bildschirm erzeugen. Der Client kann verschiedene APIs verwenden, um das Rendering durchzuführen:OpenGL, OpenGL ES usw. ("Was ist die Zeichnungs-API? Was auch immer Sie wollen") Es wird doppelte Pufferung verwendet:Ein Client aktualisiert sein Bild mit einem zweiten Puffer und wenn dieser Puffer ein kohärentes Bild enthält, wird es umgeschaltet, um beim nächsten vertikalen Austastintervall des Anzeigemonitors angezeigt zu werden. Waylands Motto lautet:„Every frame is perfect“, d. h. Fenster reißen, flackern oder blitzen nicht.

Die Eingabeverarbeitung in Wayland geht durch den Compositor, der die einzige Komponente ist, die weiß, welches Fenster sich unter dem Mauszeiger befindet (denken Sie daran, dass der Compositor die Fenster möglicherweise auch verzerrt hat). Der Compositor wandelt die Bildschirmkoordinaten in fensterlokale Koordinaten des entsprechenden Fensters um und sendet das Ereignis an den Client.

Wenn Sie an der Geschichte interessiert sind, die zur Entstehung von Wayland geführt hat, empfehle ich Ihnen, sich Daniel Stones urkomische Präsentation Die wahre Geschichte hinter Wayland und X anzusehen.