LN-Waschpress

Schlagwort: Wayland

  • Debian 10 »Buster« und Wayland

    Debian 10 »Buster« und Wayland

    Debian 10 Buster und Wayland
    Debian 10 Artwork

    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?

  • Wann wird Wayland zum Standard?

    Wayland als Standard
    Bild: The Wayland Display Server Logo | Quelle: Kristian Høgsberg

    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.

  • Firefox und Chromium erhalten Wayland-Support

    Firefox und Chromium erhalten Wayland-Support

    Vor acht Jahren wurde im Bugtracker von Mozilla ein Bug eröffnet mit dem Bestreben, Firefox für Linux auf Wayland zu portieren. Doch dann wurde  Firefox über Jahre an der Basis umgebaut. Soeben gab Mozilla-Mitarbeiter Mike Hommey, der auch Debian-Maintainer für Firefox ist, bekannt, dass Firefox Nighlies für Linux ab sofort mit Wayland-Unterstützung  ausgeliefert werden. Das gilt ab der Version Firefox Nightly vom 15.11. Anwender konnten Firefox auch bisher bereits mit Wayland-Unterstützung bauen und Fedora bietet den Browser schon länger für Wayland an. Die von Mozilla bisher ausgelieferten Nightlies setzten in einer Wayland-Sitzung allerdings noch auf XWayland.

    Noch experimentell

    Da die Unterstützung für den Nachfolger von X11 noch experimentell ist, ist sie noch nicht standardmäßig aktiviert und muss erst freigeschaltet werden. Dazu muss in einer Wayland-Sitzung die Umgebungsvariable GDK_BACKEND=wayland in /etc/environment oder der ~/.bashrc eingetragen werden. Nach dem sourcen der entsprechenden Datei kannst Du testen, ob das erfolgreich war, indem Du in about:support  überprüfst, ob bei WebGL 1 Driver WSI Info oder WebGL 2 Driver WSI Info anstatt GLX jetzt EGL  steht.  Ein Bugreport von Hommey soll eine einfachere Möglichkeit der Überprüfung anregen.

    Bei Chromium auch noch Alpha

    Es ist wahrscheinlich noch ein langer Weg, bis Firefox den Wayland-Support standardmäßig aktiviert, aber laut Hommey wurde hiermit ein wichtiger Meilenstein erreicht. Auch Google arbeitet schon lange an Wayland-Unterstützung für Chromium. Erstmals taucht die Absicht in einem Bugreport eines Entwicklers im Jahr 2011 auf. Auch hier ist die Portierung noch nicht über das Alpha-Stadium hinausgekommen. Die Hauptarbeit leistet hier seit Jahren nicht etwa Google, sondern Intel und das galizische Consulting-Unternehmen Igalia. Die Galizier haben den Stand der Entwicklung auf einem Vortrag auf der FOSDEM im Januar 2018 vorgestellt, die Folien stehen zum Download bereit.

  • Aktuelle Entwicklungen bei Fedora Workstation

    Screenshot: FThommes

     

    In der Fedora-Experimentierküche brodeln zu jeder Zeit interessante Entwicklungen. Red-Hat-Mitarbeiter Christian Schaller berichtet in unregelmäßigen Abständen über solche Entwicklungen, die dann in absehbarer Zeit in Fedora Workstation verfügbar sein werden. Jetzt bietet die kürzlich zu Ende gegangene GNOME-Entwicklerkonferenz GUADEC den Anlass für Schaller, einen neuen Bericht zu veröffentlichen.

    Wayland im Hintergrund

    Bei den meisten derzeitigen Projekten steht Wayland im Hintergrund. So etwa auch bei Remote Desktop und Desktop-Sharing. Hier stellen Unterschiede von X11 zum von Fedora Workstation seit einigen Veröffentlichungen als Standard eingesetzten Wayland-Protokoll die Entwickler vor neue Herausforderungen.

    Entfernte Desktops laden

    Jonas Ådahl arbeitet derzeit an Remote-Desktop für die GNOME-Shell. Die für Ende Oktober erwartete Veröffentlichung von Fedora 29 Workstation soll eine VNC-basierte Implementierung des Remote-Desktop bieten, weitere Protokolle wie etwa Spice sollen folgen. VNC ist zwar ziemlich veraltet, ist trotzdem noch recht weit verbreitet und anspruchslos im Einsatz. Um die Wayland-Sitzung über VNC zu teilen kommt das Multimedia-Framework PipeWire zum Einsatz, das vom GStreamer-Pionier Wim Taymans entwickelt wird.

    Desktop-Sharing per WebRTC

    Jan Grulich, Tomas Popela und Eike Rathke arbeiten seit geraumer Zeit am Desktop-Sharing unter Wayland mit Firefox und Chromium unter Zuhilfenahme von WebRTC. Auch hier spielt PipeWire das Bindeglied, indem die Browser jeweils ein PipeWire-Backend erhalten. Eine gepatchte Firefox-Version steht bereits seit einiger Zeit zum Testen für Fedora 28 und Fedora Rawhide bereit.

    PipeWire

    Auf der GUADEC 2017 hielt Entwickler Wim Taymans einen Vortrag über die Ideen hinter und den Entwicklungsstand von PipeWire. Hier wird unter anderem beständig an der Nachbildung der Funktionalität des professionellen Audio-Servers Jack gearbeitet. Die Player Totem und Rhythmbox können zum Abspielen von Audio über PipeWire mit dem PulseAudio-GStreamer-Plugin genutzt werden, nachdem ein Ersatz für die libpulse.so implementiert wurde.

    Im Herbst wird ein PipeWire und Linux Audio Hackfest stattfinden, bei dem die Teams von  PipeWire, GStreamer, Totem, GNOME Control Center, PulseAudio und Jack über die weitere Entwicklung von PipeWire diskutieren.

    GNOME Builder im Container

    GNOME Builder, die integrierte Entwicklungsumgebung, die seit einiger Zeit in den GNOME-Desktop integriert ist, wird maßgeblich von Christian Hergert entwickelt. Die derzeitige Entwicklung geht in Richtung Unterstützung für die Entwicklung hin zu Embedded-Geräten wie dem kommenden Linux-Smartphone Purism 5. Christian erwähnte zudem in seinem GUADEC-Vortrag, dass Builder wahrscheinlich die erste »Container Native IDE«  der Welt ist, indem es einerseits mit dem Ziel entwickelt wird, als Flatpak verteilt zu werden, als auch, Flatpaks als primäres Ausgabeformat zu erstellen.

    https://www.youtube.com/watch?v=Z9hPtg-caJ0
  • Screensharing unter Wayland erklärt

    Screensharing unter Wayland erklärt

    Bereits im März berichteten wir über die Bemühungen von Red-Hat-Entwickler Jan Grulich, Screensharing für KDE-Plasma unter Wayland zu realisieren. Da Wayland im Gegensatz zu X11 kein Netzwerkprotokoll ist, müssen für das Screensharing unter Wayland neue Wege gefunden werden. Dafür hatte Grulich bereits Backends in Form von xdg-desktop-portal und xdg-desktop-portal-[kde/gtk] für KDE-Plasma und die GNOME-Shell geschrieben und das Audio-Video-Framwork PipeWire zum Streamen auserkoren. Was fehlte, war eine Anwendung, mit der ein User Screensharing auch nutzen konnte.

    WebRTC als Screensharing-Anwendung

    Seit einigen Wochen arbeitet Grulich mit zwei Kollegen, daran, für diese Aufgabe die in Browsern verwendete Videochat-Technik WebRTC nutzbar zu machen, wie er jetzt in seinem Blog berichtet. WebRTC verwendet eine Klasse namens DesktopCapturer, die sowohl unter X11 als auch den Gegenstücken bei Windows oder macOS Verwendung findet. Diese Klasse hat das Team nun für Wayland aufgebohrt.

    Alle Bauteile zusammen

    Die Umsetzung dieser Idee unter Verwendung der Portals für Plasma und GNOME sowie PipeWire als Streaming-Agent konnte relativ einfach umgesetzt werden. Dank der Backend-Portals wird diese Technik auch in Sandboxen in Flatpak oder Snap funktionieren. Allerdings müssen die leicht unterschiedlichen Herangehensweisen der Browser an WebRTC noch angepasst werden, bevor der Code produktiv genutzt werden kann. Für Neugierige hat Grulich für Fedora ein Repository aufgesetzt, dass einen Firefox mit den entsprechenden Änderungen enthält.  Voraussetzung ist lediglich ein funktionierendes PipeWire.

    Screensharing unter Wayland

    Ein zweiter Blogeintrag von Grulich geht in die Praxis und erläutert schrittweise, wie Screensharing mit Wayland bereits jetzt auch außerhalb von Fedora genutzt werden kann. Wird der Plasma-Desktop verwendet, so wird hier Version 5.13.2 vorausgesetzt. Sowohl die GNOME-Shell als auch Plasma brauchen noch ein wenig Anpassung, wie Grulich erläutert. Der Blogeintrag bietet zudem für Interessierte am Ende einige Verweise, die das grundlegende Verständnis der verwendeten Techniken vertiefen sollen.

  • Plasmas Wayland-Session lernt Screen-Sharing

    Plasmas Wayland-Session lernt Screen-Sharing

    Wayland Screen-Sharing
    Bild: Fedora

    Ein generelles Defizit von Wayland ist das Fehlen von Netzwerktransparenz. Diese aus Sicherheitserwägungen fehlende Funktionalität bedeutet, dass das Wayland-Protokoll keine Lösung für etablierte Techniken wie Screen-Recording und -Sharing mitbringt. Diese Funktionalität muss bei Wayland über die Compositoren gegeben sein. Fedora- und KDE-Entwickler Jan Grulich arbeitet an der Bereitstellung dieser Funktionalität unter Plasma. Hierbei kommt neben einer neuen API auch das neue Multimedia-Framework Pipewire ins Spiel.

    API für Wayland Screen-Sharing

    Eine der Gründe für die Entwicklung von Pipewire war die Unterstützung von gewohnter Funktionalität, die unter anderem bei Flatpak und Wayland aus Sicherheitsaspekten einem neuen Ansatz folgen muss. Die benötigte API für Screen-Recording und -Sharing und Remote-Desktop wurde unlängst in das xdg-desktop-portal eingefügt. Mit Hilfe dieser API können Anwendungen nun auf Ihren Bildschirminhalt in Wayland-Sitzungen oder in Sandboxen wie bei Flatpak zugreifen.

    [su_slider source=“media: 4385″ link=“image“ width=“700″ height=“460″ mousewheel=“no“ autoplay=“0″ speed=“0″]

    Mit verschiedenen Backend-Implementierungen wie xdg-desktop-portal-kde oder xdg-desktop-portal-gtk muss nur eine einzige API unterstützt werden, um alle Desktops anzusprechen. Das Screen-Cast-Portal beispielsweise funktioniert so, dass der Client zunächst eine Sitzung mit der Backend-Implementierung des xdg-desktop-portal (xdp) erstellt.

    Pipewire liefert den Stream

    Der Benutzer erhält dann einen Dialog zur Freigabe des Bildschirms, den er freigeben möchte und startet damit die Bildschirmfreigabe. Sobald er das getan hat, erstellt die xdp-Backend-Implementierung einen Pipewire-Stream, sendet die Antwort an den Client mit Stream-ID zurück und der Client kann sich mit dieser ID mit dem Stream verbinden und seinen Inhalt abrufen.

    Grulich hat vor wenigen Tagen die Unterstützung für das Screen-Cast-Portal für das xdg-desktop-portal-kde in den KDE-Phabricator eingebracht und wartert derzeit auf das Ergebnis des Reviews. Er hofft, der Code könne früh genug für Plasma 5.13 freigegeben werden, dessen Veröffentlichung für den 12. Juni geplant ist.

  • Multimedia-Framework PipeWire auf gutem Weg

    Multimedia-Framework PipeWire
    Bild: Fedora

     

    Fedora 27 lieferte erstmals das neue Multimedia-Framework PipeWire aus. Die Anwendung soll für Audio und Video das leisten, was heute PulseAudio heute für Audio zu bieten hat. Darüber hinaus sollen auch professionelle Szenarien unter Einbeziehung des Soundservers Jack abgedeckt werden, die über die Funktionalität von PulseAudio hinausgehen. Begonnen hat die Entwicklung bereits vor einigen Jahren.

    GStreamer als Vorbild

    Entwickler Wim Taymans, der für Red Hat arbeitet, hatte bereits bei der Entwicklung von GStreamer federführend mitgearbeitet. Mit dem Aufkommen des alternativen Paketmodells Flatpak suchte er nach einer Möglichkeit, diesen Desktop-Containern – denn nichts anderes ist Flatpak – die Soundausgabe per PulseAudio zu ermöglichen. Im Anschluss begann er die Arbeit an PulseVideo, um das Gleiche auch für Bewegtbilder umzusetzen.

    Im Endeffekt fiel die Entscheidung, Audio und Video in einem Framework zu bündeln, das den Namen PipeWire erhielt. Jetzt hat Red-Hat-Kollege Christian Schaller die gerade stattfindende Fedora-Entwicklerkonferenz DevConf 2018 im tschechischen Brno zum Anlass genommen, anlässlich eines Gesprächs mit Wim Taymans über die Fortschritte bei PipeWire in seinem Blog zu berichten.

    Flatpak und Wayland profitieren

    Mittlerweile sind es nicht nur mehr Flatpak oder Container im Allgemeinen, die auf ein modernes Framework angewiesen sind, um den Zwängen einer Sandbox gerecht zu werden und containerisierten Anwendungen die Ausgabe von Audio und Video über den Host trotzt Restriktionen zu ermöglichen. Auch Wayland braucht im Bereich Multimedia neue Lösungen, will es die Funktionalität von Xorg besser abdecken.

    Das Anzeige-Protokoll Wayland ist mit mehr Augenmerk auf Sicherheit konzipiert als das rund 30 Jahre alte Netzwerkprotokoll X11. Aus diesem Grund wurde auch standardmäßig keine Netzwerktransparenz implementiert. Das bedeutet, dass das Wayland-Protokoll von Hause aus heute selbstverständliche Dinge wie Screensharing und -recording oder Remote Desktop per RDP oder VNC nicht unterstützt. Es gibt Anstrengungen,  auch für Oberflächen von Wayland-Anwendungen die Verwendung über das Netzwerk zu realisieren. Eine davon nennt sich Waltham und wird bei Collabora entwickelt. Hier geht es aber in erster Linie vorerst nicht um den Desktop, sondern um den Automobilbereich.

    Screensharing und Remote Desktop

    Eine weitere Entwicklung in diese Richtung, die wiederum PipeWire ins Spiel bringt, wird von Red Hats Jonas Ådahl vorangetrieben und soll diese Funktionalität für GNOME zurückbringen. Da die Funktion im Compositor verankert ist, wird sie auch von anderen Desktop-Umgebungen nutzbar sein, die Wayland einsetzen. Das ist zwar alles noch im experimentellen Stadium, aber PipeWire beherrscht bereits rudimentär das Teilen von Geräten, wie Entwickler Taymans am Beispiel der Videoanwendung Cheese und PipeWire im Terminal demonstrierte. Zwei Anwendungen teilen sich dabei eine Webcam ohne sich gegenseitig zu stören. Dabei kommt ein PipeWire-GStreamer-Plugin zum Einsatz, was die Anpassung an die jeweilige Anwendung übernimmt.

    Als Nächstes soll PipeWire zeitnah an Firefox und Chrome angepasst werden um Konferenzsoftware damit unter Wayland lauffähig zu bekommen. Der Sound-Server Jack für professionelle Ansprüche wie etwa geringe Latenzen wurde mittlerweile als Protokoll auf PipeWire draufgesetzt, sodass kein extra Jack-Server mehr vonnöten ist. Auf der Cosumer-Seite ist Bluetooth-Untzerstützung gegeben, wobei ein PipeWire-Bluetooth-Modul sich direkt mit dem  Bluez-Bluetooth-Framework verbindet.

    Aussichten

    PulseAudio-Applikationen sollen nach den Plänen der Entwickler zunächst Sound über PipeWire ausgeben. Für GStreamer-Apps stellt sich die Frage nicht, da sie nativ PipeWire nutzen. Für Apps, die noch ALSA verlangen, soll es ein PipeWire-ALSA-Layer geben so wie es jetzt ein PulseAudio-ALSA-Layer gibt. PulseAudio soll im späteren Verlauf einmal überflüssig werden, was jedoch einige Jahre dauern wird. Für das im Mai anstehende Fedora 28 soll zumindest der Video-Part ausgeliefert werden, weitere Schritte sollen mit den nächsten Veröffentlichungen folgen.