Wayland und Qt

Wayland wurde als Alternative zu X11 unter Linux entwickelt. Sein Hauptzweck besteht darin, zu steuern, wie die Inhalte von Anwendungen gemeinsam auf einem gemeinsamen Bildschirm dargestellt werden und wie ein Benutzer mit mehreren Anwendungen interagieren kann, die sich dieselben Eingabegeräte teilen.

Diese Rolle in einem Betriebssystem wird oft als Display-Server bezeichnet. Der Wayland-Display-Server wird manchmal auch als Compositor oder Fenstermanager bezeichnet, was sich auf bestimmte Aufgaben bezieht, die er im Rahmen seiner Funktion ausführt.

Im Folgenden geben wir eine kurze Einführung in Wayland und seine Rolle in Qt. Weitere Details und Hintergrundinformationen zu Wayland selbst finden Sie in der offiziellen Dokumentation.

Was ist ein Display-Server?

Der Display-Server ist der Teil des Betriebssystems, der den Bildschirmbereich und andere gemeinsam genutzte Ressourcen verwaltet. Auf einem typischen Desktop-System laufen möglicherweise viele unabhängige Anwendungen gleichzeitig, von denen jede erwartet, Grafiken auf dem Bildschirm darstellen und Eingaben empfangen zu können.

Der Display-Server fungiert als Schnittstelle zwischen der Anwendung und gemeinsam genutzten Ressourcen wie dem Bildschirm und Eingabegeräten. Ein typischer Display-Server auf einem Desktop-System ordnet Anwendungsinhalte in separate rechteckige „Fenster“ ein, die vom Benutzer verschoben und in ihrer Größe angepasst werden können. Der Display-Server stellt sicher, dass die Anwendungsinhalte an der richtigen Position auf dem Bildschirm angezeigt werden, dass das aktive Fenster Eingaben von der Tastatur empfängt, dass sich überlappende Fenster in der richtigen Reihenfolge gezeichnet werden und so weiter.

Auf anderen Systemtypen kann der Anzeigeserver restriktiver sein. Handelt es sich bei dem Bildschirm beispielsweise um ein Armaturenbrett in einem Auto oder das Bedienfeld eines Gabelstaplers, ist das Verschieben und Ändern der Größe von Fenstern möglicherweise nicht erwünscht. Stattdessen kann jede Anwendung in einem vordefinierten Bereich des Bildschirms fixiert sein und Eingaben von vorab zugewiesenen Geräten empfangen.

So oder so: Solange mehrere isolierte Prozesse um dieselben Ressourcen konkurrieren, ist ein Anzeigeserver nützlich.

Die Rolle von Wayland

Der Name „Wayland“ kann sich auf mehrere miteinander verbundene Begriffe 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 Interprozesskommunikation, die als Grundlage für die Implementierung der genannten Protokolle dient.
• Eine XML-basierte Sprache zur Erweiterung des Protokolls sowie ein Werkzeug zur Generierung 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-Display-Server ausgeführt werden, indem das QPA-Plugin „wayland“ ausgewählt wird (auf bestimmten Systemen ist dies die Standardeinstellung). Dies geschieht mithilfe der Option „ -qpa wayland “. Darüber hinaus kann das Qt Wayland Compositor Modul zur Entwicklung des Display-Servers selbst verwendet werden.

Qt verfügt zudem über Komfortfunktionen, mit denen sich die Wayland-Protokolle auf einfache Weise um neue Schnittstellen erweitern lassen.

Wayland und andere Technologien

Auf dem Linux-Desktop ist Wayland eine Alternative zu X11 und den dazugehörigen Erweiterungen. Im Kern handelt es sich um einen Compositing-Display-Server, und der Begriff „Compositor“ wird häufig verwendet, um den Wayland-Server zu beschreiben. Das bedeutet, dass Clients Inhalte in einen Off-Screen-Puffer rendern, der später mit den Inhalten anderer Clients auf dem Bildschirm „zusammengesetzt“ wird, wodurch Fenstereffekte wie Schlagschatten, Transparenz, Hintergrundunschärfe und so weiter ermöglicht werden.

Ein wichtiges Designprinzip der ursprünglichen X11-Protokolle besteht darin, dass der Display-Server auf einem Thin-Terminal mit lediglich einem Bildschirm und Eingabegeräten laufen kann. Seine Clients würden dann auf entfernten Systemen mit höherer Rechenleistung laufen und über eine Netzwerkverbindung mit dem Server kommunizieren.

