Wayland (Protokoll)

Wayland ist ein Kommunikationsprotokoll , das die Kommunikation zwischen einem Display-Server und seinen Clients spezifiziert, sowie eine C- Bibliotheksimplementierung dieses Protokolls. ^{[ 10 ]} Ein Display-Server, der das Wayland-Protokoll verwendet, wird als Wayland-Compositor bezeichnet , da er zusätzlich die Funktion eines Compositing-Fenstermanagers übernimmt .

Wayland wird von einer Gruppe Freiwilliger unter der Leitung von Kristian Høgsberg als freies und quelloffenes Community-Projekt entwickelt. Ziel ist es, das X Window System durch ein sicheres ^{[ 11 ] [ 12 ] [ 13 ] [ 14 ]} und einfacheres Fenstersystem für Linux und andere Unix-ähnliche Betriebssysteme zu ersetzen. ^{[ 10 ] [ 15 ]} Der Quellcode des Projekts wird unter den Bedingungen der MIT-Lizenz , einer freizügigen Lizenz für freie Software , veröffentlicht . ^{[ 15 ] [ 7 ]} Das Wayland-Projekt entwickelt außerdem eine Implementierung eines Wayland-Compositors namens Weston . ^{[ 10 ]}

1. Das evdev- Modul des Linux-Kernels empfängt ein Ereignis und sendet es an den Wayland-Compositor .
2. Der Wayland-Compositor durchsucht seinen Szenengraphen , um das Fenster zu bestimmen, das das Ereignis empfangen soll. Der Szenengraph entspricht dem Bildschirminhalt, und der Wayland-Compositor berücksichtigt die Transformationen, die er möglicherweise auf die Elemente im Szenengraphen angewendet hat. So kann der Wayland-Compositor das richtige Fenster auswählen und die Bildschirmkoordinaten mithilfe der inversen Transformationen in lokale Fensterkoordinaten umrechnen. Die auf ein Fenster anwendbaren Transformationsarten sind lediglich durch die Möglichkeiten des Compositors beschränkt, sofern dieser die inverse Transformation für die Eingabeereignisse berechnen kann.
3. Wie im Fall von X aktualisiert der Client die Benutzeroberfläche, sobald er das Ereignis empfängt. Im Fall von Wayland erfolgt das Rendering jedoch clientseitig über EGL , und der Client sendet lediglich eine Anfrage an den Compositor, um den aktualisierten Bereich anzuzeigen.
4. Der Wayland-Compositor sammelt Schadensanforderungen von seinen Clients und stellt den Bildschirm anschließend neu zusammen. Der Compositor kann dann direkt einen ioctl-Befehl ausführen , um einen Seitenwechsel mit KMS zu planen .

Das Wayland Display Server-Projekt wurde 2008 vom Red Hat- Entwickler Kristian Høgsberg ins Leben gerufen. ^{[ 16 ]}

Seit etwa 2010 hat sich die Desktop-Grafik unter Linux grundlegend verändert: von einer Vielzahl von Rendering -Schnittstellen, die alle mit dem zentralen X-Server kommunizierten, hin zu einem System, das den Linux-Kernel und seine Komponenten (z. B. Direct Rendering Infrastructure (DRI), Direct Rendering Manager (DRM)) in den Mittelpunkt rückt, während Fenstersysteme wie X und Wayland eher eine Nebenrolle spielen. Dadurch soll ein deutlich vereinfachtes Grafiksystem entstehen, das mehr Flexibilität und eine bessere Leistung bietet. ^{[ 17 ]}

Høgsberg hätte wie viele andere Projekte in letzter Zeit eine Erweiterung für X hinzufügen können , zog es aber vor, X aus dem Hotpath zwischen Clients und Hardware herauszunehmen. Gründe dafür werden in den FAQ des Projekts erläutert : ^{[ 15 ]}

Der Unterschied besteht darin, dass ein Großteil der Infrastruktur vom X-Server in den Kernel (Speicherverwaltung, Befehlsplanung, Moduseinstellung ) oder in Bibliotheken ( cairo , pixman, freetype , fontconfig , pango usw.) verlagert wurde. Dadurch muss nur noch sehr wenig in einem zentralen Serverprozess ausgeführt werden. … [Ein X-Server verfügt über] eine enorme Menge an Funktionen, die man unterstützen muss, um das X-Protokoll zu verwenden, die aber praktisch niemand nutzt. … Dazu gehören Codetabellen, Glyphenrasterisierung und -caching, XLFDs (tatsächlich XLFDs!) und die gesamte Rendering-API, mit der man gestrichelte Linien, Polygone, weite Bögen und viele weitere Grafikprimitive im Stil der 1980er-Jahre zeichnen kann. Vieles konnten wir durch Erweiterungen wie XRandR , XRender und COMPOSITE modern halten . … Mit Wayland können wir den X-Server und seine gesamte Legacy-Technologie in einen optionalen Codepfad auslagern. Bis wir an einen Punkt gelangen, an dem der X-Server eine Kompatibilitätsoption und nicht mehr das Kern-Renderingsystem darstellt, wird es eine Weile dauern, aber wir werden diesen Punkt nie erreichen, wenn wir nicht dafür planen.

Das Wayland-Protokoll wird durch eine XML-Datei repräsentiert, die mit dem Wayland-Compiler ausgeliefert wird. Dieser kann die Datei wayland.xml in die entsprechenden C-Bibliotheken für Anwendungen und Compositor-Implementierungen kompilieren. Die offizielle Referenzimplementierung für einen Wayland-Compositor heißt Weston . Das Projekt entwickelt außerdem Versionen von GTK und Qt , die anstelle von X für Wayland rendern. Die meisten Anwendungen werden voraussichtlich ohne Änderungen Wayland-Unterstützung durch eine dieser Bibliotheken erhalten.

