Original-URL des Artikels: https://www.golem.de/1105/83334.html    Veröffentlicht: 10.05.2011 12:08    Kurz-URL: https://glm.io/83334

Displayserver

Wayland statt X.org

Canonical und Fedora setzen in Zukunft auf Wayland und beteiligen sich an dem Projekt. Eine erste experimentelle Version steht unter der aktuellen Ubuntu-Version zur Verfügung. Spätestens bis Ubuntu 12.04 soll Wayland X.org ersetzen.

Der Displayserver Wayland startete vor zwei Jahren als experimentelle Alternative zu X.org und soll jetzt unter Ubuntu für die grafische Oberfläche sorgen. Wayland soll leistungsfähiger und effizienter sein als X und auf dessen wenig genutzte Funktionen verzichten. Zentrale Schnittstelle ist der Wayland-Compositor, der als Displayserver, Fensterverwaltung und Compositor dient. Ganz auf X.org verzichten werden die Entwickler auch in Zukunft nicht, es soll als Plugin unter Wayland laufen. Außerdem haben die Entwickler um Wayland-Initiator Kristian Høgsberg einige Funktionen aus X übernommen.

Ursprünglich wollte Høgsberg nur beweisen, dass der Code von X.org ohne großen Aufwand entschlackt werden kann. Erst durch die Ankündigung durch Canonical-Chef Mark Shuttleworth, Wayland in künftigen Ubuntu-Versionen zu implementieren, sah sich Høgsberg dazu gezwungen, die Arbeit am Wayland-Projekt zu intensivieren. Inzwischen hat Canonical beschlossen, Wayland in Ubuntu 12.04 als Standard zu integrieren. Eine Entwicklerversion steht bereits im aktuellen Ubuntu 11.04 zur Verfügung. Auch das Meego- und Fedora-Projekt haben signalisiert, Wayland verwenden zu wollen.

X entschlackt

Gegenüber X.org hat Wayland einige entscheidende Vorteile: Es verzichtet auf Funktionen von X, die seit Jahren veraltet sind. Wayland unterscheidet sich allerdings auch im Aufbau grundlegend von X.org und soll die grafische Oberfläche beschleunigen und effizienter machen. Das soll vor allem durch kürzere Wege realisiert werden, denn Wayland soll mit einem eigenen Compositor direkt zwischen Wayland-Clients und Grafiktreiber vermitteln.

Zu den Komponenten, auf die Wayland verzichten soll, zählen beispielsweise die Core-Fonts, die in den ersten Jahren für die Textdarstellung sorgten. Die gesamte Infrastruktur ist veraltet und unnütz. Zudem benötige niemand mehr die grafischen Primitiven wie Linien und Polygonen, wie sie in den 1980er Jahren noch genutzt wurden. Das grundlegende Ziel von Wayland ist, den X-Server von unnötigem Code-Ballast zu befreien.

DRI, GEM und KMS

Die Architektur des Displayservers wurde deshalb vollkommen umgestaltet. Zum einen verlässt sich Wayland in weiten Teilen auf Treiberkomponenten, die bereits in den Linux-Kernel ausgelagert sind, etwa die DRI-Schnittstelle (Direct Rendering Infrastructure), die Speicherverwaltung Graphics Execution Manager (GEM) oder die Kernel-Mode-Settings (KMS), über die die Bildschirmkonfiguration durch den Kernel erfolgt statt wie zuvor durch X. Bislang berichten die Entwickler auf der Mailingliste, dass Wayland mit den "großen Drei" bereits funktioniert - gemeint sind die Nouveau-, Radeon- und Intel-Treiber. Wayland setzt dabei komplett auf die Hardwarebeschleunigung per OpenGL. Eine OpenGL-Applikation verzichtet dann auf den Umweg über den X-Server, sondern kommuniziert direkt mit der Grafikkarte. Derzeit setzt Wayland auf OpenGL ES 2.0 und EGL , das die Bibliothek LibGL.so bereitstellt, um Abhängigkeiten X zu vermeiden. Auf längere Sicht wollen die Entwickler eine eigene Bibliothek bereitstellen, etwa unter dem Namen WaylandGL.

Eigener Compositing-Manager

Darüber hinaus hat Wayland einen eigenen Compositing-Manager. X verwendet externe Compositing-Manager und vermittelt Ein- und Ausgabesignale zwischen diesem und der Hardware, was unnötige Kontextwechsel nach sich zieht. In Wayland hingegen klinkt sich der Compositing-Manager direkt zwischen Client und Treiber ein. Damit kann der Wayland-Compositor nach einer Veränderung in der Benutzeroberfläche einen Pageflip-Befehl direkt beim Treiber anmelden.

