Trennung von Wayland-Compositor und Fenstermanager

 (isaacfreund.com)
2 Punkte von GN⁺ 2026-03-16 | 1 Kommentare | Auf WhatsApp teilen
  • In bisherigen Wayland-Umgebungen waren Compositor und Fenstermanager in einem einzigen Programm zusammengefasst; river 0.4.0 trennt sie jedoch in separate Prozesse
  • Das neue Protokoll river-window-management-v1 gibt dem Fenstermanager die vollständige Kontrolle über Richtlinien wie Fensterplatzierung und Tastaturkürzel und bewahrt dabei Frame-Perfektion sowie die Performance
  • Diese Struktur arbeitet ohne Eingabelatenz und gewährleistet selbst bei komplexen Tile-Layouts durch atomare Status-Updates sauberes Rendering
  • Dank der getrennten Struktur kann der Fenstermanager unabhängig entwickelt und neu gestartet werden und lässt sich auch in höheren Programmiersprachen leicht implementieren
  • Dieser Ansatz fördert eine größere Vielfalt an Fenstermanagern im Wayland-Ökosystem; river unterstützt bereits mehr als 15 kompatible Manager

Traditionelle Wayland-Struktur und rivers Ansatz der Trennung

  • Bisherige Wayland-Compositoren integrieren Display-Server, Compositor und Fenstermanager in einem einzigen Prozess
    • Der Display-Server leitet Eingabeereignisse weiter und übergibt Anzeige-Buffer an den Kernel
    • Der Compositor kombiniert die Buffer mehrerer Fenster zu einem finalen Bild
    • Der Fenstermanager übernimmt Benutzerrichtlinien wie Fensteranordnung und Tastaturkürzel
  • In der X11-Architektur läuft der Display-Server als separater Prozess, was zu unnötigen Roundtrips und Latenz führt
  • Wayland hat zur Lösung dieses Problems Server und Compositor zusammengeführt, doch die Kopplung auch des Fenstermanagers ist nicht zwingend erforderlich
  • river hebt diese Kopplung auf und trennt den Fenstermanager als eigenes Programm heraus

Designprinzipien des Protokolls river-window-management-v1

  • Entwickelt, damit der Fenstermanager maximale Kontrolle erhält und gleichzeitig die Vorteile von Wayland erhalten bleiben
  • Es sind keine Roundtrips bei jedem Frame oder Eingabeereignis nötig, es entsteht keine Eingabelatenz
  • Erhalt der Frame-Perfektion: Wenn Fenster neu geöffnet oder in der Größe verändert werden, wird eine Bildaktualisierung ohne Lücken oder Überlappungen sichergestellt
    • Das Rendering wird verzögert, bis alle Fenster neue Buffer eingereicht haben; nach Ablauf einer bestimmten Zeit wird jedoch per Timeout weiterverfahren
  • Je sauberer eine Anwendung implementiert ist, desto vollständiger ist die Frame-Synchronisierung möglich

Fenstermanagement-Struktur auf Basis einer State Machine

  • Das Protokoll trennt den Zustand in Fenstermanagement-Status und Rendering-Status
    • Fenstermanagement-Status: Fenstergröße, Vollbildstatus, Tastaturfokus, Tastaturkürzel usw.
    • Rendering-Status: Fensterposition, Reihenfolge, Dekorationen, Cropping usw.
  • Änderungen werden in atomaren Updates (manage/render sequence) gebündelt verarbeitet
  • Der Compositor startet die Sequenz; wenn es keine Zustandsänderungen gibt, bleibt der Fenstermanager im Wartezustand
  • Diese Struktur formalisiert Konzepte, die in river-classic, sway und anderen bereits implizit vorhanden waren, explizit und systematisch