Die ersten Versionen von Wayland boten keine Netzwerktransparenz , obwohl Høgsberg 2010 darauf hinwies, dass diese möglich sei. ^{[ 18 ]} Ein Versuch im Rahmen des Google Summer of Code- Projekts 2011 scheiterte. ^{[ 19 ]} Adam Jackson hatte die Idee, Fernzugriff auf eine Wayland-Anwendung entweder durch „Pixel-Scraping“ (ähnlich wie bei VNC ) oder durch das Senden eines „Rendering-Befehlsstroms“ über das Netzwerk (wie bei RDP , SPICE oder X11 ) zu ermöglichen. ^{[ 20 ]} Anfang 2013 experimentierte Høgsberg mit Netzwerktransparenz mithilfe eines Wayland-Proxy-Servers, der komprimierte Bilder an den eigentlichen Compositor sendete. ^{[ 21 ] [ 22 ]} Im August 2017 implementierte GNOME erstmals einen solchen Pixel-Scraping-VNC-Server unter Wayland. ^{[ 23 ]} In modernen Wayland-Compositors wird die Netzwerktransparenz in einer xdg-desktop-portal-Implementierung gehandhabt , die das RemoteDesktop-Portal implementiert.

Viele Wayland-Compositors beinhalten auch eine xdg-desktop-portal-Implementierung für gängige Aufgaben wie die native Dateiauswahl für native Anwendungen und Sandboxes wie Flatpak ( xdg-desktop-portal-gtk wird häufig als Fallback-Dateiauswahl verwendet), Bildschirmaufzeichnung, Netzwerktransparenz, Screenshots, Farbauswahl und andere Aufgaben, die andernfalls als sicherheitsrelevant und benutzerinteraktionsbedürftig gelten könnten. xdg-desktop-portal ist nicht Flatpak- oder Wayland-spezifisch und kann mit alternativen Paketverwaltungssystemen und Fenstersystemen verwendet werden.

In der Wayland-Protokollarchitektur kommunizieren Client und Compositor über das Wayland-Protokoll unter Verwendung der Referenzimplementierungsbibliotheken.

Das Wayland-Protokoll folgt einem Client-Server-Modell, bei dem die Clients die grafischen Anwendungen sind, die die Anzeige von Pixelpuffern auf dem Bildschirm anfordern, und der Server (Compositor) der Dienstanbieter ist, der die Anzeige dieser Puffer steuert.

Die Wayland-Referenzimplementierung wurde als zweischichtiges Protokoll konzipiert: ^{[ 24 ]}

• Eine Low-Level-Schicht oder ein Wire-Protokoll , das die Interprozesskommunikation zwischen den beiden beteiligten Prozessen – Client und Compositor – sowie das Marshalling der ausgetauschten Daten übernimmt. Diese Schicht ist nachrichtenbasiert und wird üblicherweise mithilfe der Kernel-IPC-Dienste implementiert, insbesondere Unix-Domain-Sockets im Fall von Linux und anderen Unix-ähnlichen Betriebssystemen. ^{[ 25 ]}
• Eine darauf aufbauende, höhere Schicht verarbeitet die Informationen, die Client und Compositor austauschen müssen, um die grundlegenden Funktionen eines Fenstersystems zu implementieren . Diese Schicht ist als „asynchrones objektorientiertes Protokoll“ implementiert. ^{[ 26 ]}

Während die Low-Level-Schicht manuell in C geschrieben wurde , wird die High-Level-Schicht automatisch aus einer in XML- Format gespeicherten Beschreibung der Protokollelemente generiert . ^{[ 27 ]} Jedes Mal, wenn sich die Protokollbeschreibung in dieser XML-Datei ändert, kann der C-Quellcode, der das Protokoll implementiert, neu generiert werden, um die Änderungen zu übernehmen. Dies ermöglicht ein sehr flexibles, erweiterbares und fehlerfreies Protokoll.

Die Referenzimplementierung des Wayland-Protokolls ist in zwei Bibliotheken aufgeteilt : eine Bibliothek für Wayland-Clients namens libwayland-clientund eine Bibliothek für Wayland-Compositors namens libwayland-server. ^{[ 28 ]}

Das Wayland-Protokoll wird als „asynchrones objektorientiertes Protokoll“ beschrieben. ^{[ 26 ]} Objektorientiert bedeutet, dass die vom Compositor angebotenen Dienste als eine Reihe von Objekten dargestellt werden , die auf demselben Compositor existieren. Jedes Objekt implementiert eine Schnittstelle mit einem Namen, mehreren Methoden (Anfragen ) sowie zugehörigen Ereignissen . Jede Anfrage und jedes Ereignis hat null oder mehr Argumente, die jeweils einen Namen und einen Datentyp besitzen . Das Protokoll ist asynchron, da Anfragen nicht auf synchronisierte Antworten oder Bestätigungen (ACKs) warten müssen . Dadurch werden Roundtrip-Zeiten vermieden und eine höhere Leistung erzielt.

Wayland-Clients können eine Anfrage (einen Methodenaufruf) an ein Objekt senden, sofern dessen Schnittstelle diese Anfrage unterstützt. Der Client muss zudem die erforderlichen Daten für die Argumente dieser Anfrage bereitstellen. Auf diese Weise fordern Clients Dienste vom Compositor an. Der Compositor wiederum sendet Informationen an den Client zurück, indem er das Objekt veranlasst, Ereignisse (möglicherweise ebenfalls mit Argumenten) auszulösen. Diese Ereignisse können vom Compositor als Antwort auf eine bestimmte Anfrage oder asynchron, abhängig vom Auftreten interner Ereignisse (z. B. eines Eingabegeräts) oder Zustandsänderungen, ausgelöst werden. Auch Fehlerzustände werden vom Compositor als Ereignisse signalisiert. ^{[ 26 ]}

Damit ein Client eine Anfrage an ein Objekt senden kann, muss er dem Server zunächst die ID-Nummer mitteilen, die zur Identifizierung dieses Objekts verwendet wird. ^{[ 26 ]} Im Compositor gibt es zwei Arten von Objekten: globale und nicht-globale Objekte. Globale Objekte werden vom Compositor den Clients bei ihrer Erstellung (und auch bei ihrer Zerstörung) mitgeteilt, während nicht-globale Objekte üblicherweise von anderen, bereits existierenden Objekten im Rahmen ihrer Funktionalität erzeugt werden. ^{[ 29 ]}

