Posted on by Martin Flöser

Wayland in Ubuntu – oder viel Lärm um Nichts?

Mark Shuttleworth hat in einem Blog Post geschrieben, dass Ubuntu eine der ersten Distributionen sein wird, die Wayland verwendet, was einiges an medialem Echo hervorgerufen hat. Persönlich hat mich der Blogpost überrascht, da auf dem Ubuntu Developer Summit für mich nicht ersichtlich wurde, dass Wayland schon zur Diskussion steht. Nur in einer Sitzung zu OpenGL ES in Composited Window Managers hatte ich Mark eine Frage zu Wayland stellen hören und war etwas verwundert. Für mich auch Anlass mal wieder in die Commit Historie zu schauen und ich habe erfreut festgestellt, dass die Entwicklung an Wayland aktiver geworden ist.

Nun was ist Wayland überhaupt? Wayland ist im Prinzip der Nachfolger des X-Servers, jedoch bedeutend schlanker. Wayland ist nur noch ein sehr dünner Display Manager mit eingebautem Compositor, der die Fenster zeichnet. Damit das ganze funktioniert braucht es viele der Technologien, die in den letzten Jahren Einzug erhalten haben, wie KMS und GEM. Genau hab ich mich auch noch nicht mit Wayland auseinandergesetzt, da es meiner Meinung nach, noch viel zu weit in der Zukunft ist. Jedoch sollte ich mich langsam aber sicher, damit beschäftigen, denn sonst steht KDE am Ende ohne Compositor dar (KWin als X WindowManager ist natürlich in einem X freien System nicht wirklich sinnvoll) 😉

Warum sollte man X überhaupt ersetzen? X11 ist älter als ich, xlib ist nicht gerade die schönste API um mit zu arbeiten – nicht überraschend bei einem Alter von fast 30 Jahren. X11 ist entwickelt für die Ansprüche der Rechner aus den 80er Jahren. Xlib enthält also einiges was man heute nicht mehr braucht: Farbverwaltung, Zeichnung, etc. und so ziemlich alles was man heute mit OpenGL machen sollte. Heutige Anwendungen nutzen die primitiven Funktionen von X zum Zeichnen nicht mehr, so ziemlich jedes Toolkit hat dafür bessere Methoden. So bietet Qt an komplett auf der CPU zu zeichnen, statt native Aufrufe zu verwenden und ist dabei bedeutend performanter. Das ganze führte so weit, dass Bereiche von X über Jahre kaputt waren ohne dass es irgendjemand aufgefallen ist.

Die X Entwickler um Keith Packard kennen auch die Probleme und haben immer wieder neue Lösungen angebracht. So zum Beispiel XCB – ein etwas schönerer Ersatz um nicht auf Xlib aufsetzen zu müssen. Nur hat das erst mal niemanden interessiert – KWin zum Beispiel verwendet immer noch XLib und nicht XCB. Genauso die Toolkits: mittlerweile hat man die Erfahrung an den Problemen von X herumzuprogrammieren und warum sollte man etwas neu programmieren, wenn es funktioniert? Ein anderer Bereich ist die Erweiterung des Protokolls durch Erweiterungen wie XFixes – welche wie der Name sagt Fehler im X Protokoll behebt.

Warum sollte aber ein Display Manager eine bessere Lösung sein? Dazu kann man sich anschauen wie aktuell Fenster auf den Bildschirm kommen. Das Fenster wird zuerst gemappt – erhält also einen Bereich auf dem Bildschirm. Der X Server sorgt dafür, dass nur die nicht überlappten Bereiche gezeichnet werden. Die Anwendung zeichnet in der Regel in Pixmaps als Buffers und diese werden von X dann auf den Screen geblittet. Der X Server ist also zuständig dafür zu sorgen, dass die Inhalte aktualisiert werden. Wenn man also ein Fenster über einem anderen verschiebt, werden ständig beide neu gezeichnet. Nun schalten wir die XComposite Erweiterung dazu und betrachten uns das neue Verhalten. X leitet die Ausgabe der Fenster in eine off-screen Pixmap um (Moment? Die Anwendung zeichnet selbst doch auch schon in eine Pixmap…) und benachrichtigt einen externen Client (in der Regel den Fenstermanager) über die XDamage Erweiterung wann sich die off-screen Pixmap verändert. Das geschieht schön asynchron und in klitze kleinen Häppchen (man kann sich vorstellen, was passiert, wenn der Compositor nicht alle Änderungen mibekommt). Der Fenstermanager (oder auch Compositor) nutzt nun die GLX Erweiterung Texture from Pixmap um aus der Pixmap eine Textur zu erstellen und mittels OpenGL diese auf den Bildschirm zu zeichnen. Der ganze "legacy" Bereich des X Servers wird nun nicht mehr benötigt. Man muss keine Zeichenoperationen unterstützen, keine Fenster verschieben können und so weiter und so fort.