Vorteile der getrennten Struktur

  • Entwickler von Fenstermanagern können sich auf Richtlinien konzentrieren, ohne einen kompletten Compositor implementieren zu müssen
  • Debugging und Neustart sind einfacher, ein Absturz des Fenstermanagers beendet nicht die gesamte Sitzung
  • Auch in garbage-collected Sprachen geschrieben entsteht kein Performanceverlust; der Betrieb bleibt ohne Frame-Verzögerung
  • Es gibt bereits mehr als 15 river-kompatible Fenstermanager, und es wird eine Vielfalt auf X11-Niveau erwartet

Einschränkungen und weitere Pläne

  • Das Protokoll unterstützt derzeit nur 2D-Desktop-Umgebungen, VR und Ähnliches werden nicht unterstützt
  • Komplexe visuelle Effekte (z. B. wackelnde Fenster) liegen außerhalb des Umfangs, einfache Animationen sind jedoch möglich
  • Künftig wird Unterstützung für Custom Shader geprüft, kurzfristig ist das jedoch nicht geplant
  • river 0.4.0 ist für den Alltagseinsatz ausreichend, vor dem Übergang zu Version 1.0.0 sind jedoch noch UX-Verbesserungen vorgesehen
  • Zur Fortführung der Entwicklung wird um Unterstützung über liberapay, GitHub Sponsors, Ko-fi gebeten

