Die Sway-Entwickler haben am 25. Mai 2026 nach knapp einem Jahr Entwicklungszeit Version 1.12 veröffentlicht. Das wichtigste Feature ist HDR10-Unterstützung über den Vulkan-Renderer, ergänzt um Window-Capture für einzelne Fenster, eine ganze Reihe neuer Wayland-Protokolle und die endgültige Verabschiedung des Konzepts, dass Sway auf nicht unterstützten GPUs gar nicht erst startet. Für die Multimedia-zentrierte Linux-Welt ist das Update bemerkenswert, weil HDR-Wiedergabe und Color Management auf einem Tiling-Window-Manager zum ersten Mal über eine reine Modifikation hinausgehen und in der offiziellen Sway-Linie landen. Wer auf Debian eine schlanke, scriptbare Wayland-Umgebung sucht und trotzdem auf HDR-Inhalten arbeiten oder sie produzieren möchte, hat damit eine ernstzunehmende Alternative zu KDE Plasma 6.6 bekommen.
HDR10 in einem Tiling-Compositor ist eine kleine Sensation
Tiling-Window-Manager wurden lange als Werkzeuge für Tastatur-getriebene Entwickler-Workflows verstanden, nicht als Grundlage für Multimedia-Pipelines. HDR-Wiedergabe und Color Management waren Funktionen, die man entweder über aufwendige Eigenbau-Konfigurationen erkaufte oder in größeren Desktop-Umgebungen wie KDE Plasma fand. Sway 1.12 ändert diese Wahrnehmung. Beim Start mit dem Vulkan-Renderer, der über die Option WLR_RENDERER=vulkan gesetzt wird, schaltet Sway HDR10-Pipeline-Funktionalität frei. Das bedeutet, dass HDR-fähige Inhalte in HDR-Containern an einen HDR-fähigen Monitor durchgereicht werden können, statt unterwegs in eine SDR-Repräsentation gekürzt zu werden.
Die zugrundeliegende Arbeit findet weitgehend in wlroots 0.20 statt, der Bibliothek, auf der Sway aufbaut. Mit wlroots 0.20 sind die Wayland-Protokolle color-management-v1 und color-representation-v1 in den Compositor-Unterbau gewandert. Sway 1.12 ist die erste stabile Veröffentlichung, die diese Schicht produktiv nach oben durchreicht. Vergleichbare Compositoren wie Labwc 0.20 bekommen den gleichen Sprung, weil sie ebenfalls auf wlroots 0.20 aufsetzen.
Warum Vulkan und nicht OpenGL
Der HDR-Pfad läuft ausschließlich über den Vulkan-Renderer von wlroots. Der ältere OpenGL-ES-Renderer bietet diese Funktionalität nicht. Vulkan ermöglicht eine deutlich präzisere Steuerung über Farbräume, Tone-Mapping und HDR-Metadaten, was für eine sinnvolle HDR-Wiedergabe Voraussetzung ist. Wer Sway 1.12 auf einer Maschine ohne stabilen Vulkan-Pfad betreibt, sieht weiterhin das gewohnte SDR-Verhalten. AMD-Karten ab RDNA 2, Intel-Arc-GPUs sowie Nvidia-Karten mit aktuellem proprietären Treiber 610 erfüllen die Vulkan-Anforderung problemlos. Auf älterer Hardware bleibt OpenGL die Fallback-Option.
Ergänzend zum HDR-Pfad bringt Sway 1.12 mit der Kommandozeilen-Option –device-primaries für das output color_profile-Kommando eine Möglichkeit mit, die Farb-Primärkoordinaten aus dem EDID-Block des angeschlossenen Bildschirms zu übernehmen. Damit lässt sich der Output an die tatsächlichen Farbeigenschaften des Monitors anpassen, ohne externe Profil-Tools.
Window-Capture für einzelne Fenster
Der zweite große Schritt von 1.12 betrifft Capture-Workflows. Sway kann jetzt einzelne Fenster aufnehmen, nicht mehr nur ganze Outputs oder Regionen. Für Screencasting, Tutorial-Aufnahmen, Bug-Reports und Streaming ist das einer der häufigsten Wünsche aus der Community gewesen. Anwendungen wie wf-recorder, OBS Studio oder grim können den neuen Capture-Pfad über die wlr-screencopy-Erweiterungen ansprechen und bekommen damit ein fokussiertes Fenster-Capture, das den Rest des Desktops unangetastet lässt.
Für Multimedia-Produktion ist das insbesondere bei Aufnahmen wichtig, in denen ein bestimmtes Werkzeug wie Krita 6.0, Blender 5.x oder DaVinci Resolve sauber isoliert dokumentiert werden soll, ohne dass Sway-Bar-Elemente, andere Workspaces oder Hintergrund-Anwendungen ins Bild rutschen.
Weitere Wayland-Protokolle, die jetzt unterstützt sind
Neben den Color-Management-Protokollen schaltet Sway 1.12 drei weitere Erweiterungen frei. xdg-toplevel-tag-v1 erlaubt Anwendungen, ihren Fenstern zusätzliche Tags mitzugeben, die Compositoren für intelligenteres Window-Management nutzen können. ext-workspace-v1 standardisiert den Umgang mit Workspaces zwischen Wayland-Clients, sodass Status-Bars, Panels und Skripte die Workspace-Liste zuverlässig abfragen können, ohne auf Compositor-spezifische Schnittstellen angewiesen zu sein. wl_fixes räumt eine Reihe von Detail-Inkonsistenzen im Wayland-Protokoll auf, die sich über die Jahre angesammelt haben.
Praktisch heißt das, dass Werkzeuge wie waybar, swayidle, mako oder externe Wayland-Capture-Tools nach und nach von einer breiteren Protokoll-Basis profitieren werden. Distributionen brauchen dafür allerdings ebenfalls aktuelle Versionen dieser Begleit-Tools.
Was Debian Trixie und Sid für ein HDR-Sway-Setup brauchen
Sway 1.12 lässt sich auf Debian erst dann produktiv betreiben, wenn drei Komponenten aufeinander passen. Erstens Sway 1.12 selbst, das in Debian Testing und Sid in den kommenden Wochen ankommt und über Backports auch für Trixie verfügbar werden dürfte. Zweitens wlroots 0.20, weil Sway 1.12 darauf aufbaut und ältere wlroots-Versionen den HDR-Pfad nicht mitbringen. Drittens Mesa in einer Version ab 26.1 für AMD-GPUs oder ein aktueller Nvidia-Treiber 610.
Wer das Setup neu aufzieht, sollte zudem libdrm und mesa-vulkan-drivers in aktuellen Versionen installieren, ebenso firmware-amd-graphics oder firmware-misc-nonfree für Nvidia-Karten. Sway selbst startet mit Vulkan-Renderer über die Umgebungsvariable WLR_RENDERER=vulkan, die in einer Systemd-User-Unit, einem Display-Manager-Eintrag oder einem Wrapper-Skript gesetzt werden kann. Für HDR-Inhalte muss das angeschlossene Display HDR10 unterstützen, was bei aktuellen OLED-TVs, modernen QD-OLED-Monitoren und vielen Mini-LED-Panels der Fall ist.
Display-Manager und Startverhalten
Bisher konnte Sway nur über tty oder eine reine Display-Manager-Sitzung gestartet werden, und auf einigen GPU-Konstellationen brach es den Start direkt ab. 1.12 ändert das in zwei Punkten. Erstens gibt es offiziell unterstützten Display-Manager-Start, was die Integration in GDM, SDDM oder LightDM auf Debian deutlich vereinfacht. Zweitens lehnt Sway den Start auf nicht-unterstützten GPUs nicht mehr ab. Wer eine Nvidia-Karte mit proprietärem Treiber einsetzt, sah Sway bisher mit einer harten Fehlermeldung. Jetzt erscheint nur noch ein Warnhinweis, und Sway startet trotzdem. Das macht die Plattform zugänglicher für gemischte Hardware-Setups, in denen Sway nur als sekundäre Wayland-Sitzung läuft.
Wie Sway 1.12 gegenüber KDE Plasma und GNOME steht
KDE Plasma 6.6 hat 2026 einen großen Schritt in Richtung Color Management gemacht und ist derzeit die ausgereifteste Wayland-Umgebung für HDR und ICC-Profile auf Linux. Sway 1.12 ist nicht so vollständig, aber deckt einen anderen Punkt im Markt ab. Wer scriptbare, ressourcensparende Tiling-Workflows mit voller Tastatursteuerung will und trotzdem HDR-Inhalte ansehen oder bearbeiten möchte, hat in Plasma keine direkte Entsprechung. Plasma ist für Maus-basierte Floating-Window-Workflows ausgelegt, Sway für eine klassische Tiling-Logik mit minimaler UI-Belastung.
In der Praxis ergeben sich aus dieser Unterscheidung zwei Empfehlungen. Wer hauptsächlich produktiv mit Krita, DaVinci Resolve oder einer kalibrierten Foto-Pipeline arbeitet und auf maximale Anwendungs-Integration setzt, bleibt bei KDE Plasma 6.6. Wer auf einem Notebook oder einer Headless-Workstation mit Multi-Monitor-Setup arbeitet und die Effizienz eines Tiling-WMs nicht aufgeben möchte, kann Sway 1.12 für HDR-Wiedergabe und einfache Color-Pipelines erstmals ernsthaft in Betracht ziehen. GNOME-Mutter zieht beim Color-Management-Protokoll noch nach, ist Stand Frühjahr 2026 aber noch nicht auf der Höhe von KWin oder Sway-Vulkan.
Multimedia-Anwendungen, die jetzt auf Sway sinnvoll laufen
Krita 6.0 ist der erste großer Profiteur, weil es das Wayland-Color-Management-Protokoll vollständig implementiert. In Verbindung mit Sway 1.12 lässt sich damit eine HDR-Mal-Pipeline aufbauen, die zuvor nur unter Plasma stabil lief. mpv, der populäre Open-Source-Mediaplayer, unterstützt HDR-Ausgabe über Vulkan ebenfalls und kann unter Sway 1.12 HDR-Inhalte direkt an einen HDR10-fähigen Monitor durchreichen. Für Foto-Workflows mit darktable und RawTherapee bringt das Color-Representation-v1-Protokoll präzisere Farbinformationen, sobald die Anwendungen den Pfad nutzen. Auch Browser wie Firefox haben über die letzten Versionen schrittweise HDR-Pfade ergänzt, die unter Sway 1.12 zum Tragen kommen.
Was beim Setup typischerweise schiefgeht
Drei Stolpersteine tauchen in der Community am häufigsten auf. Erstens, der Vulkan-Renderer ist nicht aktiv, weil die Umgebungsvariable nicht gesetzt ist oder die GPU-Treiber Vulkan nicht sauber liefern. Ein vulkaninfo-Test sollte vor dem Sway-Start saubere Ausgabe liefern. Zweitens, das EDID des Displays meldet HDR-Fähigkeiten nicht korrekt, was insbesondere bei manchen HDMI-AVR-Konstellationen passiert. Hier hilft entweder ein direkter DisplayPort-Anschluss oder eine manuelle EDID-Override-Konfiguration im Kernel-Befehl. Drittens, die installierten Mesa-Pakete sind zu alt für stabile HDR-Pipelines. Mesa 26.1 ist die untere Grenze, mit der HDR auf AMD-Karten reibungsfrei läuft, ältere Versionen zeigen Farb-Banding, fehlerhaftes Tone-Mapping oder rein schwarze HDR-Ausgaben.
Für Debian-Nutzer auf Trixie sind diese drei Punkte über Backports lösbar. Wer auf Bookworm bleibt, wird auf absehbare Zeit nicht in den Genuss einer sinnvollen HDR-Sway-Pipeline kommen, weil die Paketstände dort schlicht zu alt sind.
Wohin sich Sway als Multimedia-Plattform bewegt
Mit 1.12 ist Sway nicht nur ein Werkzeug für Entwickler-Workflows, sondern eine Wayland-Plattform mit halbwegs vollständigem Multimedia-Profil. HDR-Wiedergabe, Color Management, Window-Capture, Workspace-Standardisierung und eine breitere Protokoll-Basis ergeben in Summe ein Bild, das vor zwei Jahren auf einem Tiling-WM kaum vorstellbar gewesen wäre. Für Debian-Anwender, die einen schlanken, scriptbaren Compositor mit modernem Display-Stack suchen, ist 1.12 das erste Sway, das in diese Rolle hineinpasst, ohne dass massive Eigenarbeit nötig ist.
Was bleibt, ist die Beobachtung der nächsten Monate. KDE Plasma 6.7 und 6.8 werden den Color-Management-Pfad weiter ausbauen, GNOME-Mutter wird voraussichtlich nachziehen, und wlroots 0.21 oder 0.22 wird vermutlich weitere HDR-Detailfunktionen, etwa Dolby Vision oder erweiterte Tone-Mapping-Optionen, mitbringen. Sway profitiert davon automatisch, weil es auf wlroots aufsetzt. Wer 1.12 jetzt einrichtet, hat damit die Basis für eine HDR-fähige Tiling-Linux-Workstation, die in den kommenden Versionen nur noch besser werden dürfte.