Die Schnittstellen sowie ihre Anfragen und Ereignisse bilden den Kern des Wayland-Protokolls. Jede Protokollversion umfasst eine Reihe von Schnittstellen mit den dazugehörigen Anfragen und Ereignissen, die in jedem Wayland-Compositor erwartet werden. Optional kann ein Wayland-Compositor eigene Schnittstellen definieren und implementieren, die neue Anfragen und Ereignisse unterstützen und so die Funktionalität über das Kernprotokoll hinaus erweitern. ^{[ 30 ]} Um Änderungen am Protokoll zu vereinfachen, enthält jede Schnittstelle neben ihrem Namen ein Attribut mit der Versionsnummer. Dieses Attribut ermöglicht die Unterscheidung von Varianten derselben Schnittstelle. Jeder Wayland-Compositor stellt nicht nur die verfügbaren Schnittstellen, sondern auch die unterstützten Versionen dieser Schnittstellen bereit. ^{[ 31 ]}

Die Schnittstellen der aktuellen Wayland-Protokollversion sind in der Datei `protocol/wayland.xml` des Wayland-Quellcodes definiert. ^{[ 27 ]} Diese XML-Datei listet die vorhandenen Schnittstellen der aktuellen Version zusammen mit ihren Anfragen, Ereignissen und weiteren Attributen auf. Dieser Satz an Schnittstellen stellt die Mindestanforderung für die Implementierung durch jeden Wayland-Compositor dar.

Zu den grundlegendsten Schnittstellen des Wayland-Protokolls gehören: ^{[ 30 ]}

wl_display

Das globale Kernobjekt, ein spezielles Objekt zur Kapselung des Wayland-Protokolls selbst.

wl_registry

Das globale Registrierungsobjekt, in dem der Compositor alle globalen Objekte registriert, die allen Clients zur Verfügung stehen sollen.

wl_compositor

Ein Objekt, das den Compositor repräsentiert und für die Kombination der verschiedenen Oberflächen zu einem Ergebnis zuständig ist.

wl_surface

Ein Objekt, das einen rechteckigen Bereich auf dem Bildschirm darstellt und durch Position, Größe und Pixelinhalt definiert ist.

wl_buffer

Ein Objekt, das, wenn es an ein wl_surface- Objekt angehängt wird, seinen anzeigbaren Inhalt bereitstellt.

wl_output

ein Objekt, das den anzeigbaren Bereich eines Bildschirms darstellt

wl_pointer , wl_keyboard , wl_touch

Objekte, die verschiedene Eingabegeräte wie Zeiger oder Tastaturen darstellen

wl_seat

ein Objekt, das einen Sitzplatz (eine Gruppe von Eingabe-/Ausgabegeräten) in Mehrsitzkonfigurationen repräsentiert

Eine typische Wayland-Client-Sitzung beginnt mit dem Aufbau einer Verbindung zum Compositor mithilfe des `wl_display`- Objekts. Dieses spezielle lokale Objekt repräsentiert die Verbindung und befindet sich nicht auf dem Server. Über seine Schnittstelle kann der Client das globale `wl_registry`- Objekt vom Compositor anfordern, in dem alle globalen Objektnamen gespeichert sind, und die für ihn relevanten Objekte binden. Üblicherweise bindet der Client mindestens ein ` wl_compositor`- Objekt, von dem er ein oder mehrere `wl_surface`- Objekte anfordert, um die Anwendungsausgabe auf dem Bildschirm anzuzeigen. ^{[ 29 ]}

Ein Wayland-Compositor kann eigene zusätzliche Schnittstellen definieren und exportieren. ^{[ 30 ]} Diese Funktion dient dazu, das Protokoll über die von den Kernschnittstellen bereitgestellte Basisfunktionalität hinaus zu erweitern und hat sich als Standardmethode für die Implementierung von Wayland-Protokollerweiterungen etabliert. Bestimmte Compositors können benutzerdefinierte Schnittstellen hinzufügen, um spezialisierte oder einzigartige Funktionen bereitzustellen. Der Wayland-Referenz-Compositor Weston nutzte diese, um neue experimentelle Schnittstellen als Testumgebung für neue Konzepte und Ideen zu implementieren, von denen einige später Teil des Kernprotokolls wurden (wie beispielsweise die in Wayland 1.4 hinzugefügte Schnittstelle `wl_subsurface` ^{[ 32 ]} ).

Das XDG-Shell-Protokoll (siehe freedesktop.org für XDG) ist eine erweiterte Methode zur Oberflächenverwaltung unter Wayland-Compositors (nicht nur Weston). Die traditionelle Methode zur Manipulation von Oberflächen (Maximieren, Minimieren, Vollbildmodus usw.) besteht in der Verwendung von wl_shell_*()Funktionen, die Teil des Wayland-Kernprotokolls sind und sich in libwayland-client befinden , aber mittlerweile als veraltet gelten . Eine Implementierung des xdg-Shell-Protokolls hingegen soll vom Wayland-Compositor bereitgestellt werden. Daher finden Sie die Headerdatei <xdg-shell-client-protocol.h> im Weston-Quellcode.

xdg_shell ist ein Protokoll, das wl_shell langfristig ersetzen soll, aber nicht Teil des Wayland-Kernprotokolls sein wird. Es beginnt als instabile API, die zunächst als Entwicklungsumgebung dienen soll. Sobald die von verschiedenen Desktop-Shells benötigten Funktionen definiert sind, kann es stabilisiert werden. Es bietet im Wesentlichen zwei neue Schnittstellen: xdg_surface und xdg_popup. Die xdg_surface-Schnittstelle implementiert ein Desktop-ähnliches Fenster, das verschoben, in der Größe verändert, maximiert usw. werden kann; sie ermöglicht die Erstellung von Kind-/Elternbeziehungen. Die xdg_popup-Schnittstelle implementiert ein Desktop-ähnliches Popup/Menü; ein xdg_popup ist für eine andere Oberfläche immer transient und verfügt über eine implizite Greiffunktion. ^{[ 33 ]}

