Wayland und Qt
Wayland wurde als Alternative zu X11 unter Linux entwickelt. Sein Hauptzweck besteht darin, zu verwalten, wie der Inhalt von Anwendungen gemeinsam auf einem gemeinsamen Bildschirm angezeigt wird und wie ein Benutzer mit mehreren Anwendungen interagieren kann, die dieselben Eingabegeräte verwenden.
Diese Rolle in einem Betriebssystem wird oft als Display-Server bezeichnet. Der Wayland-Anzeigeserver wird manchmal auch als Compositor und Fenstermanager bezeichnet, was sich auf bestimmte Aufgaben bezieht, die er als Teil seiner Aufgabe ausführt.
Im Folgenden werden wir eine kurze Einführung in Wayland und seine Rolle in Qt geben. Weitere Details und Hintergründe zu Wayland selbst finden Sie in der offiziellen Dokumentation.
Was ist ein Display Server?
Der Display-Server ist der Teil des Betriebssystems, der die Bildschirmfläche und andere gemeinsam genutzte Ressourcen verwaltet. Auf einem typischen Desktop-System können viele unabhängige Anwendungen gleichzeitig laufen, von denen jede erwartet, dass sie in der Lage ist, Grafiken auf dem Bildschirm darzustellen und Eingaben zu empfangen.
Der Anzeigeserver ist das Bindeglied zwischen der Anwendung und den gemeinsam genutzten Ressourcen wie dem Bildschirm und den Eingabegeräten. Ein typischer Anzeigeserver auf einem Desktop-System platziert den Anwendungsinhalt in verschiedenen rechteckigen "Fenstern", die vom Benutzer verschoben und in der Größe verändert werden können. Der Anzeigeserver sorgt dafür, dass der Anwendungsinhalt an der richtigen Stelle auf dem Bildschirm angezeigt wird, dass das aktive Fenster Eingaben von der Tastatur empfängt, dass sich überlappende Fenster in der richtigen Reihenfolge gezeichnet werden und so weiter.
Bei anderen Systemtypen kann der Anzeigeserver restriktiver sein. Handelt es sich bei dem Bildschirm beispielsweise um ein Armaturenbrett in einem Auto oder um das Bedienfeld eines Gabelstaplers, dann ist das Verschieben und Ändern der Größe von Fenstern möglicherweise nicht erwünscht. Stattdessen kann jede Anwendung auf einen vordefinierten Bereich des Bildschirms festgelegt werden und Eingaben von vorher zugewiesenen Geräten erhalten.
Solange mehrere isolierte Prozesse um dieselben Ressourcen konkurrieren, ist ein Display-Server in jedem Fall sinnvoll.
Die Rolle von Wayland
Der Name Wayland kann sich auf mehrere verwandte Elemente beziehen:
- Eine Reihe von Protokollen für die Kommunikation zwischen einem Display-Server und seinen Clients.
- Eine in C geschriebene Bibliothek mit Funktionen für die Kommunikation zwischen Prozessen, die als Grundlage für die Implementierung dieser Protokolle dient.
- Eine XML-basierte Sprache zur Erweiterung des Protokolls sowie ein Werkzeug zur Erzeugung von Bindungscode in C aus solchen Erweiterungen.
Qt bietet Implementierungen sowohl für die Client- als auch für die Serverseite des Protokolls.
Normale Qt-Anwendungen können als Clients auf einem Wayland-Anzeigeserver ausgeführt werden, indem das QPA-Plugin "wayland" ausgewählt wird (dies ist auf bestimmten Systemen die Standardeinstellung). Darüber hinaus kann das Qt Wayland Compositor Modul verwendet werden, um den Display-Server selbst zu entwickeln.
Qt verfügt auch über Komfortfunktionen zur einfachen Erweiterung der Wayland-Protokolle um neue Schnittstellen.
Wayland und andere Technologie
Auf dem Linux-Desktop ist Wayland eine Alternative zu X11 und verwandten Erweiterungen. Im Kern handelt es sich um einen Compositing-Display-Server, und der Begriff "Compositor" wird häufig zur Beschreibung des Wayland-Servers verwendet. Das bedeutet, dass Clients Inhalte in einen Puffer außerhalb des Bildschirms rendern, die später mit anderen Clients auf dem Bildschirm "zusammengesetzt" werden, wodurch Fenstereffekte wie Schlagschatten, Transparenz, Hintergrundunschärfe usw. möglich sind.
Ein wichtiges Gestaltungsprinzip der ursprünglichen X11-Protokolle besteht darin, dass der Display-Server auf einem Thin-Terminal mit nur einem Bildschirm und Eingabegeräten laufen kann. Die Clients würden dann auf entfernten Systemen mit mehr Rechenleistung laufen und mit dem Server über eine Netzwerkverbindung kommunizieren.
Im Gegensatz dazu basiert Wayland auf der Beobachtung, dass in modernen Systemen der Client und der Display-Server in der Regel auf der gleichen Hardware laufen. Verteiltes Rechnen, Remote-Storage und Remote-Desktop-Funktionen werden normalerweise über andere Mechanismen abgewickelt. Die Integration dieser Funktionen in das Protokoll ermöglicht die gemeinsame Nutzung des Grafikspeichers durch den Client und den Server: Wenn der Compositor Client-Inhalte auf dem Bildschirm platziert, kann er sie einfach von einem Teil des Grafikspeichers in einen anderen kopieren.
Damit dies optimal funktioniert, muss der Grafiktreiber Wayland unterstützen. Diese Unterstützung wird durch eine Erweiterung von EGL bereitgestellt, die EXT_platform_wayland genannt wird.
Hinweis: Qt Wayland unterstützt Compositing auch auf Systemen, auf denen EXT_platform_wayland nicht unterstützt wird, entweder durch XComposite oder durch Kopieren von Anwendungsinhalten in den gemeinsamen CPU-Speicher. Für optimale Leistung empfehlen wir jedoch Systeme mit Treiberunterstützung.
X11 wurde erweitert, um Funktionen wie Composition und Direct Rendering zu unterstützen, aber Wayland wurde von Grund auf für diesen Anwendungsfall entwickelt. Im Gegensatz zu der Komplexität, die X11 im Laufe der Zeit entwickelt hat, soll es klein und erweiterbar sein.
Erweiterbarkeit und eingebettete Systeme
Da Wayland einen minimalen Kern hat und leicht erweiterbar ist, ist es ein ideales Werkzeug für die Entwicklung eingebetteter Linux-Plattformen.
Desktop-ähnliche Fenstersystemfunktionen sind zum Beispiel nicht Teil des Kernprotokolls. Stattdessen verfügt Wayland über eine spezielle Kategorie von Protokollerweiterungen, die als "Shells" bezeichnet werden und dem Client eine Möglichkeit bieten, seine Oberflächen zu verwalten. Desktop-ähnliche Funktionen werden über eine Shell namens XDG Shell bereitgestellt. Für andere Arten von Systemen kann eine spezialisiertere (und vielleicht restriktivere) "Shell" verwendet werden. Für die Erstellung von In-Vehicle Infotainment -Systemen könnte beispielsweise die IVI Shell vorzuziehen sein.
Der Wayland-Server sendet eine Liste seiner unterstützten Protokolle (oder "Schnittstellen"), wenn ein Client eine Verbindung herstellt, und der Client kann sich an die Protokolle binden, die er verwenden möchte. Dies kann jede der Standardschnittstellen sein, aber auch neue Erweiterungen lassen sich leicht hinzufügen. Wayland definiert ein leicht verständliches XML-Format für die Definition von Protokollen, und das Tool waylandscanner kann verwendet werden, um daraus C-Code zu erzeugen. (In Qt gibt es auch qtwaylandscanner, das zusätzlichen C++-Bindungscode generiert).
Nachdem sich ein Client an eine Schnittstelle gebunden hat, kann er "Anfragen" an den Server stellen und der Server kann "Ereignisse" an den Client senden. Die Anforderungen und Ereignisse sowie ihre Argumente werden in der XML-Datei definiert, die das Protokoll beschreibt.
Wenn Sie eine Plattform von Grund auf neu aufbauen und den Code sowohl des Servers als auch der Clients kontrollieren, ist das Hinzufügen von Erweiterungen ein einfacher und kontrollierter Weg, um Betriebssystemfunktionen hinzuzufügen.
Multiprozess oder Einzelprozess
Wenn Sie eine einfache eingebettete Plattform mit Qt erstellen, ist es eine durchaus praktikable Option, alle Teile der Benutzeroberfläche in einem einzigen Prozess laufen zu lassen. Wenn das System jedoch komplexer wird, sollten Sie stattdessen ein Multiprozesssystem in Betracht ziehen. An dieser Stelle kommt Wayland ins Spiel. Mit Qt können Sie zu jedem Zeitpunkt des Entwicklungsprozesses zwischen Einzelprozess und Multiprozess wechseln.
Vorteile von Multi-Process
Die folgenden Diagramme veranschaulichen den Unterschied zwischen Multiprozess- und Einzelprozesssystemen.
Multiprozess-Client-Architektur
Einzelprozess-Client-Architektur
Das Qt Wayland Compositor Modul ist ideal für die Erstellung des Display-Servers und Compositors in Multiprozess-Systemen unter Embedded Linux. Die Verwendung von Multiprozess hat die folgenden Vorteile:
| Stabilität | |
|---|---|
| Leichtere Wiederherstellung, wenn Clients hängen bleiben oder abstürzen | Wenn Sie eine komplexe Benutzeroberfläche haben, ist der Multiprozess nützlich, denn wenn ein Teil der Benutzeroberfläche abstürzt, hat dies keine Auswirkungen auf das gesamte System. Ebenso bleibt die Anzeige nicht stehen, selbst wenn ein Client abstürzt. Hinweis: Wenn Ihr Client gesetzlich verpflichtet ist, sicherheitskritische Informationen darzustellen, sollten Sie Qt Safe Renderer Overview verwenden. |
| Schutz vor möglichen Speicherlecks | Wenn in einem Multiprozesssystem ein Client ein Speicherleck hat und viel Speicher verbraucht, wird dieser Speicher wiederhergestellt, wenn dieser Client beendet wird. Im Gegensatz zu einem Einzelprozesssystem bleibt das Speicherleck bestehen, bis das gesamte System neu gestartet wird. |
| Sicherheit |
|---|
| In einem Single-Process-System können alle Clients auf den Speicher der anderen zugreifen. So gibt es beispielsweise keine Isolierung für sensible Datenübertragungen; jede Codezeile muss gleichermaßen vertrauenswürdig sein. Diese Isolierung ist in Multiprozesssystemen von vornherein gegeben. |
| Leistung |
|---|
| Wenn Sie eine CPU mit mehreren Kernen haben, kann ein Multiprozesssystem dazu beitragen, die Last gleichmäßig auf die verschiedenen Kerne zu verteilen und so Ihre CPU effizienter zu nutzen. |
| Interoperabilität |
|---|
| Sie können in einem Multiprozess-System mit Nicht-Qt-Clients zusammenarbeiten, solange Ihre Clients Wayland oder X11 verstehen. Wenn Sie z. B. gstreamer für Video verwenden oder eine Navigationsanwendung nutzen möchten, die mit einem anderen UI-Toolkit erstellt wurde, können Sie diese Clients neben Ihren anderen Qt-basierten Clients ausführen. |
Nachteile von Multi-Process
Beim Wechsel von Single-Process zu Multi-Process ist es wichtig, sich der folgenden Kompromisse bewusst zu sein:
- Erhöhter Videospeicherverbrauch
- Erhöhter Verbrauch an Hauptspeicher
- Wiederholte Speicherung von grafischen Ressourcen
- Eingabe-Latenzzeit
| Erhöhter Verbrauch an Videospeicher |
|---|
| Dies kann eine Einschränkung für eingebettete Geräte darstellen. Bei mehreren Prozessen muss jeder Client seinen eigenen Grafikpuffer haben, den er an den Compositor sendet. Folglich wird mehr Videospeicher verbraucht als im Fall eines einzelnen Prozesses, bei dem alles auf einmal gezeichnet wird und die verschiedenen Teile nicht in Zwischenpuffern gespeichert werden müssen. |
| Erhöhter Hauptspeicherverbrauch |
|---|
| Abgesehen von einem gewissen zusätzlichen Overhead auf Betriebssystemebene kann die Ausführung mehrerer Clients auch mehr Hauptspeicher beanspruchen, da einige Teile pro Client einmal dupliziert werden müssen. Wenn Sie z. B. QML ausführen, benötigt jeder Client eine eigene QML-Engine. Wenn Sie also einen einzigen Client ausführen, der Qt Quick Controls verwendet, wird dieser nur einmal geladen. Wenn Sie diesen Client dann in mehrere Clients aufteilen, müssen Sie Qt Quick Controls mehrfach laden, was zu höheren Startkosten für die Initialisierung Ihrer Clients führt. |
| Wiederholte Speicherung von grafischen Ressourcen |
|---|
| Wenn Sie in einem Einzelprozesssystem an vielen Stellen dieselben Texturen, Hintergründe oder Symbole verwenden, werden diese Bilder nur einmal gespeichert. Wenn Sie diese Bilder dagegen in einem Multiprozesssystem verwenden, müssen Sie sie mehrfach speichern. In diesem Fall besteht eine Lösung darin, grafische Ressourcen zwischen Clients zu teilen. Qt erlaubt bereits die gemeinsame Nutzung von Bildressourcen im Hauptspeicher über Prozesse hinweg, ohne Wayland einzubeziehen. Die gemeinsame Nutzung von GPU-Texturen zwischen Prozessen erfordert dagegen kompliziertere Lösungen. Mit Qt können solche Lösungen als Wayland-Erweiterungsprotokolle entwickelt werden, zum Beispiel mit QQuickImageProvider. |
| Eingabe-zu-Photonen-Latenz |
|---|
| Auf einem Einzelprozesssystem greift die Anwendung direkt auf den Hauptbildpuffer zu. Dies bedeutet, dass die Latenzzeit zwischen Eingabeereignissen und deren Wiedergabe auf dem Bildschirm in einem solchen System minimiert werden kann. Auf einem Multiprozesssystem muss der Anwendungsinhalt dreifach gepuffert werden, um sicherzustellen, dass der Client nicht in die Puffer zeichnet, während sie gleichzeitig vom Server gelesen werden, da dies zu Tearing führen würde. Dies bedeutet, dass es in einem Multiprozess-System eine implizite Latenz gibt. |
Warum Wayland anstelle von X11 oder benutzerdefinierten Lösungen verwenden?
Wie bereits beschrieben, ist X11 für typische Systemkonfigurationen heutzutage nicht optimal geeignet. Es ist recht groß und komplex und lässt sich nur unzureichend anpassen. In der Tat ist es schwierig, einen Client mit X11 flüssig zu betreiben und 60 fps ohne Tearing zu erreichen. Wayland dagegen ist einfacher zu implementieren, hat eine bessere Leistung und enthält alle notwendigen Teile, um auf moderner Grafikhardware effizient zu laufen. Für eingebettete Multiprozess-Systeme unter Linux ist Wayland der Standard.
Wenn Sie jedoch mit alter Hardware oder Legacy-Anwendungen arbeiten, ist Wayland möglicherweise keine gute Wahl. Das Wayland-Protokoll wurde im Hinblick auf Sicherheit und Isolierung entwickelt und ist streng/konservativ in Bezug auf die Informationen und Funktionen, die den Clients zur Verfügung stehen. Dies führt zwar zu einer saubereren und sichereren Schnittstelle, aber einige Funktionen, die von älteren Anwendungen erwartet werden, sind auf Wayland möglicherweise nicht mehr verfügbar.
Insbesondere gibt es drei häufige Anwendungsfälle, in denen Wayland nicht die beste Option ist:
- Die Hardware oder Plattform ist alt und unterstützt nur X11; in diesem Fall haben Sie keine Wahl.
- Sie müssen ältere Anwendungen unterstützen, die auf Funktionen angewiesen sind, die im Wayland-Protokoll aus Gründen der Sicherheit und Einfachheit nicht vorhanden sind.
- Sie müssen Legacy-Anwendungen unterstützen, die ein UI-Toolkit verwenden, das auf Wayland überhaupt nicht läuft. In einigen Fällen können Sie dies umgehen, indem Sie diese Anwendungen stattdessen auf XWayland laufen lassen.
Als X11 noch sehr populär war, schrieben Entwickler ihre eigenen Lösungen, um X11-Probleme zu umgehen. Ältere Qt-Versionen verfügten über das Qt Windowing System (QWS), das heute nicht mehr weiterentwickelt wird. Heute werden die meisten dieser Anwendungsfälle von Wayland abgedeckt, und benutzerdefinierte Lösungen sind immer weniger verbreitet.
Was Qt Wayland bietet
Für Clients
Qt-Clients können auf jedem Wayland Compositor laufen, einschließlich Weston, dem Referenz-Compositor, der im Rahmen des Wayland-Projekts entwickelt wurde.
Jedes Qt-Programm kann als Wayland Client (als Teil eines Multiprozess-Systems) oder als eigenständiger Client (Einzelprozess) laufen. Dies wird beim Starten festgelegt, wobei Sie zwischen den verschiedenen Backends wählen können. Während des Entwicklungsprozesses können Sie den Client zunächst auf dem Desktop entwickeln und ihn dann später auf der Zielhardware testen. Sie müssen Ihre Clients nicht immer auf der eigentlichen Zielhardware laufen lassen.
Single-Process-Client-Entwicklung
Wenn Sie auf einem Linux-Rechner entwickeln, können Sie den Compositor auch in einem Fenster auf Ihrem Entwicklungsrechner ausführen. Dadurch können Sie Clients in einer Umgebung ausführen, die dem Zielgerät sehr ähnlich ist. Ohne den Client neu zu erstellen, können Sie ihn auch mit -platform wayland innerhalb des Compositors ausführen. Wenn Sie -platform xcb (für X11) verwenden, können Sie den Client auf dem Desktop ausführen. Mit anderen Worten: Sie können mit der Entwicklung Ihrer Clients beginnen, bevor der Compositor einsatzbereit ist.
Für Server
Der Server oder Compositor stellt eine Verbindung zum Bildschirm her und zeigt die Inhalte der einzelnen Clients auf dem Bildschirm an. Der Compositor verarbeitet Eingaben und sendet Eingabeereignisse an den entsprechenden Client. Im Gegenzug stellt jeder Client eine Verbindung zum Compositor her und sendet den Inhalt seiner Fenster. Die Entscheidung liegt beim Compositor:
- Wie und wo der Inhalt angezeigt werden soll
- Welche Inhalte angezeigt werden sollen
- Was mit den verschiedenen Client-Grafikpuffern geschehen soll
Das bedeutet, dass es dem Compositor überlassen bleibt, zu entscheiden, was ein Multiprozess-System ist. Die Clients könnten zum Beispiel Teil einer 3D-Szene mit Fenstern an den Wänden sein, auf einem VR-System, auf einer Kugel abgebildet usw.
Die Qt Wayland Compositor ist eine API zum Erstellen eines eigenen Compositors. Sie gibt Ihnen die volle Freiheit, eine benutzerdefinierte Compositor-Benutzeroberfläche zu erstellen und die Fenster der verschiedenen Clients zu verwalten. Sie können sowohl Qt Quick als auch QML mit der Qt Wayland Compositor kombinieren, um beeindruckende, phantasievolle UIs zu erstellen. Für weitere Informationen siehe Qt Wayland Compositor.
Qt bietet auch leistungsstarke und benutzerfreundliche APIs, um Wayland-Erweiterungen zu implementieren und sie von QML oder C++ aus zu verwenden.
Verwandte Inhalte
© 2025 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.