Das Rendern bei Wayland übernimmt der Client beziehungsweise die Anwendung. Über Direct Rendering, das mit Hilfe der DRI2-Schnittstelle bereitgestellt wird, können Clients und der Server einen Videopuffer teilen. Der Client kommuniziert über eine Rendering-Bibliothek, etwa OpenGL, direkt mit der Grafikkarte und schreibt die Rendering-Informationen in den Speicherpuffer. Dort wird er vom Compositing-Manager ausgelesen und auf den Bildschirm geschrieben. Der Client muss dem Compositing-Manager nur mitteilen, in welchem Speicherbereich er nach den Daten suchen muss und wann er neue Daten geschrieben hat.

Die jeweiligen Anwendungen erhalten damit die Kontrolle über den verwendeten Speicherpuffer. Diese müssen über neue Fensterinhalte zwar informiert werden, der Inhalt des Speicherpuffers kann aber winzig sein und etwa nur die Information über das Blinken eines Cursors enthalten.

X-Server als Plugin

Laut Entwickler Høgsberg soll Wayland lediglich eine Schnittstelle sein, die andere Schnittstellen erkennt und verwenden kann. Dank der Auslagerung in Erweiterungen soll Wayland weitgehend skalierbar sein. Selbst der X-Server, auf den laut Høgsberg auch künftig nicht verzichtet werden kann, soll später als Wayland-Plugin funktionieren.

Wayland stellt einen kompletten eigenen Displayserver bereit, soll aber die Kompatibilität zu X beibehalten. Dazu sind nur wenige Änderungen in X nötig, so dass X auf die Eingabegeräte über Wayland zugreifen und die gezeichneten Oberflächen entweder an sein Root-Fenster oder die X-Clients weiterleiten kann. X.org könnte seine eigenen 2D-Treiber und Grafikbeschleunigung verwenden. Der einzige Unterschied wäre, dass X.org über Wayland mit der Grafikkarte kommuniziert statt selbst auf die Kerneltreiber zuzugreifen.

Wenige KByte Code

Wayland soll auch als Toolkit dienen, mit dem sowohl eigene Clients als auch Compositor geschrieben werden können. Derzeit arbeiten die Compiz-Entwickler daran, ihren Compositing-Manager an Wayland anzupassen. Der Vorteil gegenüber X soll darin bestehen, dass die Kommunikation mit den Grafiktreibern und der Eingabeschnittstelle in weniger als 1.000 Zeilen Code realisierbar ist.

Der derzeitige Wayland-Code selbst gibt sich bescheiden. Insgesamt etwa 150 KByte beträgt das Tar.gz-Archiv aus dem Code-Repository. Während die Wayland-Version für Ubuntu 11.10 aktiv gepflegt wird, scheint die Version für das aktuelle Ubuntu 11.04 schon jetzt nicht mehr weiterentwickelt zu werden. Code-Änderungen durch Dritte werden im Git-Repository meist durch Hauptentwickler Høgsberg eingepflegt.

Aktive Entwicklung

Die Mailingliste zeigt, dass das Projekt durch Canonicals Zuspruch Fahrt aufgenommen hat. Inzwischen gibt es erste Toolkit-Schnittstellen, etwa zu Clutter, Qt, SDL und Gtk+. Allerdings zeigt die Diskussion dort, dass nicht nur Erklärungsbedarf besteht, sondern dass sich die Entwicklung noch in einem experimentellen Stadium befindet und noch nicht alle Fragen geklärt sind.

Auch wenn die Entwickler immer wieder betonen, Wayland sei kein Fork - langfristig könnte der neue Displayserver X.org durchaus ersetzen.  (jt)


Verwandte Artikel:
Google: Chromebooks bekommen "Linux-VMs" und "Terminal"   
(27.02.2018, https://glm.io/133030 )
Modesetting: Fedora verzichtet auf Intels X11-Treiber   
(12.01.2017, https://glm.io/125548 )
Unix-Desktop: KDE Plasma 5.12 startet schneller und bringt LTS   
(07.02.2018, https://glm.io/132636 )
KWin: KDE beendet Funktionsentwicklung für X11   
(22.01.2018, https://glm.io/132300 )
Nouveau: Nvidia baut neues Grafikspeicher-API für freien Treiber   
(21.12.2017, https://glm.io/131812 )

© 1997–2020 Golem.de, https://www.golem.de/