Ein kleiner Display Manager ist genau das was man will. Jede Anwendung wird automatisch und immer umgeleitet. Sie braucht also auch keine Informationen wo sie sich befindet. Interessant ist nur die Größe, ob sie aktiv ist oder nicht und vllt. ob sie sichtbar ist oder nicht (z.B. für Videoplayer um automatisch zu pausieren). Wenn man sich nun auch festlegt, dass Compositing generell über OpenGL erfolgt, kann man auch statt einer Pixmap direkt einen Buffer verwenden, der in OpenGL direkt benutzt werden kann. Der X Fenstermanager entfällt und kann nun durch einen viel schlankeren Compositor ersetzt werden.

Viele der heutigen Probleme im Compositing Stack von X sind vermutlich unlösbar. Ich denke da zum Beispiel an das Problem der "Löcher in Fenstern" oder die Tatsache, dass man keine Live Bilder von minimierten Anwendungen hat (was auch der Grund ist für das Stottern der de-minimier Animationen ist). Auch Lösungen um Live Bilder von Anwendungen auf anderen Desktops zu erhalten ist eigentlich nur ein riesiger Hack. Warum wird mein Bildschirm neu gezeichnet, wenn sich etwas auf einem anderen Desktop ändert? Bei einer Architektur, die sich primär auf Compositing ausrichtet, ist das natürlich viel einfacher.

Der Wechsel auf Wayland ist natürlich nichts, was schnell vollzogen werden kann und ich denke mal, dass es locker noch fünf Jahre dauern wird. Alle Toolkits müssen dazu die X Abhängigkeit verlieren, Desktop Shells müssen portiert werden – hier ist es vor allem wichtig gute Compositor zu erstellen, da sonst Funktionalität verloren geht und die wichtige Adaptierung von Wayland verhindern wird. Dies ist zum Beispiel bei KWin ein etwas schwieriges Unterfangen, da die Anwendung komplett X voraussetzt – nur die Effekte könnten fast komplett wiederverwendet werden (nach einer Portierung auf OpenGL ES 2). Es gibt sicherlich auch Anwendungen und Toolkits die niemals portiert werden – für diese wird es dann in Wayland auch einen eingebetteten X Server geben. Die Angst, dass geliebte Anwendungen durch die Transition verloren geht, besteht also nicht. Auch die Netzwerktransparenz von X bleibt somit erhalten.

Und was ist nun von der Canonical Ankündigung zu halten? Für mich klingt es danach, dass sie Unity so schreiben, dass es keine X Abhängigkeit erzwingt (wie zum Beispiel Plasma auch nicht) und dass sie wohl daran arbeiten werden Compiz als Compositor für Wayland fit zu machen. Dies wäre natürlich sehr interessant, da ich mich dort dann auch bedienen kann 😉 Bzw. dass man in den Bereichen zusammenarbeiten kann. Wir sind glücklicherweise so weit, dass wir grundlagen Technologie nicht mehr getrennt entwickeln. Vorerst bedeutet das wohl, dass Compiz auf OpenGL ES portiert werden muss – genauso wie KWin. Abgesehen davon wird wohl nicht viel passieren. Die Anwendungen werden weiter X verwenden.

Natürlich ist das jetzt auch nichts unglaublich herausragendes von Canonical in dem Bereich früh dabei zu sein. Sie werden es wohl auch nicht schaffen als erste Wayland einzusetzen, da MeeGo auch daran arbeitet (Kristian Høgsberg arbeitet für Intel) und gerade für Mobile Devices X nicht die beste Technologie ist. Außer Maemo setzt aktuell kein Linux Handy OS auf X. Um es ganz klar zu sagen: alle Distributionen werden so schnell wie möglich ein etwas funktionierendes Wayland ausliefern, um den Entwicklern eine Basis zum Portieren geben zu können.

Ich persönlich begrüße die Entwicklung, auch wenn es gerade für meine Anwendung viel Arbeit bedeuten wird, auf Wayland zu portieren und ohne eine Vollzeit Stelle wird so etwas kaum machbar sein. Dass Ubuntu nun diese Ankündigung macht, ist wirklich nicht überraschend, aber man muss Mark gratulieren zum guten Marketing 😉