IVI-Shell ist eine Erweiterung des Wayland-Kernprotokolls, die auf Infotainmentsysteme im Fahrzeug (IVI) abzielt. ^{[ 34 ]}

Wayland Compositor und seine Clients verwenden EGL , um direkt in den Framebuffer zu zeichnen ; X.Org Server mit XWayland und Glamor .

Das Wayland-Protokoll enthält keine Rendering-API. ^{[ 35 ] [ 15 ] [ 36 ] [ 37 ] : 2} Stattdessen verwendet Wayland ein direktes Rendering- Modell, bei dem der Client den Fensterinhalt in einen mit dem Compositor gemeinsam nutzbaren Puffer rendern muss. ^{[ 38 ]} Hierfür kann der Client das gesamte Rendering selbst durchführen, eine Rendering-Bibliothek wie Cairo oder OpenGL verwenden oder auf die Rendering-Engine von High-Level-Widget-Bibliotheken mit Wayland-Unterstützung wie Qt oder GTK zurückgreifen . Optional kann der Client auch weitere spezialisierte Bibliotheken für spezifische Aufgaben nutzen, beispielsweise FreeType für das Rendern von Schriftarten .

Der resultierende Puffer mit dem gerenderten Fensterinhalt wird in einem `wl_buffer`- Objekt gespeichert. Der interne Typ dieses Objekts ist implementierungsabhängig. Die einzige Voraussetzung ist, dass die Inhaltsdaten zwischen Client und Compositor gemeinsam genutzt werden können. Verwendet der Client einen Software-Renderer (CPU) und wird das Ergebnis im Systemspeicher abgelegt , können Client und Compositor gemeinsam genutzten Speicher verwenden , um die Pufferkommunikation ohne zusätzliche Kopien zu realisieren. Das Wayland-Protokoll stellt diese Art von gemeinsam genutztem Speicherpuffer bereits nativ über die Schnittstellen `wl_shm` ^{[ 39 ]} und `wl_shm_pool` ^{[ 40 ]} bereit . Der Nachteil dieser Methode besteht darin, dass der Compositor möglicherweise zusätzliche Arbeit leisten muss (üblicherweise das Kopieren der gemeinsam genutzten Daten auf die GPU), um sie anzuzeigen, was zu einer geringeren Grafikleistung führt.

Im Normalfall rendert der Client direkt in einen Videospeicherpuffer mithilfe einer hardwarebeschleunigten API (GPU) wie OpenGL , OpenGL ES oder Vulkan . Client und Compositor können diesen GPU-Speicherpuffer über einen speziellen Handler gemeinsam nutzen. ^{[ 41 ]} Dadurch vermeidet der Compositor das zusätzliche Kopieren der Daten aus dem Hauptspeicherpuffer (Client-zu-Compositor-zu-GPU-Methode), was zu einer höheren Grafikleistung führt und daher bevorzugt wird. Der Compositor kann die Komposition der endgültigen Szene für die Anzeige weiter optimieren, indem er dieselbe Hardwarebeschleunigungs -API wie der API-Client verwendet.

Sobald das Rendering in einem gemeinsam genutzten Puffer abgeschlossen ist, weist der Wayland-Client den Compositor an, den gerenderten Inhalt des Puffers auf dem Bildschirm darzustellen. Dazu bindet der Client das Pufferobjekt, das den gerenderten Inhalt speichert, an das Oberflächenobjekt und sendet eine „Commit“-Anforderung an die Oberfläche, wodurch die Kontrolle über den Puffer an den Compositor übertragen wird. ^{[ 24 ]} Anschließend wartet der Client, bis der Compositor den Puffer freigibt (signalisiert durch ein Ereignis), falls er den Puffer für das Rendern eines weiteren Frames wiederverwenden möchte. Alternativ kann er einen anderen Puffer für das Rendern des neuen Frames verwenden und diesen nach Abschluss des Renderings an die Oberfläche binden und dessen Inhalt bestätigen. ^{[ 42 ] : 7} Das Rendering-Verfahren, einschließlich der Anzahl der verwendeten Puffer und deren Verwaltung, liegt vollständig in der Hand des Clients. ^{[ 42 ] : 7}

Zwischen Wayland und X bestehen mehrere Unterschiede hinsichtlich Leistung, Wartbarkeit des Codes und Sicherheit: ^{[ 43 ]}

Architektur

Der Kompositionsmanager ist in X eine separate Zusatzfunktion, während Wayland Display-Server und Compositor zu einer einzigen Funktion vereint. ^{[ 44 ] [ 36 ]} Außerdem integriert er einige Aufgaben des Fenstermanagers , der in X ein separater clientseitiger Prozess ist. ^{[ 45 ]}

Compositing

Compositing ist in X optional, in Wayland jedoch obligatorisch. In X ist Compositing „aktiv“, d. h., der Compositor muss alle Pixeldaten abrufen, was zu Latenz führt. In Wayland ist Compositing „passiv“, was bedeutet, dass der Compositor die Pixeldaten direkt von den Clients empfängt. ^{[ 46 ] : 8–11}

Rendering

Der X-Server selbst kann rendern, er kann aber auch angewiesen werden, ein vom Client gesendetes gerendertes Fenster anzuzeigen. Im Gegensatz dazu stellt Wayland keine API für das Rendering bereit, sondern delegiert diese Aufgaben (einschließlich des Renderns von Schriftarten, Widgets usw.) an die Clients. ^{[ 44 ] [ 36 ]} Fensterdekorationen werden clientseitig (z. B. durch ein Grafiktoolkit) oder serverseitig (durch den Compositor) mit dem optionalen xdg-decoration- Protokoll gerendert, sofern der Compositor diese Funktionalität implementiert. ^{[ 47 ]}