Im Gegensatz dazu basiert Wayland auf der Erkenntnis, dass in modernen Konfigurationen der Client und der Display-Server in der Regel auf derselben Hardware laufen. Verteiltes Rechnen, Remote-Speicher und Remote-Desktop-Funktionen werden üblicherweise über andere Mechanismen abgewickelt. Die Einbindung dieses Ansatzes in das Protokoll ermöglicht die gemeinsame Nutzung des Grafikspeichers durch Client und Server: Wenn der Compositor Client-Inhalte auf dem Bildschirm anzeigt, kann er diese 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 des „ EGL “ bereitgestellt, die als „ EXT_platform_wayland “ bezeichnet wird.

X11 wurde um Funktionen wie Compositing und Direct Rendering erweitert, doch Wayland wurde von Grund auf für diesen Anwendungsfall konzipiert. Es zielt zudem darauf ab, kompakt und erweiterbar zu sein – im Gegensatz zu der Komplexität, die sich im Laufe der Zeit bei X11 entwickelt hat.

Erweiterbarkeit und eingebettete Systeme

Da Wayland über einen minimalen Kern verfügt und leicht erweiterbar ist, eignet es sich ideal für den Aufbau eingebetteter Linux-Plattformen.

Funktionen eines Fenstersystems im Desktop-Stil sind beispielsweise nicht Teil des Kernprotokolls. Stattdessen verfügt Wayland über eine spezielle Kategorie von Protokollerweiterungen, sogenannte „Shells“, die es dem Client ermöglichen, seine Oberflächen zu verwalten. Funktionen im Desktop-Stil werden über eine Shell namens „ XDG Shell “ bereitgestellt. Für andere Systemtypen kann eine spezialisiertere (und möglicherweise restriktivere) „Shell“ verwendet werden. Bei der Entwicklung von „ In-Vehicle Infotainment “-Systemen könnte beispielsweise die „ IVI Shell “ vorzuziehen sein.

Der Wayland-Server sendet eine Liste der von ihm unterstützten Protokolle (oder „Schnittstellen“) aus, wenn ein Client eine Verbindung herstellt, und der Client kann sich an die Schnittstellen binden, die er nutzen möchte. Dabei kann es sich um beliebige Standardschnittstellen handeln, aber auch neue Erweiterungen lassen sich leicht hinzufügen. Wayland definiert ein leicht verständliches XML-Format zur Definition von Protokollen, und mit dem Tool „ waylandscanner “ lässt sich daraus C-Code generieren. (In Qt steht zudem „ qtwaylandscanner “ zur Verfügung, das zusätzlichen C++-Bindungscode generiert.)

Nachdem ein Client eine Verbindung zu einer Schnittstelle hergestellt hat, kann er „Anfragen“ an den Server stellen, und der Server kann „Ereignisse“ an den Client senden. Die Anfragen und Ereignisse sowie deren Argumente sind in der XML-Datei definiert, die das Protokoll beschreibt.

Wenn man eine Plattform von Grund auf neu aufbaut und sowohl den Server- als auch den Client-Code selbst steuert, ist das Hinzufügen von Erweiterungen eine einfache und kontrollierte Möglichkeit, Betriebssystemfunktionen zu ergänzen.

Mehrprozess- oder Einprozess-Betrieb

Beim Aufbau einer einfachen eingebetteten Plattform mit Qt ist es durchaus eine praktikable Option, alle Teile der Benutzeroberfläche in einem einzigen Prozess laufen zu lassen. Wenn das System jedoch komplexer wird, sollten Sie stattdessen ein Mehrprozesssystem in Betracht ziehen. Hier kommt Wayland ins Spiel. Mit Qt können Sie zu jedem Zeitpunkt Ihres Entwicklungsprozesses zwischen Ein- und Mehrprozessbetrieb wechseln.

Vorteile des Mehrprozess-Ansatzes

Die folgenden Diagramme veranschaulichen den Unterschied zwischen Mehrprozess- und Einprozess-Systemen.

Multi-Prozess-Client-Architektur

Ein-Prozess-Client-Architektur

Das Qt Wayland Compositor Modul eignet sich ideal für die Erstellung des Display-Servers und des Compositors in Multiprozess-Systemen unter Embedded-Linux. Die Verwendung eines Multiprozess-Ansatzes bietet folgende Vorteile:

• Stabilität
• Sicherheit
• Leistung
• Interoperabilität

Vor- und Nachteile eines Mehrprozesssystems

Beim Übergang von einem Ein-Prozess- zu einem Mehrprozess-System ist es wichtig, sich der folgenden Vor- und Nachteile bewusst zu sein:

• Erhöhter Videospeicherverbrauch
• Erhöhter Hauptspeicherverbrauch
• Wiederholtes Speichern von Grafikressourcen
• Eingabelatenz

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 umfangreich und komplex und lässt sich nur begrenzt anpassen. Tatsächlich ist es schwierig, einen Client mit X11 flüssig laufen zu lassen und 60 fps ohne Bildreißen zu erreichen. Wayland hingegen ist einfacher zu implementieren, bietet eine bessere Leistung und enthält alle notwendigen Komponenten, 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 unter Berücksichtigung von Sicherheit und Isolation entwickelt und ist streng bzw. konservativ hinsichtlich der Informationen und Funktionen, die Clients zur Verfügung stehen. Dies führt zwar zu einer übersichtlicheren und sichereren Schnittstelle, doch sind einige Funktionen, die Legacy-Anwendungen erwarten, unter Wayland möglicherweise nicht mehr verfügbar.

Insbesondere gibt es drei häufige Anwendungsfälle, in denen Wayland möglicherweise nicht die beste Wahl ist:

1. Die Hardware oder Plattform ist veraltet und unterstützt nur X11; in diesem Fall haben Sie keine andere Wahl.
2. Sie müssen ältere Anwendungen unterstützen, die auf Funktionen angewiesen sind, die im Wayland-Protokoll aus Sicherheits- und Vereinfachungsgründen fehlen.
3. Sie müssen ältere Anwendungen unterstützen, die ein UI-Toolkit verwenden, das unter Wayland überhaupt nicht läuft. In manchen Fällen können Sie dies möglicherweise umgehen, indem Sie diese Anwendungen stattdessen unter XWayland ausführen.

Als X11 noch sehr beliebt war, entwickelten Entwickler eigene Lösungen, um Probleme mit X11 zu umgehen. Ältere Qt-Versionen verfügten über das Qt Windowing System (QWS), das inzwischen eingestellt wurde. Heute werden die meisten dieser Anwendungsfälle von Wayland abgedeckt, und eigene Lösungen werden immer seltener.

Was Qt Wayland bietet

Für Clients
Qt-Clients können auf jedem Wayland-Compositor ausgeführt werden, einschließlich Weston, dem Referenz-Compositor, der im Rahmen des Wayland-Projekts entwickelt wurde.

Jedes Qt-Programm kann als Wayland-Client (als Teil eines Mehrprozess-Systems) oder als eigenständiger Client (Einzelprozess) ausgeführt werden. Dies wird beim Start 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 später auf der Zielhardware testen. Sie müssen Ihre Clients nicht ständig auf der eigentlichen Zielhardware ausführen.

Entwicklung von Ein-Prozess-Clients

Wenn Sie auf einem Linux-Rechner entwickeln, können Sie den Compositor auch in einem Fenster auf Ihrem Entwicklungsrechner ausführen. So können Sie Clients in einer Umgebung ausführen, die dem Zielgerät sehr ähnlich ist. Ohne den Client neu zu kompilieren, können Sie ihn auch mit „ -platform wayland “ ausführen, um ihn innerhalb des Compositors zu starten. Wenn Sie „ -platform xcb “ (für X11) verwenden, können Sie den Client auf dem Desktop ausführen. Mit anderen Worten: Sie können bereits mit der Entwicklung Ihrer Clients beginnen, bevor der Compositor einsatzbereit ist.

Für Server:
Der Server, auch Compositor genannt, 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. Es ist Aufgabe des Compositors, zu entscheiden:

• Wie und wo der Inhalt angezeigt werden soll
• Welche Inhalte angezeigt werden sollen
• Was mit den verschiedenen Grafikpuffern der Clients geschehen soll

Das bedeutet, dass es dem Compositor überlassen bleibt, zu entscheiden, was ein Multiprozess-System ist. Beispielsweise könnten die Clients Teil einer 3D-Szene mit Fenstern an den Wänden sein, auf einem VR-System, auf eine Kugel abgebildet und so weiter.

Die Qt Wayland Compositor ist eine API zum Erstellen eines eigenen Compositors. Sie bietet Ihnen volle Freiheit beim Erstellen einer benutzerdefinierten Compositor-Benutzeroberfläche und bei der Verwaltung der Fenster verschiedener Clients. Sie können sowohl „ Qt Quick “ als auch QML mit dem „ Qt Wayland Compositor “ kombinieren, um beeindruckende, kreative Benutzeroberflächen zu erstellen. Weitere Informationen finden Sie unter Qt Wayland Compositor.

Qt bietet außerdem leistungsstarke und benutzerfreundliche APIs zur Implementierung von Wayland-Erweiterungen und deren Nutzung aus QML oder C++ heraus.

Verwandte Inhalte

• QtWS17 – Qt Wayland Compositor: Erstellung einer Benutzeroberfläche mit mehreren Prozessen
• Qt Application Manager