=-=-=-=-=
Powered by Blogilo

25 Replies to “Wayland in Ubuntu – oder viel Lärm um Nichts?”

  1. Vielen Dank für Deine Einschätzung. Es ist immer interessant zwischen den ganzen Euphorieposts einen vom Profi zu lesen.

    Kannst Du mal bitte ein Beispiel für einen Laien bringen, warum Anwendungen da angepasst werden müssen? Ich dachte doch, dass die meisten einfach ein Toolkit nutzen (Qt, GTK, was weiß ich was noch) und somit von tieferliegenden Schichten abgekapselt sind. Somit würde es nach meiner Vorstellung reichen, Toolkits und Windowmanager zu portieren. Wo liegt da das Problem?

    1. Dem kann ich mich nur anschließen.
      Was ich hier erfahren habe lässt all dir andere Berichterstattung in schlechtem, unvollständigen Licht stehen.
      Danke

  4. Danke für die Erklärung. Hast du mitbekommen, ob derzeit geplant wird, einen generellen WaylandServer zu bauen, oder sollen die Compositoren wie Compiz selbst in diese Rolle schlüpfen? Oder habe ich das falsch verstanden und die letztere Möglichkeit besteht nicht wirklich?
    Gruß

  5. Eines ist sicher: Mit dem Kreieren der Frage und Theorien mit dem Titel “Is Shuttleworth Crazy, Brave, or Smart?” bringt er seine Person und Canonical zwar in die Schusslinie … aber eine sehr erfrischende, anregende und unterhaltsame Diskussion zu FOSS die ich lange vermisst habe 😉

  6. Wie heißt dann wohl Linux ohne “X” ? Linway?

    Eine Ankündigung mit wieder einmal viel Pathos , wohl wissenen das dies allein kein Ubuntu “stemmen” könnet , sich aber vorzeitig den Ruhm dafür sichern möchte.

    Im Prinzip ist die Sache gut , zum Funktionieren muss es von allen Akzeptiert und mit Zusammenarbeit Unterstützt werden und da sehe ich die größten Schwierigkeiten,
    Gerade nach den letzten Alleingängen von Ubuntu wären nach meinen Infos einige nicht Unglücklich wenn sie damit auf die “Nase fallen” würden.

    Wichtig sind zudem die Treiber , die Ubuntu Klientel die zur Zeit ihren “Mark” dafür feiert wüden sicher die ersten sein die Wayland verteufeln wenn die Grafikktreiber nicht oder schlechter damit laufen.
    Das Erinnert mich etwas an die unbedingte Einführung von “Pulse Audio” was heut noch viele Probleme bereitet.

    Aber wie gesagt im Prinzip Gut, Xorg zu Erneuern , aber bitte Zeit dafür nehmen und Gemeinsam.

  7. HoiHoi Martin,

    vielen dank für den höchst informativen Artikel, der das auch dem Laien endlich mal verständlich macht.

    Ich persönlich bange bei der Sache ein bißchen um die Multi-Monitor Geschichten. Das ist jetzt schon immer eine etwas hackelige Angelegenheit. (xrandr 1.4 soll ja viel besser sein, konnte ich noch nicht testen) Kannst Du, mit Deinen Einblicken und Deinem Schachverständnis, eine Einschätzung abgeben, ob das mit Wayland besser/einfacher wird oder (zu Anfang) eher schlechter bis unmöglich.

    Wäre Dir sehr zu Dank verbunden,

    will;

    1. Multimonitor ist unter X so ein fürchterliches Problem, weil es so viele verschiedene Möglichkeiten gibt: Dual-Head, Xinerama, TwinView, XRandR… – ich denke das kann nur besser werden, da es auf eine API reduziert wird und das ganze “legacy” Zeug wie Dual-Head und Xinerama endlich stirbt.

  8. Pingback: onli blogging

  9. Irgendwie fände ich es auf anderer Seite aber auch hilfreich, nicht zwangsläufig von GL abhängig sein zu müssen. — Wohlwissens dass glxgears kein Benchmark ist, produziert es auf den typischen gegenwärtig erhältlichen Intel GMA3150/N10 “nur” 60 fps (auch sonst eher langsam mit “echten” GL-Games). Verdammt, da ist ja selbst eine fast 10 Jahre ältere NV11 GF2 mindestens 6x besser.

      1. Außer man deaktiviert vsync.

        Könnte man den xserver nicht einfach gründlich überarbeiten? Irgendwie sehe ich keinen überwältigenden Nutzen durch Wayland.

        1. Wenn ein Softwaresystem verbastelt / an den Anforderungen vorbei genug ist, ist es meist einfacher von den Anforderungen ausgehend von vorne anzufangen als zuerst das alte System komplett zu verstehen und dann zu verbessern.

  10. Ich betrachte das Ganz zunächst einmal wenig emotional.
    Wissen würde ich aber gern, wie man sich für die Zukunft die Realisation von Netzwerktransparenz vorstellt u.a. für den Einsatz von Thin Clients. Natürlich gibt es Alternativen zu den Netzwerkfähigkeiten von X11, z.B. NX oder RDP. Aber wie soll es praktisch funktionieren?
    Ich würde es für verfrüht halten, eine Migration auf Wayland zu beginnen, bevor die Frage geklärt ist.
    Das Ausweichen auf X11 für das Netzwerk und X11 auf Wayland kann allenfalls eine Übergangslösung darstellen.

    1. Ich sehe nicht warum man für einen Desktop Netzwerktransparenz braucht und denke dass es durchaus ok ist, dies in Wayland nicht zu verwenden. Wer das braucht, kann ja weiterhin X verwenden.

      1. Viele haben über Jahre die fehlende Netzwerktransparenz in MS Windows kritisiert, die erst nachträglich über ICA bzw. RDP “drangeflanscht” wurde.

        Ich möchte nicht behaupten, dass die Netzwerkschicht in X optimal gelöst ist, performant und effizient ist sie sicherlich nicht. Im Gegenteil, es wäre an der Zeit, sie ebenfalls durch eine moderne Lösung zu ersetzen.

        Ich verstehe den Schritt in Richtung Wayland aber als sinnvollen Schritt nach drei Jahrzehnten endlich X loszuwerden. Daher schrieb ich, dass “Das Ausweichen auf X11 für das Netzwerk und X11 auf Wayland […] allenfalls eine Übergangslösung darstellen” kann.

        Anwender, die netzwerktransparenz benötigen – und ich halte das nicht für exotisch – daher auf X zu verweisen, finde ich daher befremdlich. (Klingt ein wenig nach: wer Netzwerktansparenz braucht, soll halt mit X untergehen, auch wenn es sicherlich nicht so gemeint war.)

        Mir ist klar, dass Wayland selbst Netzwerkfähigkeiten nicht entgegen steht, sondern nur nicht selbst mitbringt.

        Ich bedaure nur, dass es derzeit offenbar keinen konkreten Plan gibt, optional(!) Anwendungen oder den kompletten Desktop auf einem entfernt Host laufen zu lassen und lokal mit Wayland zur Darstellung zu bringen (ohne X).

        1. Worauf ich hinauswollte: die nicht vorgesehene Netzwerktransparenz in Wayland ist kein Argument gegen die Einführung. Es hat einfach nichts miteinander zu tun. Die die Wayland brauchen, brauchen keine Netzwerktransparenz und umgekehrt. Schauen wir uns doch einfach mal die Realität an: Plasma ist im rinzip nicht für Netzwerktransparenz geeignet und für Unity und GNOME Shell halte ich es für unmöglich. Wer einen modernen Desktop will, kann netzwerktransparenz nicht verwenden. Wer keinen modernen Desktop will, sollte noch länger bei X bleiben

          1. Es gibt den Vorschlag für einen Compositor in Wayland, der die Bilddaten über ein modernes Protokoll wie RDP, VNC oder NX über das Netzwerk schickt.
            Übrigens – weiß man schon irgendwas über die Behandlung von allem, was nicht Fensterinhalt ist, in Wayland? Fokus, Maus und Tastatur vor allem. An Drag&Drop wird wohl schon gearbeitet, denn es gibt einen Screenshot einer D&D-Demo auf der Wayland-Homepage.

            1. zu Maus & Tastatur hab ich gelesen, dass das auch in den Compositor fällt, womit Input Redirection ein Standardfeature wäre. Fokus weiß ich noch nicht wie das funktioniert – das braucht wohl die Wayland Umsetzung von IPC.

  11. Das man soviel portieren muss ist ganz grosser Mist, den viele nicht mitmachen werden!

    Wenn sie wollen das sich Wayland durchsetzt, müssen sie eine Kompatibiltätsschicht einführen, damit man sich diese Arbeit ersparen kann!

Comments are closed.