Sicherheit

Wayland isoliert die Ein- und Ausgabe jedes Fensters und gewährleistet so Vertraulichkeit, Integrität und Verfügbarkeit für beides. Dem ursprünglichen X-Design fehlten diese wichtigen Sicherheitsmerkmale ^{[ 12 ] [ 13 ] [ 14 ]} , obwohl einige Erweiterungen entwickelt wurden, um dies zu beheben ^{[ 48 ] [ 49 ] [ 50 ].} Da der Großteil des Codes auf dem Client ausgeführt wird, benötigt weniger Code Root- Rechte, was die Sicherheit erhöht ^{[ 12 ].} Allerdings erlauben mittlerweile mehrere gängige Linux-Distributionen den Betrieb des X-Servers ohne Root-Rechte ^{[ 51 ] [ 52 ] [ 53 ] [ 54 ] .}

Netzwerk

Das X Window System ist eine Architektur , die von Grund auf für den Betrieb über ein Netzwerk konzipiert wurde. Wayland selbst bietet keine Netzwerktransparenz ^{[ 15 ]} ; jedoch kann ein Compositor jedes beliebige Remote-Desktop-Protokoll implementieren, um die Remote-Anzeige zu ermöglichen. Darüber hinaus gibt es Forschung zu Wayland-Bildstreaming und -Komprimierung, die einen Remote-Framebuffer-Zugriff ähnlich wie bei VNC ermöglichen würden . ^{[ 22 ]}

XWayland ist ein X-Server , der als Wayland-Client ausgeführt wird und somit native X11-Clientanwendungen in einer Wayland-Compositor-Umgebung darstellen kann. ^{[ 55 ] [ 56 ]} Dies ähnelt der Funktionsweise von XQuartz , das X-Anwendungen im nativen Fenstersystem von macOS ausführt . Ziel von XWayland ist es, den Übergang vom X Window System zu Wayland-Umgebungen zu erleichtern und in der Zwischenzeit die Ausführung nicht portierter Anwendungen zu ermöglichen. XWayland wurde in X.Org Server Version 1.16 integriert. ^{[ 57 ]}

Widget-Toolkits wie Qt 5 und GTK 3 können ihr grafisches Backend zur Laufzeit umschalten ^{[ 58 ]} , sodass Benutzer beim Laden der Anwendung entscheiden können, ob sie unter X oder Wayland ausgeführt werden soll. Qt 5 bietet hierfür die -platformKommandozeilenoption ^{[ 59 ]} , während GTK 3 die Auswahl des gewünschten GDK -Backends über die GDK_BACKENDUnix-Umgebungsvariable ermöglicht ^{[ 58 ] [ 60 ]} .

Display-Server , die das Wayland-Display-Server-Protokoll implementieren, werden auch Wayland-Compositors genannt , da sie zusätzlich die Aufgabe eines Compositing-Fenstermanagers übernehmen .

Die Bibliothek wlroots ist eine modulare Wayland-Implementierung, die als Basis für verschiedene Compositor-Bibliotheken dient. ^{[ 61 ]}

Einige bemerkenswerte Wayland-Compositor-Programmierer sind:

• Weston  – eine Implementierung des Wayland-Entwicklungsteams. Weitere Informationen zu Weston finden Sie unten.
• Enlightenment bietet Wayland-Unterstützung seit Version 0.20 ^{[ 62 ].}
• KWin , der standardmäßige Wayland-Compositor von KDE Plasma ^{[ 63 ],} verwendet seit KDE Plasma 6.0 standardmäßig Wayland. In Plasma 6.4 wurde die X11-Sitzungsunterstützung von KWin in eine separate Codebasis ausgelagert. ^{[ 64 ]} In Plasma 6.8 wird KWin-X11 von KDE nicht mehr unterstützt .
• Mutter , der standardmäßige Wayland-Compositor von GNOME ^{[ 65 ],} deaktivierte die X11-Sitzung zur Kompilierzeit in GNOME 49. Der X11-Sitzungscode von Mutter wurde in GNOME 50 entfernt.
• labwc ist ein auf wlroots basierender, stapelbarer Wayland-Compositor, der von Openbox inspiriert wurde . Er ist als einfacher Compositor ohne Animationen für Systeme gedacht, die möglicherweise nicht leistungsstark genug sind, um Compositors mit Desktop-Animationen und -Effekten auszuführen. ^{[ 66 ]} Er wird als Standard-Compositor von Raspberry Pi OS verwendet . ^{[ 67 ]}
• Sway – ein Wayland-Compositor mit Tiling-Funktion, basierend auf wlroots; er ist ein direkter Ersatz für den i3 X11 Window Manager . ^{[ 68 ] [ 69 ] [ 70 ]}
• Hyprland  ist ein in C++ geschriebener Wayland-Compositor mit Tiling-Funktion . Zu den bemerkenswerten Merkmalen von Hyprland gehören dynamisches Tiling, Registerkartenfenster und ein benutzerdefinierter Renderer, der Fensteranimationen, abgerundete Ecken und Dual-Kawase-Blur für transparente Fenster ermöglicht. ^{[ 71 ] [ 72 ]}
• Woodland – ein auf wlroots basierender Window-Stacking-Compositor für Wayland, geschrieben in C, inspiriert von TinyWL und mit Fokus auf Einfachheit und Stabilität.
• niri – ein in Rust geschriebener Wayland-Compositor mit scrollbarem Tiling . ^{[ 73 ]}
• Wayfire ist ein auf wlroots basierender Stacking-Wayland-Compositor mit Desktop-Animationen und -Effekten, inspiriert von Compiz . ^{[ 74 ]}
• Phoc ist ein Wayland-Compositor für mobile Geräte wie das PinePhone , der die wlroots-Bibliothek verwendet. Er wird häufig zusammen mit der mobilen Shell Phosh eingesetzt . ^{[ 75 ]}
• River ist ein in Zig geschriebener, auf wlroots basierender Compositor . Er stellt ein eigenes Protokoll für die Fensterverwaltung bereit; er führt die Fensterverwaltung nicht selbst durch. ^{[ 76 ]}