Beispiele und Galerie

  • Es werden verschiedene unter river laufende Fenstermanager vorgestellt
    • Canoe: klassischer Stacking-Fenstermanager
    • reka: Emacs-basierter Fenstermanager
    • tarazed: fokussierte Desktop-Umgebung
    • rhine: rekursives, modulares Fenstermanagement mit Animationsunterstützung
  • Darüber hinaus gibt es zahlreiche weitere river-kompatible Fenstermanager

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-03-16
Hacker-News-Kommentare

  • Es fällt mir schwer zu verstehen, warum es in den Kommentaren so viel Unzufriedenheit mit Wayland (dem Protokoll) gibt
    Bibliotheken wie wlroots haben die schweren Teile bereits übernommen, und jetzt bietet river Abstraktionen auf höherer Ebene
    Das Wayland-Projekt hätte solche Abstraktionen vielleicht früher bereitstellen können, aber ich denke, das hätte jeder tun können
    Letztlich bekommen wir diese Fortschritte kostenlos, also sehe ich keinen Grund, sich zu beschweren, nur weil es niemand anders für uns erledigt

    • Ich denke, das Problem begann damit, dass Wayland anfangs prinzipielle Positionen wie keine Screenshots eingenommen hat
      Auch Barrierefreiheit wurde als Sicherheitsrisiko betrachtet, was das Design erschwerte, und jetzt, wo wir ins Zeitalter von Agentic AI eintreten, könnte das ein interessanter Punkt werden
      Pipewire füllt zwar Lücken, die Wayland offengelassen hat, aber es gibt weiterhin die Wahrnehmung, dass ein benutzerfreundliches Design fehlt
      Trotzdem macht Wayland insgesamt zwei Schritte nach vorn, selbst wenn es zwischendurch ein oder zwei Schritte zurückgeht
    • Die eigentliche Ursache der Unzufriedenheit liegt meiner Meinung nach an der Wayland-Community, insbesondere an der Haltung des GNOME-Lagers
      Häufig heißt es sinngemäß „entweder auf meine Art oder gar nicht“, und auf externe Wünsche wird wenig flexibel reagiert
      Dass alles kostenlos bereitgestellt wird, ist zwar gut, aber wenn Xorg eingestellt wird und es keine Alternative gibt, ist dieses erzwungene Durchdrücken problematisch

  • Bei diesem Projekt hatte ich zum ersten Mal das Gefühl, dass Wayland keine Zeitverschwendung ist
    Ich finde nicht, dass ein Display-Server unbedingt auch noch das Fenstermanagement kompliziert übernehmen muss
    Dass Wayland ursprünglich Window Manager und Compositor zusammengelegt hat, war vermutlich einfach der Weg des geringsten Widerstands
    Die Remote-Zugriffsfunktionen bleiben allerdings ein Problem. Unter X11 funktionierte das gut, unter Wayland gab es viele Bugs

    • Bei X11 waren Xserver und Window Manager getrennt, weshalb Probleme wie die anfängliche Fensterplatzierung schwer zu lösen waren
      Wayland hat das durch die Integration gelöst, dafür sind aber andere Nebenwirkungen entstanden
    • Die meisten kleineren Wayland-Compositoren verwenden Bibliotheken wie wlroots oder smithay
      Die API-Grenzen sind gut gezogen, was das Teilen von Code einfach macht
      Ich frage mich, ob der 90-Grad-Rotationsbug ein Problem des Compositors oder von wlroots ist
    • Der Remote-Zugriff unter X11 war chaotisch. Unter Wayland kann man mit EGL oder Vulkan sauberer schichten, deshalb halte ich es eher für besser
    • Unter X11 war der Window Manager für die Dekorationen zuständig, weshalb eine Trennung Messaging und Konfiguration komplizierter macht
    • Vielleicht haben die Desktop-Umgebungen auch ihre eigenen Ökosysteme aufgebaut und dabei die Leiter hinter sich hochgezogen

  • Ich denke, hier wird gerade erst einer von Waylands vielen Designfehlern behoben
    Bis es gemeinsame Protokolle gibt und Window Manager den Reifegrad von X11 erreichen, dürften noch einmal 15 Jahre vergehen
    Und am Ende wird wahrscheinlich wieder jemand kommen, der „etwas Besseres“ bauen will, Wayland verwirft und neu anfängt

    • Deshalb halte ich heute Dinge wie WSL oder Virtualization Framework für die realistischere Lösung für Desktop-Linux
      Nach viel Ärger mit UEFI bin ich schließlich zu Samsung DEX gewechselt
    • Selbst wenn man Wayland neu bauen würde, sähe das Ergebnis wohl ähnlich aus
      Die Grenzen sind aus meiner Sicht weniger technisch als vielmehr politisch

  • Als Linux-Nutzer seit 25 Jahren bin ich seit dem Wechsel zu Wayland vor 5 Jahren zufrieden, vor allem weil ich seitdem kein Tearing mehr habe
    Für Entwickler mag dadurch mehr Arbeit entstehen, aber aus Nutzersicht ist es eindeutig eine Verbesserung

    • Trotzdem vermisse ich die Funktion zum Fenstershading
      Ich frage mich, ob ich darüber irgendwann genauso weiterreden werde wie Leute, die früher den CDE-Funktionen nachtrauerten

  • River war schon vor der Trennung großartig. Ich freue mich auf die weitere Entwicklung
    Ich bin kurzzeitig zu Niri gewechselt, werde aber irgendwann wohl zurückkehren
    Für Xmonad-Nutzer dürfte River am besten passen

    • Ich nutze ebenfalls Xmonad, und Hyprland konnte den Master/Slave-Stack nicht richtig verarbeiten
      Mich würde interessieren, ob in River neue Fenster über dem aktuell ausgewählten Fenster eingefügt werden
      Und nach der Trennung würde ich auch gern wissen, wie das Projekt auf Window-Manager-Seite heißen wird

  • Im Grunde erfinden wir die Funktionen von X11 Stück für Stück neu
    Vielleicht kann ein Wayland-Fenster irgendwann sogar seine eigene Position kennen

    • Idealisten sträuben sich offenbar immer noch dagegen, auch nur ein virtuelles 2D-Pixelraster explizit festzulegen
      Wahrscheinlich wird man darauf noch eine Weile warten müssen
    • Allerdings läuft der Großteil von GNU/Linux inzwischen ohnehin auf headless Servern oder Embedded-Systemen, daher dürfte das keine große Bedeutung mehr haben
      Den Desktop werden wohl Android, ChromeOS oder VMs auf Windows/macOS übernehmen

  • Ich nutze einen vollständig angepassten River-Window-Manager
    Unter Hyprland war standardmäßig nur BSP-Tiling möglich, was unpraktisch war, während ich in River genau das gewünschte gleichmäßige Tiling umsetzen kann
    Diese Trennung hat meinen Workflow stark verändert

    • Wer gleichmäßiges Tiling möchte, sollte sich hy3 ansehen
      Ich war früher i3-Nutzer, und dank hy3 konnte ich Hyprland verwenden
    • Ich hatte unter Hyprland ähnliche Probleme und bin am Ende zu Niri gewechselt, wo ich eine stabile Entwicklungsumgebung gefunden habe
      Meine Konfiguration steht in den dotfiles
    • Ich würde gern wissen, was BSP ist

  • Soweit ich weiß, war eines der zentralen Konzepte von Wayland die Integration von Window Manager und Compositor
    Ich frage mich, warum man das so entworfen hat

    • Wenn ein Window Manager als separater Prozess asynchron kommuniziert, entstehen Frame-Sync-Probleme
      Wayland verarbeitet das synchron und beseitigt dadurch visuelle Inkonsistenzen
    • Wayland hat alles in einen einzigen Prozess gepackt, um Context Switches zu minimieren
      Dieses neue Protokoll ist ein Versuch, den Leistungsvorteil beizubehalten und gleichzeitig Grafikserver und Window Manager zu trennen

  • Dass man unter Wayland keine austauschbaren Plug-in-Window-Manager einfach ersetzen kann, ist im Vergleich zu X11 für mich der größte Verlust
    Menschen, die solche Probleme lösen wollen, sind wirklich selten und wertvoll

    • Wenn man jahrzehntelang denselben Window Manager verwendet hat, ist der Umstieg auf Wayland schwer, solange es keine vollständige Ersatzschnittstelle gibt
      Ich hoffe, dass Ebenen wie River oder Wayback diese Rolle übernehmen können
    • Diese Einschränkung ist auch ein großes Hindernis für die Entwicklung neuer WM- und DE-Konzepte
      Ich habe selbst experimentelle Desktop-Ideen, muss aber wegen der schnellen Iteration zwangsläufig mit X11 anfangen
      Wayland hat nach wie vor Designschwächen
    • Eigentlich reicht es schon, wenn nur eine Implementierung eine WM-Erweiterungs-API bereitstellt
      Der Standard muss keine bestimmte Struktur erzwingen
    • Ideal wäre vermutlich eine hierarchische Struktur mit einem Root-Wayland-Server, darunter benutzerspezifischen Wayland-Servern, darin einem X11-Server und darüber dem Window Manager

  • Ich nutze seit 15 Jahren i3, und bei solchen Projekten frage ich mich jedes Mal, wofür Wayland überhaupt nötig ist
    X11 hat zwar Nachteile, aber fast alles, was ich will, ist damit möglich
    Wayland wirkt immer so, als bringe es ständig Reibung mit sich

    • Ich verwende Wayland seit KDE 5, und das HiDPI-Scaling war hervorragend
      Für mich als Laptop-Nutzer war das ein großer Vorteil, und Unterstützung für VRR oder HDR ist ebenfalls deutlich einfacher als unter X.org
    • Aus Nutzersicht funktioniert es einfach
      DPI-Anpassung pro Display, kein Tearing und das standardmäßige Blockieren unerlaubter Bildschirmaufnahmen durch Apps sind damit von Haus aus gelöst
    • Ich bin von i3 zu sway gewechselt, ebenfalls wegen der DPI-Unterstützung
      Dass ich nicht mehr an der Xorg.conf herumarbeiten muss, hat meine Lebensqualität verbessert
      Ich nutze bis heute unterschiedliche Skalierungsfaktoren je Monitor
    • Unter X11 waren hohe Bildwiederholraten immer ein Problem
    • Ein Problem, das ich kürzlich hatte, war, dass Wayland DeviceEvent nicht unterstützt
      Ich brauche eine Funktion, bei der ein Fenster auch im inaktiven Zustand Eingaben empfangen kann, wobei nur Mausbewegungen ausnahmsweise funktionieren
      Am Ende habe ich auf Window Event umgestellt, aber es bleibt unbequem