Firefox war bisher nicht unbedingt eine Vorzeigeanwendung unter Wayland. Martin Stransky, Firefox-Paketbetreuer für Fedora und RHEL und verantwortlich für die Portierung von Firefox für Wayland, hat einen Bericht veröffentlicht, der die Fortschritte von Firefox in Wayland-Sitzungen für 2021 zusammenfasst.
Er identifiziert zwei große Bereiche, in denen Firefox hinter seinem X11-Gegenstück zurückbleibt – die Zwischenablage und die Handhabung von Pop-ups. Das liegt an einigen Funktionen des Wayland-Protokolls, bei denen der X11-Code nicht einfach dupliziert werden kann.
Schlecht abgelegt
Die Zwischenablage unter Wayland ist ähnlich wie die von X11, jedoch muss die asynchrone Zwischenablage von Wayland in eine mit Firefox/Web synchronisierte übersetzt werden. Der beste Ansatz scheint laut Stransky zu sein, einfach die asynchrone Wayland-Zwischenablage so zu verwenden, wie sie ist, und eine Art Abstraktion darüber zu implementieren. Das wurde bereits in Firefox 93 implementiert und wird mit Firefox 94 am 2. November standardmäßig ausgeliefert. Das angepasste Verhalten der Zwischenablage kann mit dem heute freigegebenen Firefox 93 unter Wayland bereits getestet werden, indem in about:config der Schalter set widget.wayland.async-clipboard.enabled auf true gesetzt und der Browser neu gestartet wird.
Problemfall Pop-ups
Bei Pop-ups ist die Situation etwas schwieriger. Firefox erwartet einfach, dass jedes Pop-up jederzeit ohne sein »Elternteil«, also den auslösenden Prozess erstellt werden kann, aber Wayland verlangt eine strenge Pop-up-Hierarchie. Das bedeutet, dass jedes Fenster nur ein Kind-Pop-up haben kann. Wenn mehr als ein Pop-up-Fenster geöffnet wird, muss es an das zuvor geöffnete angehängt werden, dass dann zum Elternfenster wird. Dies betrifft alle Arten von Pop-ups.
Außerdem gibt es noch einige Bugs im Wayland-Protokoll oder in GTK, die die Implementierung des mit Firefox 94 zur Auslieferung geplanten Pop-up-Tracker erschweren und die vermutlich einige Regressionen nach sich ziehen werden. Zum Ende seines Berichts geht Stransky noch auf die Pläne für Firefox 95 und 96 in Bezug auf Wayland ein. Stichworte sind hier unter anderem GPU und VAAPI.
X.Org Server 1.21 ist bereits seit einigen Jahren in der Entwicklung. Aber nicht Fehler im Code hielten das Release zurück, sondern das Fehlen eines Release-Managers. Die Veröffentlichung der letzten Version X.Org Server 1.20 liegt über drei Jahre zurück. Hatte früher meist Red Hat diese Position übernommen, aber angesichts von Wayland offenbar kein Interesse mehr an X.Org. Da auch sonst keine Organisation die Rolle übernahm, fehlte für X.Org Server 1.21 lange ein Release-Manager.
Vorbereitungen für X.Org Server 21.1 begonnen
Jetzt scheint es, als ob wir noch in diesem Jahr mit einem Release von X.Org Server 1.21 rechnen können, allerdings mit veränderter Versionierung als X.Org Server 21.1. Der unabhängige litauische Entwickler Povilas Kanapickas hat begonnen das Release vorzubereiten. Es gebe zwar noch einige Fehler im Master-Zweig, aber die Release-Vorbereitungen könnten trotzdem bereits beginnen. Kanapickas hatte bereits Anfang Juni den Entwicklungs-Snapshot xorg-server 21.0.99.1 freigegeben.
Sein Plan sieht vor, am 16. August die ABI einzufrieren und zum 30. August einen ersten Release-Kandidaten vorzulegen. dem alle zwei Wochen ein weiterer Kandidat folgen soll, bis X.Org Server 21.1 bereit zur Veröffentlichung ist. Abweichend vom Vorgehen bei früheren Veröffentlichungen wird bereits vor den ersten RC das Git gebrancht anstatt erst nach der stabilen Veröffentlichung.
XWayland wird separat veröffentlicht
Der Grund dafür ist, dass der Code von XWayland für die RC-Versionen entfernt wird, da XWayland wegen der Verzögerungen bei der Veröffentlichung von X.Org bereits im März abgekoppelt wurde und seitdem separat auf Grundlage des Masters auf Git veröffentlicht wird. Die erste Veröffentlichung des Standalone-XWayland-Pakets fand mit Fedora 34 statt. Dementsprechend wird nach der Veröffentlichung von RC 1 der Master-Zweig wieder offen für Änderungen, die auf die nächste Version abzielen.
X11 ist in die Jahre gekommen, aber noch lange nicht vom Tisch, denn Wayland kann noch nicht unter allen Umständen als vollwertiger Ersatz dienen. Allerdings stockt die Entwicklung von X11 und die Veröffentlichung von X.Org Server 1.21 hängt bereits seit Längerem in der Schwebe, da niemand sich zuständig fühlt.
Red Hat hat kein Interesse mehr an X.Org
Die Veröffentlichungen und die nötige Pflege von Veröffentlichungen des X.Org Server wurden früher oft von Red Hat-Entwicklern betreut, deren Zeit aber jetzt von Wayland gebunden wird. Darunter hatte das Paket XWayland zu leiden, dessen Weiterentwicklungen nicht zeitnah zu den Anwendern gelangte, da XWayland zusammen mit X.Org Server ausgeliefert wurde.
XWayland ist ein vollwertiger X-Server, der bei X11-kompatiblen Anwendungen für eine Zwischenschicht sorgt, indem er Bilddaten an den Wayland-Compositor durchreicht. Ein Entwicklungsziel für Fedora 34 war, XWayland als eigenständiges Paket zu etablieren, sodass Änderungen schneller veröffentlicht werden können.
Technisch einfach umzusetzen
XWayland verfügt über keinen geräteabhängigen Treiber, der zur Laufzeit geladen wird und lädt auch kein Modul, sodass es nicht durch die Xorg-API-Versionierung eingeschränkt ist wie der Rest von X.org. Technisch gesehen spricht also nichts dagegen, XWayland als eigenständiges, separates Paket auf Git-Master zu bauen, während der Rest des X.org-Server aus dem stabilen Source-Tree von Upstream kommt.
Mit Fedora 34 ausgeliefert
Jetzt melden die Entwickler Vollzug, gestern wurde mit XWayland 21.1.0 das erste eigenständige Release vorgelegt. Red Hats Michel Danzer gab die Veröffentlichung auf der Xorg-Ankündigungsliste bekannt, Fedora wird das neue Paket in seiner anstehenden Veröffentlichung ausliefern.
Wann diese stattfindet, entscheidet sich heute bei der Sitzung des Fedora-Steuerungskomitee FESCo. Letzte Woche war die geplante Veröffentlichung von Fedora 34 Beta wegen ausstehender Fehler zurückgestellt worden. Heute wird sich entscheiden, ob die Beta am Ausweichtermin 23. März erscheinen wird. Die allgemeine Verfügbarkeit von Fedora 34 wird für Ende April erwartet.
Für die im Frühjahr anstehende Veröffentlichung von Fedora 34 liegt ein Vorschlag vor, XWayland in ein eigenes Paket abzuspalten, anstatt es weiterhin mit X.org zu koppeln. Der X.org-Server verharrt seit Jahren bei Version 1.20.x und es ist auch keine Veröffentlichung in Sicht.
XWayland als eigenes Paket
XWayland ist eine vollwertige X-Server-Implementierung, die als Proxy zwischen X11-Clients und einem Wayland-Compositor fungiert. Der Veröffentlichungszyklus ist derzeit an X.org gebunden. Da keine neuen X.org-Server-Releases in Sicht sind, Red Hat und Fedora aber aktualisierte XWayland-Pakete ausliefern möchten, stellte Red Hat-Entwickler Michel Dänzer einen Request for Comments (RFC) auf GitLab und einen Änderungsvorschlag für Fedora 34 vor, indem er die Idee ausbreitet, die Veröffentlichung in einem eigenen Paket vorzunehmen, sodass Anwender neue Funktionen schneller in ihren Distributionen testen können.
Technisch einfach umzusetzen
XWayland verfügt über keinen geräteabhängigen Treiber, der zur Laufzeit geladen wird und lädt auch kein Modul, sodass es nicht durch die Xorg-API-Versionierung eingeschränkt ist wie der Rest von X.org. Technisch gesehen spricht also nichts dagegen, XWayland als eigenständiges, separates Paket auf Git-Master zu bauen, während der Rest des X.org-Server aus dem stabilen Source-Tree von Upstream kommt.
Entwicklung vereinfachen
Derzeit werden manche Weiterentwicklungen von XWayland zurückportiert, andere nicht, was zu einem unbefriedigenden Ergebnis führt und zudem fehleranfällig ist. Auch die derzeitige XRandR-Emulation für Spiele könnte entfallen, falls sich der Vorschlag durchsetzt. Jetzt warten die Entwickler auf Rückmeldungen aus der Community. Im Endeffekt entscheidet Fedoras Leitungsgremium FESCo darüber, ob der Vorschlag umgesetzt wird. Erst kürzlich hatte FESCo dem Vorschlag zugestimmt, mit Fedora 34 Audio per PipeWire auszugeben.
Wayland, das nicht mehr ganz so neue Display-Server-Protokoll für Linux ist keine Technik, die ihren Vorläufer von heute auf morgen ersetzt. Wayland schleicht sich eher über einen langen Zeitraum an die Stelle des in die Jahre gekommenen Display-Servers X.Org.
KDE-Entwickler Méven Car berichtet in seinem Blog über den Zustand von Wayland mit Plasma 5.20. Unbestritten hat Wayland bei KDE in diesem Jahr viele Fortschritte gebracht und es gibt Nutzer, die Wayland aufgrund ihrer Hardware und ihres Anwendungsprofils bereits ohne große Abstriche nutzen können. Das gilt aber noch nicht für die Mehrzeit der KDE-Anwender.
Warum braucht die Wayland-Integration so lange?
Wayland formalisiert den Datenaustausch zwischen einer Anwendung und dem jeweiligen Compositor, im Fall von Plasma also KWin durch Protokolle. Dazu stellt Wayland im Kern eine ganze Reihe von Standardprotokollen zur Verfügung. Da diese Protokolle recht generisch ausfallen sind sie für Plasma oft nicht ausreichend oder gar unpassend. Darüber hinaus wurden viele Protokolle erstellt, die Funktionalitäten jenseits des Wayland-Core bereitstellen.
Erweiterte Protokolle benötigt
KWin und Plasma haben mit der Zeit einige spezifische Protokolle erhalten. Diese erlauben es beispielsweise der Plasma-Taskleiste, andere Fenster zu verwalten. Die Definition von an den jeweiligen Desktop und Compositor angepassten Protokollen braucht Zeit, sie müssen ausgiebig getestet, validiert und bei Bedarf aktualisiert werden. Zudem müssen sie neben dem Compositor manchmal auch in Anwendungen oder Frameworks implementiert werden. Fehlende oder nicht implementierte Protokolle sind oft die Ursache für fehlende Features, die Miniaturansichten des Task-Manager-Fensters sind ein Beispiel dafür.
Keine Netzwerktransparenz
Die Wayland-Entwickler hatten nie die vollständige Funktionsparität mit dem X.Org Display-Server im Sinn. Dieser umfasst viele Dinge von Tastatureingaben über Bildschirmschoner bis hin zur Bildschirmverwaltung. Ein weiterer Hemmschuh war die Netzwerktransparenz von X.Org, die Wayland aus Sicherheitserwägungen nicht implementiert hat.
So müssen manche Funktionen teilweise durch zusätzliche Wayland-Protokolle oder durch völlig neue Lösungen realisiert werden. KDE hat hier gute Fortschritte gemacht, aber es fehlen noch einige wenige Fälle. Im Wiki von KDE sind die noch fehlenden Puzzleteile aufgelistet. Ein anderer Eintrag definiert KDEs Ziele in Bezug auf Wayland und zeigt Wege auf, dieses Ziel zu erreichen.
Neue Lösungen
Auf der Haben-Seite der letzten Monate stehen Screen-Recording und Screen-Casting, bei denen das neue Multimedia-Framework Pipewire eine gewichtige Rolle spielt. Auch Klipper unterstützt nun Wayland inklusive dessen Zwischenablage. Um unter Wayland eine virtuelle Tastatur und andere Annehmlichkeiten in Plasma und Plasma Mobile zu ermöglichen, wurde ein weiteres Protokoll implementiert. Ab KDE Frameworks 5.74 und Plasma 5.21 merkt sich KWin die Position von Fenstern unter Wayland.
Plasma 5.20 hat aufgeholt
Bugfixes für Plasma 5.20 brachten weitere Erleichterung bei der Nutzung von Wayland. So zieht XWayland, wenn es abstürzt nicht mehr die ganze Sitzung in den Abgrund, sondern startet automatisch neu. Auch das Löschen der Wayland-Zwischenablage führt nicht mehr zum Absturz von Plasma. KWin ist ebenfalls besser gegen Abstürze gesichert. Ein vertiefendes Buch zum Thema Wayland und dessen Integration stammt von Drew deVault, seines Zeichens Entwickler des Window-Manager Sway, einem Wayland-Clone von i3.
Der Umstieg auf das nun schon nicht mehr so neue Display-Server-Protokoll Wayland dauert an und wird je nach Desktop-Umgebung auch noch eine ganze Weile brauchen, bevor die Parität der Funktionen zu X.org erklärt werden kann. So wird etwa das in Kürze erwartete Xfce 4.16 immer noch keine Wayland-Sitzung bieten. Auch bei Cinnamon sind bisher keine Entwicklungen zur Unterstützung von Wayland erkennbar.
Als Abandonware bezeichnet
Gleichzeitig lässt aber die Unterstützung für X.org von Entwicklerseite so stark nach, dass Intels Kernel-Entwickler und DRM-Co-Maintainer Daniel Vetter X.org kürzlich gar als Abandonware, also als vernachlässigte Software bezeichnet hat, die keine angemessene technische Unterstützung mehr erhält. Das ist eine harte Kritik, die aber laut eines Berichts auf der Plattform Phoronix nicht unangemessen erscheint.
Entwicklungszyklus außer Kraft
Demzufolge fand die letzte große Veröffentlichung des X.org-Server in Form von Version 1.20 im May 2018 statt. Dabei unterliegt die Entwicklung eigentlich einem halbjährlichen Veröffentlichungszyklus. Die Git-Commits sind in den letzten beiden Jahren auf dem niedrigsten Stand der letzten 20 Jahren angelangt. Gab es im Jahr 2008 noch 2.114 Commits, so waren es 2019 lediglich noch 316 Einreichungen.
Red Hat vorne
Obwohl Red Hat hauptsächlich Ressourcen in Wayland steckt, führt der dort beschäftigte Entwickler Adam Jackson mit 66 Commits die Liste für 2019 an, gefolgt von weiteren Red Hat Mitarbeitern. Dabei strebt Red Hat schon seit geraumer Zeit an, die Entwicklungstätigkeit einzustellen, X.org in den Wartungsmodus zu versetzen und lediglich die vorhandene Codebasis zu pflegen.
Keine Veröffentlichung in Sicht
Derzeit scheint keine Firma, Organisation oder Community bereit, die Veröffentlichung von X.Org-Server 1.21 vorzubereiten und zu übernehmen. Neben Red Hat ist Intel das einzige andere große Unternehmen, das überhaupt noch Ressourcen in X.org investiert. Bleibt nur zu hoffen, das Wayland bald alle gewünschte Funktionalität von X.org abbilden kann und die Entwicklung hin zu Wayland bei den Desktop-Umgebungen vorangeht.
Minix war 1995 mein Einstieg in die Unix-Welt und 1999 bin ich privat vollständig von DOS/Windows auf Linux mit X11 umgestiegen. Seit 2014 benutze ich Linux auch beruflich als Hauptbetriebssystem und Windows nur noch für die proprietäre Software meines Geräteparks.
Im August 2020 habe ich mir zu meinem Microsoft Surface Pro-4 einen 32-Zoll UHD Monitor geleistet und mich auf eine deutliche Verbesserung meines täglichen Arbeitsumfeldes gefreut – die Augen werden auch nicht besser und das Display vom Surface ist super in der Auflösung, aber doch recht klein. Die Erwartungen an das Gesamtsystem mit dem neuen Monitor waren hoch.
Mein bisheriges Arbeitsumfeld mit Manjaro und KDE 5.19.5 lief unter X11. Damit war für alle drei Monitore nur eine einheitliche Skalierung möglich. Im Klartext hieß 100% perfektes Bild auf dem neuen UHD und dem alten FullHD Schirm, dafür unleserlich klein auf dem Surface. Oder lesbar auf dem Surface und dafür verschwendete Auflösung auf den anderen beiden Schirmen – so schlecht sehe ich nun auch wieder nicht.
„Wayland kann das“, sagt das Netz
Die Lösung war schnell gefunden: Wayland, der neue Standard für die grafische Oberfläche – so stand es in zahlreichen Beiträgen im großen weiten Web. Diese sollte neben höherer Sicherheit auch mehr Performance und vor allem freie Skalierbarkeit je Monitor bieten.
Super – schnell die Wayland-Session dazu installiert und – das Chaos begann. Als erstes streikte gleich einmal Libreoffice, welches unter Wayland keine Menüleiste mehr anzeigte. Copy und Paste funktionierte nicht mehr, ebenso wenig Screenshots. Auch andere Programme verhielten sich sehr zweifelhaft und Systemabstürze stellten sich stündlich ein.
Als leidenschaftlicher Experimentierer (schließlich bin ich Chemiker) war das eine Herausforderung, der ich mich gerne stellte. So installierte ich mehrere Distributionen und schließlich auch unterschiedliche Desktop Environments auf einer eigenen Partition (keine VMs). Immer auf der Suche nach einer für den Produktiveinsatz stabilen Variante mit Wayland, die mir auch den gewohnten Komfort bot.
Erkenntnisse harter Arbeit
Nach einem knappen Monat muss ich ernüchternd feststellen, dass es die viel zitierte „eierlegende Wollmilchsau“ noch immer nicht gibt. Ich bin jetzt (wieder) bei KDE neon mit Plasma 5.20.0 gelandet, weil ich mich mit den anderen Desktop Environments nicht anfreunden kann und ich hier noch die „stabilste Kombination“ installieren konnte. Aus mir nicht nachvollziehbaren Gründen stellte sich Manjaro plötzlich als äußerst widerspenstig heraus und auch Fedora, SUSE Tumbleweed und diverse Ubuntu Varianten boten mir nicht das, was ich wollte.
Mit „stabilster Kombination“ möchte ich sagen, dass man zwar damit arbeiten kann, sich allerdings mit einigen Problemen abfinden muss. Gleich nach dem Login (SDDM) zeigen sich auf den Bildschirmen Darstellungsfehler im Aufbau der Desktops – sieht fast so aus, als ob Wayland die Position mit den drei Schirmen so lange über mehrere Versuche festlegt, bis es passt. Bei den Systemeinstellungen fehlt das Sub-Menü für die Verwaltung der Schriftarten. Nicht benötigte deinstallieren oder neue hinzufügen geht unter Wayland auf diesem Weg nicht.
Problembereich Screenshots
Screenshots sind nach wie vor ein Problem. Spectacle bei KDE funktioniert als User sporadisch, zumindest für die Aufnahme aller Bildschirme oder desjenigen, auf dem man sich gerade befindet. Für einen rechteckigen Bereich lässt einen das System einen Rahmen aufziehen, übernimmt dann allerdings einen ganz anderen Bildschirmbereich. Meist startet es allerdings erst gar nicht (Speicherzugriffsfehler). Als Root (mittels sudo auf der Kommandozeile) startet Spectacle problemlos (nachdem man Root den Zugriff mit xhost +si:localuser:root erlaubt hat) und schaltet dann bei der Auswahl auf drei vollkommen schwarze Bildschirme um. Dort darf man auswählen und bekommt als Ergebnis auch ein schwarzes Bild. Auch Flameshot funktioniert unter Wayland nicht – es zeigt das Icon im Systray an und das war’s dann auch schon. Kurz und Gut – noch immer keine Screenshots unter Wayland.
Startet man GwenView und navigiert durch die Unterordner kommt es zu Darstellungsfehlern (die Icon/Ordner-Größe stimmt nicht und sie überlappen sich), welche sich durch manuelle Größenänderung reparieren lassen. Nervig ist auch, dass Wayland die räumliche Anordnung der Bildschirme von Zeit zu Zeit vergisst und ich diese wieder neu einrichten muss (insbesondere, wenn ich mein Surface aus der Docking-Station nehme und später wieder in diese zurückbringe).
Copy & Paste Lotterie
Was mich jedoch am meisten stört, sind noch immer auftretende Abstürze der Plasma-Shell und das nur sporadische Funktionieren der Copy & Paste Funktion. Es ist wirklich lästig, wenn man Textschnipsel von einem Dokument in ein anderes übernehmen will und Wayland offensichtlich im Hintergrund würfelt, ob es die Information übernehmen soll oder nicht. Die Abstürze der Plasma-Shell fallen erst auf, wenn man ein Element aus der Kontrollleiste braucht und dieses nicht reagiert. Die stehen gebliebene Uhr zeigt dann an, wann die Shell abgeschmiert ist. Leider bin ich bis dato trotz Syslog noch nicht auf einen verbindlichen Anhaltspunkt gestoßen, woran es liegen kann. Dieses Problem habe ich auf zwei Varianten umschifft: einmal mit einem forschen killall plasmashell ; plasmashell & als Tastaturkürzel zum Wiederbeleben und zum anderen das Starten einer Debug-Shell mit sudo gdb -pid `pidof plasmashell`. Letzteres vermeidet die Abstürze, liefert dann aber leider keine Hinweise mehr.
Langer Rede kurzer Sinn
Ich habe die (schmerzliche) Erfahrung gemacht, dass sich Wayland und KDE offensichtlich nicht so vertragen, dass man von einem stabilen System für produktives Arbeiten sprechen kann. Ich bin mir bewusst, dass meine Konstellation (MS-Surface & Multi-Monitoring) durchaus herausfordernd ist, allerdings beherrscht X11 alles problemlos, bis auf die individuelle Skalierbarkeit.
In diesem Sinne verstehe ich die Schönrederei rund um Wayland nicht. Was nutzt es mir, wenn ein (inzwischen auch schon in die Jahre gekommenes) neues, moderneres und zukunftssicheres System, das seit 30 Jahren laufende X11 ersetzen soll, wenn es immer noch nicht stabil ist. Mehr Sicherheit, Performance und Skalierbarkeit sind schön, will ich haben – allerdings muss es funktionieren. Wenn so einfache Dinge wie Copy & Paste sowie Screenshots am Sicherheitssystem scheitern, lässt das bei mir die Alarmglocken klingeln – irgendetwas läuft hier nicht rund. Vielleicht ist das auch nur die Spitze vom viel zitierten Eisberg.
Während in wenigen Tagen Plasma 5.19.4 erscheint, macht sich mit Plasma 5.20 die nächste stabile Veröffentlichung der KDE-Desktop-Umgebung für die Freigabe am 13. Oktober bereit.
Fortschritte bei Wayland
Wie Nate Graham in seinem Blog berichtet, wird Plasma 5.20 wichtige Weiterentwicklungen bei der Nutzung mit Wayland bringen und weitere Lücken bei der Parität der Funktionen zwischen X11 und Wayland schließen.
Kompatible Anwendungen werden mit Plasma 5.20 endlich Gebrauch von Screen-Recording und Casting machen können. Die Grundlagen dazu wurden bereits vor mehr als zwei Jahren gelegt.
Screen-Recording per PipeWire
Das mit 5.20 freigegebene Protokoll basiert auf dem Multimedia-Framework PipeWire und ermöglicht die Verwaltung von Video-Feeds und Ausgabe-Streams. Somit können Anwendungen wie unter anderem OBS Studio den Bildschirm einer Plasma-Sitzung unter Wayland aufzeichnen. Des Weiteren kann auch Klipper nun die Zwischenablage von Wayland nutzen.
Client Side Decorations
Die Diskussion über Client-Side-Decorations (CSD) bei KDE währte über viele Jahre, bis Plasma mit 5.18 endlich CSDs in den Fenstermanager KWin integrierte. CSD erlaubt es im Gegensatz zu Server-Side-Decorations Anwendungen, ihre eigenen Fensterdekorationen zu zeichnen. Mit 5.20 wird dazu mit der Client-Geometrie eine weitere Geometrie eingeführt.
Die Paketverwaltung Discover soll nach dem Start wesentlich schneller als bisher eine nutzbare Oberfläche anbieten. Wayland merkt sich zudem jetzt das zuletzt benutzte Tastaturlayout.
Bei KDEs Standard-Screenshoter Spectacle wird in der Grundeinstellung der Mauszeiger nicht mehr mit aufgenommen. Die Seitenleiste zum Einbinden von Widgets erhielt eine dritte Spalte und erspart somit der Maus einige Zentimeter beim Scrollen durch das umfangreiche Angebot.
Die bisher unter Aktionen in Dolphins Kontextmenü angezeigten Funktionen, die jeweils von externen Plug-ins abhängen, werden künftig auf der obersten Ebene des Menüs angezeigt, sofern deren Zahl drei nicht übersteigt. Sind es mehr als 3, wird wie bisher das Untermenü Aktionen angezeigt.
Die Veröffentlichung von Debian 10 »Buster« steht in den nächsten Wochen oder Monaten bevor. Als Standard-Desktop kommt wie gehabt GNOME 3 zum Zug. Anders als bei Debian 9 »Stretch« soll dabei Wayland anstatt Xorg als Voreinstellung für das Display-Protokoll dienen.
Red Hat liefert Wayland als Standard aus
Das Wayland-Protokoll wird seit über 10 Jahren entwickelt und schon genauso lange als Ablösung für das überalterte Xorg gehandelt. Aber bisher liefern lediglich Fedora und seit einigen Tagen Red Hat Enterprise Linux 8 (RHEL) Wayland als Standard aus. Bereits im Februar habe ich mich gefragt, wann Wayland generell zum Standard wird.
Ubuntu weiß es noch nicht
Debian entschied sich für das derzeit stabile »Stretch« gegen Wayland als Standard. Canonical stellte mit Ubuntu 17.10 »Artful Aardvark« auf Wayland um, revidierte die Entscheidung jedoch für Ubuntu 18.04 LTS »Bionic Beaver« wieder und kehrte für die langzeitunterstützte Version zu Xorg als Standard zurück. Laut Canonicals Mastermind Mark Shuttleworth soll Ubuntu 20.04 LTS voraussichtlich die erste langzeitunterstützte Version mit Wayland am Steuer sein.
Debian Testing seit 2017
Anwender, die Debian Testing oder Unstable mit Gnome 3 als Desktopumgebung verwenden nutzen bereits seit August 2017 Wayland, sofern sie bei der Installation nicht bewusst Xorg ausgewählt haben. Zu diesen Anwendern zählt auch der Debian-Entwickler Jonathan Dowland, der vor einem Monat auf der Entwicklerliste die Frage stellte, ob Wayland bereit sei, als Standard für Debian 10 zu dienen. In seinem Blog plädiert er nun dafür, Debian 10 mit Xorg als Standard auszuliefern und den Wechsel auf Wayland erst mit dem Nachfolger zu vollziehen.
Kritik an Debians Entscheidung
Dowland wundert sich zunächst, dass es für die Entscheidung zu Wayland nicht die bei Debian übliche ausdauernde Diskussion gab, wie es etwa bei der Entscheidung für Systemd der Fall war. Als Argumente für eine Rückkehr zu Xorg dienen ihm zwei Fehler im ansonsten für ihn zufriedenstellenden Testablauf sowie die Befürchtung, Debian verliere zum jetzigen Zeitpunkt mit Wayland etwas von seiner Vielseitigkeit.
Verlust der Vielseitigkeit befürchtet
Ein Merkmal von Debian sei, dass man den GNOME-Desktop mit Anwendungen aus allen möglichen Ecken des Linux-Ökosystems paaren und so einen angepassten Workflow etablieren könne, Dowlands Befürchtung geht dahin, dass mit Wayland etwas davon verloren gehen wird. In dem Zusammenhang kritisiert er auch das automatische Entfernen von Paketen, die mit Wayland nicht kompatibel sind, wie im Fall des grafischen Paketmanagers Synaptic geschehen. Grund war in dem Fall, dass Synaptic generell als Root läuft, was den Prinzipien von Wayland zuwiderläuft
Zu viele Fehler in Wayland!?
Die Fehler, die Dowland anführt, sind keineswegs esoterisch und können im Alltag jederzeit auftreten. So stirbt etwa der gesamte Desktop samt Session-Manager, wenn die Root-Partition vollläuft. Das lässt sich auch nicht mit Werkzeugen wie systemctl beheben. Es passiert zwar auch unter Xorg, aber die Session bleibt dort laut Dowland zumindest erhalten.
Der zweite Fehler, den Dowland erwähnt tritt beim Drag&Drop von Firefox in den Dateimanager Nautilus auf. Danach werden laut Bugreport alle laufenden X-Applikationen daran gehindert, auf Maus- oder Tastatureingaben zu reagieren. Firefox lässt sich dann nicht mehr normal beenden und muss abgeschossen werden. Obwohl beide Bugreports bereits vom 26. April stammen, gibt es bisher keinerlei Reaktion darauf.
Die Diskussion auf der Mailingliste geht derweil weiter. Die Frage von Dowland, welche Kriterien das GNOME-Team zur Entscheidung für Wayland als Standard genutzt hat, bleibt bisher unbeantwortet.
Den Durchschnittsanwender im Auge behalten
Wer Debian kennt, wird sich vermutlich wundern, dass eine noch relativ unerprobte Technologie, die noch nicht fehlerfrei läuft, von der konservativen und auf absolute Stabilität ausgelegten Distribution relativ früh aufgegriffen wird. Dem durchschnittlichen Anwender ist es egal, was im Hintergrund läuft, solange alles funktioniert. Dieser Anwender wird sich bei der Installation deshalb meist nicht bewusst sein, dass Xorg als erprobte Alternative vielleicht die bessere Wahl ist.
Wayland oder Xorg?
Wenn Red Hat seinen Unternehmenskunden GNOME mit Wayland ausliefert, ist das nicht ein Beweis, dass Wayland bereit für den Mainstream ist? Sollte Debian bei Wayland als Standard bleiben und sich damit wie bei der Entscheidung für Systemd als zukunftsorientierte Distribution verhalten oder lieber Xorg den Vorzug geben, während Wayland die Alternative bleibt?
Kürzlich konstatierte ein Artikel im Netz die Tatsache, dass Wayland nach zehn Jahren Entwicklung immer noch nicht Standard sei. Dabei war eine schnelle und abrupte Umstellung nie das Ziel der Entwickler und ist technisch auch nicht möglich.
Nur bei Fedora
Die Entwicklung zum Display-Server-Protokoll Wayland wurde 2008 unter Federführung des damals bei Red Hat beschäftigten Kristian Høgsberg begonnen. Ziel war und ist die langsame Ablösung des in die Jahre gekommenen X-Servers. Seit Fedora 25 im Oktober 2016 wird Wayland dort als Standard eingesetzt. Aber das war’s auch schon, die erwartete kontinuierliche Ablösung des herkömmlichen X-Window-System (X11) durch Wayland scheint fürs Erste etwas ins Stocken geraten zu sein.
Dabei ist Wayland selbst ziemlich ausentwickelt, wie es in der Release-Ankündigung zu Version 1.16 heißt. Da sich Wayland und X11 aber im Funktionsumfang erheblich unterscheiden, bleibt drumherum noch einiges zu tun.
Aufgabe gleich – verschiedene Wege
Sowohl X11 als auch Wayland haben vorwiegend die Aufgabe, Programmen die Möglichkeit zu bieten, Grafiken auf Displays zu zeichnen. Sie tun dies auf sehr unterschiedliche Art und Weise. Während X11 als Netzwerkprotokoll nach dem Client-Server-Modell arbeitet und sich dabei vom Zeichnen und Bewegen von Bildern bis zu Benutzereingaben von Maus und Tastatur um alles kümmert, hat Wayland viel weniger zu tun.
Es sitzt als Protokoll zwischen einem Compositor und seinen Clients. Der Compositor sendet Eingabe-Events an die Clients. Die Clients rendern diese lokal und kommunizieren dann Videospeicherpuffer und Informationen über Updates dieser Puffer an den Compositor zurück.
Gefährliche Altlasten
X11 ist mittlerweile weit über 30 Jahre alt und schleppt Altlasten aus seiner Frühzeit mit, die heutzutage nicht mehr gebraucht werden, die aber zum Teil auch nicht entfernt werden können, weil sie zu tief im System verwurzelt sind. Fähigkeiten wie etwa das Zeichnen von Kreisen und Rechtecken oder das Verschieben von Fenstern regeln moderne Grafikbibliotheken heute wesentlich effizienter ohne dafür auf einen X-Server zurückgreifen zu müssen.
Moderne Clients erwarten vom Display-Server heute hauptsächlich die Zuteilung eines Bereiches, in den sie schreiben können und die Darstellung dieser Inhalte. Das entspricht der Arbeitsweise von Wayland. Allerdings müssen einige etablierte Funktionen, die das Client-Server-Modell von X11 ermöglichte, außerhalb von Wayland neu implementiert werden.
Einiges fehlt
So kann Wayland von Hause aus seinen Desktop nicht teilen, wie es Anwendungen wie WebRTC, Google Hangouts oder TeamViewer erwarten. Auch Remote-Desktop-Sitzungen per VNC oder RDP fallen in diese Kategorie. Diese Funktionalität muss bei Wayland von den Clients oder den Compositoren übernommen werden, da Wayland keine Rendering-API beinhaltet.
Probleme gibt es auch noch mit proprietären Grafiktreibern wie denen von Nvidia. GNOME und auch Plasma arbeiten am Nachrüsten, um die verbleibenden Defizite gegenüber X11 auszugleichen. Beim MATE-Desktop und bei Xfce ist Wayland-Integration geplant, bei Cinnamon zumindest in der Diskussion. Schon lange unterstützt wird Wayland bei Enlightenment. Auch bei den Browsern geht die Integration voran.
Ubuntu will nachziehen
Neben Fedora hatte auch Canonical den Schritt zu Wayland als Standard mit Ubuntu 17.10 »Artful Aardvark« vollzogen, ging aber mit dem langzeitunterstützten Ubuntu 18.04 »Bionic Beaver« wieder einen Schritt zurück und lieferte X11 als Standard aus und stellte Wayland alternativ als technische Vorschau bereit. Damals ging Mark Shuttleworth davon aus, dass Ubuntu 20.04 LTS voraussichtlich die erste langzeitunterstützte Version mit Wayland am Ruder sein werde.
Langsame Ablösung
Die Adaption von Wayland in den Distributionen wird nicht über Nacht voranschreiten, aber es bewegt sich was. So wird das im Sommer 2019 erwartete Debian 10 »Buster« in der Standard-Version mit GNOME vermutlich Wayland als Standard setzen. Von anderen Distributionen sind mir keine konkreten Pläne für Wayland als Standard bekannt. X11 wird uns also noch eine Weile begleiten.