Weston ist ein Wayland-Compositor, der zuvor vom Wayland-Projekt als Referenzimplementierung des Protokolls entwickelt wurde. ^{[ 77 ] [ 78 ]} Er ist in C geschrieben und unter der MIT-Lizenz veröffentlicht .

Weston unterstützt offiziell nur Linux, da es von Kernel-spezifischen Funktionen wie Kernel Mode-Setting (KMS), dem Graphics Execution Manager (GEM) und udev abhängig ist . Unter Linux erfolgt die Eingabe über evdev und die Pufferverwaltung über Generic Buffer Management (GBM). Ein Prototyp für FreeBSD wurde 2013 angekündigt. ^{[ 79 ]}

Der Compositor unterstützt High-bandwidth Digital Content Protection (HDCP) ^{[ 80 ]} und nutzt GEM zur gemeinsamen Nutzung von Puffern zwischen Anwendungen und dem Compositor. Er verfügt über eine Plug-in-Architektur mit „Shells“, die Elemente wie Docks und Panels bereitstellen. ^{[ 22 ]} Anwendungen sind für das Rendern ihrer eigenen Fensterdekorationen verantwortlich.

Weston unterstützt das Rendern über OpenGL ES ^{[ 81 ]} oder die Pixman -Bibliothek für Software-Rendering . ^{[ 82 ]} Der vollständige OpenGL-Stack wird vermieden, um das Einbinden von GLX und anderen Abhängigkeiten des X Window Systems zu verhindern . ^{[ 83 ]}

Eine Remote-Desktop-Schnittstelle für Weston wurde 2013 von einem Entwickler von RealVNC vorgeschlagen . ^{[ 84 ]}

Maynard ist eine grafische Shell und wurde als Plugin für Weston entwickelt, genau wie die GNOME Shell als Plugin für Mutter entwickelt wurde . ^{[ 85 ]}

Raspberry Pi Holdings veröffentlichte in Zusammenarbeit mit Collabora Maynard. ^{[ 86 ] [ 87 ]}

Der Weston-Code zur Handhabung von Eingabegeräten (Tastaturen, Zeiger, Touchscreens usw.) wurde in eine eigene separate Bibliothek namens libinput ausgelagert , deren Unterstützung erstmals in Weston 1.5 integriert wurde. ^{[ 88 ] [ 89 ]}

Libinput verwaltet Eingabegeräte für verschiedene Wayland-Compositors und stellt zudem einen generischen X.Org-Server -Eingabetreiber bereit. Ziel ist es, eine einheitliche Implementierung für mehrere Wayland-Compositors mit einer gemeinsamen Methode zur Verarbeitung von Eingabeereignissen zu schaffen und gleichzeitig den Bedarf an benutzerdefiniertem Eingabecode für die Compositors zu minimieren. Libinput bietet Geräteerkennung (über udev ), Geräteverwaltung, Verarbeitung von Eingabegeräteereignissen und Abstraktion. ^{[ 90 ] [ 91 ]}

Version 1.0 von libinput folgte auf Version 0.21 und beinhaltete Unterstützung für Tablets, Tastengruppen und Touchpad-Gesten. Diese Version gewährleistet eine stabile API/ABI. ^{[ 92 ]}

Da die erforderlichen Änderungen in GNOME/GTK und KDE Frameworks 5 ^{[ 93 ]} integriert wurden, wird Fedora 22 die evdev- und Synaptics-Treiber von X.Org durch libinput ersetzen. ^{[ 94 ]}

Mit Version 1.16 erhielt der X.Org-Server Unterstützung für die libinput-Bibliothek in Form eines Wrappers namens xf86-input-libinput . ^{[ 95 ] [ 96 ]}

Das Wayland Security Module ist ein Vorschlag, der der Schnittstelle des Linux Security Module im Linux-Kernel ähnelt . ^{[ 97 ]}

Einige Anwendungen (insbesondere solche, die Barrierefreiheit betreffen ) benötigen privilegierte Berechtigungen, die mit verschiedenen Wayland-Compositors kompatibel sein müssen. Derzeit können Anwendungen unter Wayland ohne die Nutzung von xdg-desktop-portal oder privilegierten Systemzugriff in der Regel keine sensiblen Aufgaben wie das Erstellen von Screenshots oder das Einschleusen von Eingabeereignissen ausführen. Das von Wayland erzwungene Sicherheitsmodell führt außerdem in vielen Spielen zu Problemen mit der Mausposition beim Texteingabeversuch. ^{[ 98 ]}

Das Wayland Security Module ist eine Möglichkeit, Sicherheitsentscheidungen innerhalb des Compositors an eine zentrale Sicherheitsentscheidungs-Engine zu delegieren. ^{[ 97 ]}

Das Wayland-Protokoll ist bewusst einfach gehalten, sodass zusätzliche Protokolle und Schnittstellen definiert und implementiert werden müssen, um ein umfassendes Fenstersystem zu realisieren. Obwohl viele grafische Toolkits Wayland bereits vollständig unterstützen, arbeiten die Entwickler der grafischen Oberflächen mit den Wayland-Entwicklern zusammen, um die notwendigen zusätzlichen Schnittstellen zu erstellen.

Die meisten großen Linux-Distributionen verwenden standardmäßig Wayland. Einige bemerkenswerte Beispiele sind:

• Debian liefert Wayland seit Version 10 (Buster) , veröffentlicht am 6. Juli 2019, als Standard-Sitzung für GNOME aus ^{. [ 99 ]}
• Fedora ab Version 25 (veröffentlicht am 22. November 2016) verwendet Wayland für die Desktop-Sitzung der GNOME Workstation Edition. X.Org dient als Fallback, falls der Grafiktreiber Wayland nicht unterstützt. ^{[ 100 ]} Fedora verwendet Wayland standardmäßig für die Sitzung der KDE Plasma Edition ab Version 34 (veröffentlicht am 27. April 2021). Beide Fedora-Editionen verzichten in Fedora 41 (veröffentlicht am 29. Oktober 2024) auf die standardmäßige Verwendung von X.Org. ^{[ 101 ]}
• Manjaro liefert Wayland standardmäßig in der GNOME-Edition von Manjaro 20.2 (Nibia) (veröffentlicht am 22. November 2020) aus. ^{[ 102 ]}
• Raspberry Pi OS , eine Portierung von Debian, bietet seit Version 11 (Bullseye) , die am 3. Dezember 2021 veröffentlicht wurde, die Option, Wayland zu verwenden. In Version 12 (Bookworm) , die am 10. Oktober 2023 veröffentlicht wurde, wurde Wayland zum Standard .
• Red Hat Enterprise Linux liefert Wayland als Standard-Session in Version 8 aus, die am 7. Mai 2019 veröffentlicht wurde. ^{[ 103 ]}
• Der Desktop-Modus von Steam OS 3.7 wurde von Plasma 5.27 auf KDE Plasma 6.2 umgestellt. Valve verwendete damals jedoch weiterhin standardmäßig die X.Org-Sitzung. Mit Steam OS 3.8 erfolgte die Umstellung auf KDE Plasma 6.4, und mit dieser Version von Steam OS stellte Valve den Desktop-Modus standardmäßig auf die Wayland-Sitzung um. ^{[ 104 ]}
• Ubuntu wurde in Version 17.10 (Artful Aardvark) standardmäßig mit Wayland ausgeliefert. ^{[ 105 ]} Aufgrund mehrerer Probleme kehrte Ubuntu 18.04 LTS jedoch wieder zu X.Org als Standard zurück. ^{[ 106 ] [ 107 ]} Seit der Veröffentlichung von Ubuntu 21.04 im Jahr 2021 ist Wayland wieder der Standard. ^{[ 108 ]} Ab Ubuntu 25.10 wurde die X.Org-Sitzung aufgrund der in dieser Version verwendeten GNOME-Version 49 zur Kompilierzeit deaktiviert. Da die nächste GNOME-Version, GNOME 50, die X.Org-Sitzung vollständig entfernen würde, ^{[ 109 ]} und Ubuntu 26.04 eine LTS-Version von Ubuntu ist, wurde die X.Org-Sitzung nicht wieder aktiviert, um Tests von 25.10 ausschließlich mit der Wayland-Sitzung in Vorbereitung auf Ubuntu 26.04 zu ermöglichen. ^{[ 110 ] [ 111 ]}
• Slackware Linux integrierte Wayland am 20. Februar 2020 ^{[ 112 ]} in die Entwicklungsversion -current, die 2022 zur Version 15.0 wurde. Wayland ist jedoch noch nicht der Standard. ^{[ 113 ]}

Zu den Toolkits, die Wayland unterstützen, gehören folgende:

• Die EFL genießt volle Unterstützung für Wayland, außer bei der Aufstellung. ^{[ 114 ]}
• GTK 3.20 bietet vollständige Wayland-Unterstützung. ^{[ 115 ]}
• Qt 5 bietet vollständige Wayland-Unterstützung und kann sowohl zum Schreiben von Wayland-Compositors als auch von Wayland-Clients verwendet werden.
• Die SDL- Unterstützung für Wayland wurde mit der Version 2.0.2 eingeführt ^{[ 116 ]} und ist seit Version 2.0.4 standardmäßig aktiviert. ^{[ 117 ]}
• GLFW 3.2 unterstützt Wayland. ^{[ 118 ]}
• FreeGLUT bietet erste Wayland-Unterstützung. ^{[ 119 ]}
• FLTK unterstützt Wayland seit Version 1.4.0 (Nov. 2024). ^{[ 120 ]}

Zu den Desktop-Umgebungen, die von X11 auf Wayland portiert wurden, gehören GNOME [ ^{121 ] ,} KDE Plasma ^{[ 122 ]} und Enlightenment ^{[ 123 ]} . Aktuell entwickelt auch Xfce einen Wayland-Compositor ^{[ 124 ] .}

• GNOME 3.20 war die erste Version mit einer vollständigen Wayland-Sitzung. ^{[ 125 ]} GNOME 3.22 bot deutlich verbesserte Wayland-Unterstützung für GTK, Mutter und GNOME Shell. ^{[ 126 ]} GNOME 3.24 enthielt Unterstützung für die proprietären Nvidia-Treiber unter Wayland. ^{[ 127 ]} In GNOME 49 war die X.Org-Sitzung standardmäßig deaktiviert, und in GNOME 50 wurde die Unterstützung für X.Org aus dem Quellcode entfernt. ^{[ 109 ]} Dies schränkt die Möglichkeit, X11-Anwendungen in der Wayland-Sitzung von GNOME über XWayland auszuführen, jedoch nicht ein .
• KDE Plasma unterstützte Wayland ab Version 5. ^{[ 128 ]} Version 5.4 von Plasma war die erste mit einer vollständigen Wayland-Sitzung. ^{[ 129 ]} In KDE Plasma 6.0 wurde Wayland zur Standardsitzung, X.Org stand als Fallback-Sitzung zur Verfügung. ^{[ 130 ]} In KDE Plasma 6.4 erkannte KWin die X.Org-Sitzung. ^{[ 64 ]} In KDE Plasma 6.8, dessen Veröffentlichung für Anfang 2027 geplant ist, wird die Unterstützung für die X11-Sitzung eingestellt. ^{[ 131 ]} Dies schränkt die Möglichkeit, X11-Anwendungen in der Wayland-Sitzung von KDE Plasma über XWayland auszuführen, nicht ein .
• Im November 2015 wurde Enlightenment e20 mit vollständiger Wayland-Unterstützung angekündigt. ^{[ 132 ] [ 62 ] [ 133 ]}
• Im Januar 2026 kündigte Xfce xfwl4 an , das Wayland-Äquivalent von xfwm . xfwl4 wird in Rust mit smithay geschrieben ^{[ 124 ]} , demselben Toolkit, das auch System76s COSMIC verwendet , welches in Pop!_OS ab Version 24.04 zum Einsatz kommt. Anders als bei GNOME und KDE Plasma gaben die Xfce-Entwickler im April 2026 bekannt, dass die X11-Sitzung nicht als veraltet markiert oder entfernt wird, solange es Entwickler gibt, die bereit sind, xfwm weiterzuentwickeln.

Weitere Software, die Wayland unterstützt, umfasst Folgendes:

• Intelligent Input Bus arbeitet an der Wayland-Unterstützung und könnte für Fedora 22 bereit sein. ^{[ 134 ]}
• RealVNC veröffentlichte im Juli 2014 eine Wayland-Entwicklervorschau. ^{[ 84 ] [ 135 ] [ 136 ]}
• wayvnc ist ein VNC-Server für wlroots-basierte Wayland-Compositors.
• Maliit und die Plasma-Tastatur von KDE sind zwei virtuelle Tastaturen, die als Eingabemethoden- Framework unter Wayland verwendet werden. ^{[ 137 ] [ 138 ] [ 139 ] [ 140 ]}
• kmscon unterstützt Wayland mit wlterm. ^{[ 141 ]}
• Mesa verfügt über integrierte Wayland-Unterstützung. ^{[ 142 ]}
• Eclipse wurde im Rahmen eines GSoC -Projekts im Jahr 2014 für den Betrieb unter Wayland entwickelt . ^{[ 143 ]}
• Die Vulkan-WSI (Window System Interface) ist eine Sammlung von API-Aufrufen, die eine ähnliche Funktion erfüllen wie EGL für OpenGL und OpenGL ES oder GLX für OpenGL unter X11. Vulkan WSI bietet von Anfang an Unterstützung für Wayland: VK_USE_PLATFORM_WAYLAND_KHR. Vulkan-Clients können auf unveränderten Wayland-Servern ausgeführt werden, darunter Weston, GENIVI LayerManager, Mutter/GNOME Shell, Enlightenment und weitere. Die WSI ermöglicht es Anwendungen, die verschiedenen GPUs des Systems zu erkennen und die Ergebnisse des GPU-Renderings in einem Fenstersystem anzuzeigen. ^{[ 144 ]}
• Waydroid (früher Anbox -Halium genannt) ist ein Container, mit dem Android-Anwendungen auf Linux-Distributionen mithilfe von Wayland ausgeführt werden können.

Folgende mobile und eingebettete Hardware unterstützt Wayland:

• postmarketOS
• GENIVI Alliance: Die GENIVI Alliance, jetzt COVESA, für In-Vehicle-Infotainment (IVI) unterstützt Wayland. ^{[ 145 ]}
• Jolla : Smartphones von Jolla nutzen Wayland. Es wird auch als Standard verwendet, wenn das Linux- Betriebssystem Sailfish mit Hardware anderer Hersteller eingesetzt oder von Nutzern auf Android-Geräten installiert wird. ^{[ 146 ] [ 147 ] [ 148 ]}
• Tizen : Ab Version 2.x unterstützt Tizen Wayland in Fahrzeug-Infotainmentsystemen (IVI). ^{[ 149 ]} Ab Version 3.0 ist Wayland die Standardeinstellung für Tizen. ^{[ 150 ] [ 151 ]}

Wayland verwendet Direct Rendering über EGL .

Kristian Høgsberg, ein Linux- Grafik- und X.Org- Entwickler , der zuvor an AIGLX und DRI2 mitgearbeitet hatte , begann Wayland 2008 als Nebenprojekt während seiner Tätigkeit bei Red Hat . ^{[ 152 ] [ 153 ] [ 154 ] [ 155 ]} Sein erklärtes Ziel war ein System, in dem „jedes Bild perfekt ist“, womit er meinte, dass Anwendungen die Darstellung so präzise steuern können, dass Tearing, Lags, Nachzeichnen oder Flimmern ausgeschlossen sind. Høgsberg fuhr gerade durch die Stadt Wayland in Massachusetts, als die zugrundeliegenden Konzepte Gestalt annahmen – daher der Name ( Weston und Maynard sind ebenfalls nahegelegene Städte in derselben Gegend, was die Verbindung weiterführt). ^{[ 154 ] [ 156 ]} Zu den weiteren frühen prominenten Entwicklern von Wayland zählen Daniel Stone, Peter Hutterer und Pekka Paalanen.

Im Oktober 2010 wurde Wayland ein Projekt von freedesktop.org . ^{[ 157 ] [ 158 ]} Die Entwickler-Mailingliste wurde damals nach wayland-devel migriert , die seit 2026 über GNU Mailman gehostet wird. ^{[ 159 ]}

Die Wayland-Client- und Serverbibliotheken wurden ursprünglich unter der MIT-Lizenz veröffentlicht ^{[ 160 ]} , während der Referenz-Compositor Weston und einige Beispielclients die GNU General Public License Version 2 verwendeten ^{[ 161 ]} . Später wurde der gesamte GPL-Code unter die MIT-Lizenz neu lizenziert , „um den Austausch von Code zwischen der Referenzimplementierung und den eigentlichen Bibliotheken zu vereinfachen“ ^{[ 162 ]} . Im Jahr 2015 wurde festgestellt, dass der von Wayland verwendete Lizenztext eine leicht abweichende und ältere Version der MIT-Lizenz war. Daraufhin wurde der Lizenztext auf die aktuelle Version des X.Org-Projekts (bekannt als MIT Expat License ) aktualisiert ^{[ 7 ]} .

Wayland funktioniert mit allen Mesa-kompatiblen Treibern mit DRI2- Unterstützung ^{[ 142 ]} sowie mit Android- Treibern über das Hybris-Projekt . ^{[ 163 ] [ 164 ] [ 165 ]}

• Mir (Software)
• X-Fenstersystem