Kann man 2026 endlich Wayland nutzen?

• Wayland ist der Nachfolger von X11 im Grafik-Stack und wurde 2008 gestartet, doch der Autor bewertet, dass er es 18 Jahre lang auf seinem System nicht wirklich brauchbar einsetzen konnte
• Mit Stand 2025 ist der grundlegende Betrieb dank GBM- und Explicit-Sync-Unterstützung der nVidia-Treiber möglich geworden, doch eine vollständige Umstellung bleibt wegen Dingen wie der weiterhin fehlenden TILE-Unterstützung für 8K-Monitore schwierig
• In Sway 1.11 und wlroots 0.19.0 gab es wichtige technische Fortschritte, aber es bestehen weiterhin zahlreiche praktische Hürden wie Eingabeverzögerung, Grafik-Glitches und Skalierungsprobleme bei Xwayland
• Wichtige Anwendungen wie Chrome und Emacs zeigen weiterhin Probleme wie Leistungseinbußen, Unterschiede beim Rendering und instabile Hardware-Beschleunigung
• Insgesamt lautet das Fazit zu Wayland: „Es ist nun erstmals in Reichweite für den praktischen Einsatz“, aber für die tägliche Arbeit ist die Kombination aus X11 und i3 weiterhin stabiler

---

Historischer Hintergrund von Wayland

• Wayland ist ein 2008 gestartetes Nachfolgeprojekt für den X-Server (X11, Xorg), und der Autor entwickelte 2009 den Tiling-Window-Manager i3 für X11
• Anfangs ließ sich nur der Demo-Compositor Weston ausführen, 2014 begann GNOME mit der Wayland-Unterstützung, später dann KDE
• Wichtige Anwendungen wie Firefox, Chrome und Emacs konnten Wayland nur über experimentelle Flags nutzen
• nVidia-GPUs funktionierten lange Zeit unter Wayland gar nicht oder verursachten Grafikfehler, zudem blieben Kompatibilitätsprobleme mit 8K-Monitoren bestehen
• In jüngerer Zeit haben wichtige Distributionen wie Fedora, RHEL und Asahi Linux Wayland als Standard- oder einzigen Desktop-Stack übernommen, was den Migrationsdruck erhöht

Einrichtung der Wayland-Laufzeitumgebung

• Das Testsystem verwendet eine nVidia RTX 4070 Ti (Laptop) und eine RTX 3060 Ti (Haupt-PC)
• Ab nVidia-Treiber 495 (2021) wurde GBM-Unterstützung hinzugefügt, und die Funktion explicit sync wurde in Sway 1.11 (2025) und wlroots 0.19.0 implementiert
• Wegen der fehlenden TILE-Eigenschaftsunterstützung des 8K-Monitors Dell UP3218K wird der Bildschirm in Sway in zwei Hälften getrennt dargestellt
  • Mithilfe eines Patches von EBADBEEF und der Analyse durch Claude Code wurde ein Bug in der DRM-Eigenschaft SRC_X gefunden; mit einem Workaround-Patch gelang schließlich die Darstellung im Vollbild
• GNOME unterstützt TILE, aber es tritt starkes Tearing in der Bildschirmmitte auf
• In einer NixOS-25.11-Umgebung wurden GDM, GNOME und Sway parallel eingerichtet, zusätzlich kamen Wayland-spezifische Tools wie foot, fuzzel und wayland-utils hinzu

Versuchsergebnisse: Sway-Umgebung

• Sway ist mit der i3-Konfiguration größtenteils kompatibel; der Autor passte dabei das NEO-Tastaturlayout sowie Ein- und Ausgabe-Einstellungen an
• Die wichtigsten Probleme:
  • Verzögerter und nicht flüssiger Mauszeiger (vermutlich wegen fehlender Unterstützung für nVidia-Hardware-Cursor)
  • Keine Skalierung für Xwayland-Apps, wodurch sie unscharf oder doppelt skaliert dargestellt werden
  • Manche Tastenkürzel werden doppelt ausgelöst (ghost key press)
• Bei GTK-Apps wurde ein anfänglich zu großer Font per gsettings reset behoben
• GTK3 nutzt nur dconf-Einstellungen, daher muss font-name in dconf gesetzt werden, damit das Rendering übereinstimmt
• swaylock endet im Gegensatz zu i3lock beim Beenden in einem „roten Bildschirm“-Zustand und kann nur mit SIGUSR1 aufgehoben werden
• Automatisierungs-Tools auf Basis von i3 IPC sind nur teilweise kompatibel, unter anderem wegen anderer Socket-Pfade, stehenbleibender Prozesse und fehlender Unterstützung für Layout-Wiederherstellung

Tests wichtiger Anwendungen

• Das foot-Terminal ist leichtgewichtig, zeigte aber Unterschiede bei manchen Farben, bei der Verarbeitung von Ctrl+Enter, bei der URL-Auswahl und bei den screen-Farben
• Emacs läuft in der Standardversion unter Xwayland und wirkt dadurch unscharf; die pgtk-Version zeigt Eingabeverzögerung und Unterschiede bei den Zeichenabständen
• Chrome verliert wegen Abstürzen des GPU-Prozesses die Hardware-Beschleunigung; außerdem werden beim Wiederherstellen von Fenstern Informationen zum vorherigen Workspace nicht beibehalten
• Bildschirmfreigabe ist über xdg-desktop-portal-wlr möglich, unterstützt aber keine Freigabe einzelner Fenster und hat Probleme mit Übertragungen in niedriger Auflösung
• Wenn Ausgabeskalierung aktiviert ist, treten Glitches auf, bei denen Fensterinhalte kurz verrutschen oder unscharf werden
• dunst-Benachrichtigungen und rofi (ab 2.0.0) funktionieren normal, beim Screenshot-Tool grim ist die Fensterauswahl jedoch unkomfortabel

Fazit: Wie realistisch ist die Wayland-Nutzung im Jahr 2026?

• Die Wayland/Sway-Sitzung kommt erstmals in die Nähe eines praktisch nutzbaren Zustands, weist aber weiterhin viele Mängel auf
• Die X11/i3-Umgebung bietet niedrige Eingabeverzögerung von 763μs und perfekte Stabilität
• Beim Umstieg auf Wayland treten Grafik-Glitches, Eingabeverzögerung und Leistungseinbußen bei wichtigen Apps auf
• Für den täglichen Einsatz wären folgende Bedingungen nötig:
  • Behebung der doppelten Tasteneingaben und Umschalt-Glitches in Sway
  • Stabilisierung der Chrome-Hardware-Beschleunigung und Unterstützung für die Fensterwiederherstellung
  • Verbesserung von Eingabeverzögerung und Rendering bei Emacs (pgtk)
• Das Fazit lautet: Wayland ist für den täglichen Arbeitseinsatz noch nicht bereit, und der Autor plant, weiterhin X11/i3 zu verwenden

[GN⁺]

Hacker-News-Meinungen

• Wayland ist letztlich nur ein Protokoll, daher gibt es mehrere Implementierungen (GNOME, KDE, wlroots usw.)
  Bei Xorg baute der Desktop auf einem einzigen soliden Fundament auf, während bei Wayland jeder Desktop das Rad praktisch neu erfindet
  Weston ist als Referenz gut, aber für den Alltagsgebrauch ungeeignet
  Ich denke, es braucht eine Standardbibliothek, die alle Desktops gemeinsam nutzen können. wlroots zielt auf diese Rolle, aber es wirkt nicht so, als würden GNOME oder KDE bald dorthin wechseln
  • Ich finde, X.org hatte das richtige Abstraktionsniveau getroffen. Ein WM musste Eingabe- oder Ausgabe-Verarbeitung nicht direkt selbst handhaben, und genau dadurch waren Einfachheit und Energieeffizienz gut. Wayland hat die Lehren aus X11 gewissermaßen nicht gelernt
  • Ich habe Sway und Hyprland benutzt, inzwischen nutze ich niri. Die wlroots-basierten Sway und niri sind ziemlich ordentlich, aber es gibt immer noch viele zufällige Bugs. Pointer-Probleme bei Wine-Apps, Abstürze beim Screen-Sharing, Probleme mit 10-Bit-Farben usw. Vielleicht ist es 2027 stabil, aber für 20 Jahre Entwicklung fühlt es sich ineffizient an
  • KDE und GNOME haben jeweils eigene Implementierungen von xdg-desktop-portal, was zu Kompatibilitätsproblemen führt. Bei wlroots-basierten Umgebungen muss man xdg-desktop-portal-wlr verwenden, bei Hyprland xdg-desktop-portal-hyprland.
    Die Struktur von Wayland selbst sieht in der Theorie laut dem offiziellen Architekturdokument gut aus, aber in der Praxis fehlen auf Protokollebene viele Funktionen
  • Eigentlich war auch X ein Protokoll, aber weil es mit X.org eine einzige Implementierung gab, war die Verwirrung geringer. Technisch ist es nicht unmöglich, eine standardisierte Bibliothek auf dem Niveau von wlroots zu haben
  • Die Wayland-Entwickler haben es ursprünglich als reines Display-Protokoll entworfen. Sie erwarteten, dass andere Gruppen Protokolle für Eingabe und Fenstermanagement entwickeln würden, aber das hat nicht gut funktioniert.
    Ein Versuch, Wayland jetzt zu ersetzen, könnte am Ende Verschwendung sein, weil man bereits ausgereifte Teile noch einmal neu baut
• Ich sehe immer noch keinen Grund, Wayland zu verwenden. Xorg ist stabil, und die meisten Lösungsbeiträge beginnen mit „Wenn du Wayland nutzt, geh zurück zu Xorg“.
  Wahrscheinlich wird die echte Verbreitung erst zunehmen, wenn Distributionen es wie bei systemd zwangsweise als Standard setzen
  • Normale Nutzer haben keinen besonderen Grund zu wechseln. Allerdings löst Wayland Dinge wie Multi-Display-Skalierung, bei denen X11 schwach ist, ziemlich gut.
    Aus Sicht von GNOME und KDE ist ein großer Faktor, dass sie die Last der fortlaufenden X11-Wartung reduzieren wollen, indem sie auf Wayland umsteigen.
    Ich denke, das Ziel dieses Jahr ist, einen Punkt zu erreichen, an dem es „keine Nachteile mehr“ gibt
  • Wayland wirkt so, als liefere es flüssigere Performance, aber wegen einiger Apps muss ich Xorg verwenden.
    Bei Arch und Ubuntu ist GNOME 49 bereits standardmäßig ohne Xorg, und KDE wird wohl bald nachziehen. Die Zeit von Xorg geht zu Ende
  • Früher musste man xorg.conf von Hand bearbeiten, aber nachdem ich Wayland auf Ubuntu testweise ausprobiert hatte, bin ich komplett umgestiegen. Vielleicht liegt es an meiner AMD-GPU, aber es läuft reibungslos ohne Probleme
  • Der Vorteil von Wayland ist fractional scaling
  • Ich muss Tools wie x2x, xev und xdotool benutzen, aber wegen des Sicherheitsmodells von Wayland ist das nicht möglich, deshalb bleibe ich bei Xorg
• Dass Nvidia die GBM-API von Wayland abgelehnt habe, ist ein Missverständnis. GBM war eine inoffizielle API innerhalb von Mesa, daher konnte Nvidia sie nicht direkt implementieren.
  Deshalb wurde mit EGLStreams eine herstellerneutrale Alternative vorgeschlagen.
  Das eigentliche Problem war eher, dass die freedesktop-Seite keine Struktur bereitgestellt hatte, in der der Nvidia-Treiber funktionieren konnte
  • Ich frage mich allerdings, wie ein Open-Source-Projekt wie Mesa von einer nicht öffentlichen API abhängen kann
• Ich benutze Wayland unter Gnome seit Jahren und habe überhaupt keine Probleme.
  Natürlich liegt das vielleicht auch daran, dass meine Hardware schlicht ist und nicht von Nvidia stammt, aber ich möchte betonen, dass Wayland durchaus gut funktionieren kann
  • Bei mir genauso: Unter Sway (2016) und KDE Plasma 6 läuft es perfekt. Nur Steam-Spiele lasse ich über XWayland laufen. Eine AMD/Intel-Kombination ist deutlich stabiler
  • Auch mit Nvidia-Hardware läuft es inzwischen ziemlich reibungslos. Früher hat es geruckelt, aber jetzt fühlt es sich besser an als Xorg.
    Für Dinge wie Fensterpositionierung oder das Durchsuchen anderer Apps braucht man allerdings Workarounds über Gnome-Shell-Extensions
  • So wie manche früher das Flimmern von CRT-Monitoren nicht wahrgenommen haben, können auch kleine Unannehmlichkeiten wie das feine Eingabegefühl oder Unterschiede bei Schriften je nach Person unterschiedlich auffallen
• Ich nutze seit Jahren Wayland auf Basis von wlroots/swaywm, und sogar eGPU funktioniert perfekt.
  Allerdings könnte das daran liegen, dass ich AMD-Hardware habe. Das Leben ist zu kurz, um es mit Nvidia-Problemen zu verschwenden
  • Umgekehrt crasht sway auf integrierter Intel-Grafik bei mir häufig, daher bin ich wieder zu i3+Xorg zurück
  • Ich nutze Nvidia seit 23 Jahren und hatte nie große Probleme. Letztlich ist es wohl eine Frage der persönlichen Wahl
  • Früher habe ich es auch mit Nvidia gut genutzt, und mit dem TILE-Patch war sogar ein 5K-Bildschirm okay.
    Wegen der Unterstützung für Multi-Output-Skalierung bin ich zu Wayland gewechselt und später wieder zurück
• Wegen der jüngsten Windows-Probleme bin ich zu Linux gewechselt; früher war das wegen fehlendem fractional scaling unmöglich.
  Dank Wayland ist das gelöst und eine große Verbesserung. Allerdings nutzt nicht jede Distribution Wayland standardmäßig, deshalb habe ich Ubuntu gewählt.
  Es war etwas lästig, dass Snap-Firefox keine Hardwarebeschleunigung verwendet hat
  • Auch für mich ist fractional scaling das größte Manko unter Linux.
    Unter MacOS ist selbst „wie 1440p aussehen“ perfekt, unter Windows etwas unscharf.
    Unter Linux ist X11 langsam, und Wayland hat immer noch Leistungsverzögerungen
• Ich nutze ebenfalls die Kombination i3+NixOS+urxvt+zsh+Emacs+rofi+maim+xdotool.
  Diesen perfekt funktionierenden Stack durch Sway zu ersetzen, würde mehr Nachteile als Vorteile bringen.
  Ich finde es beeindruckend, dass Michael es ausprobiert und dokumentiert hat
  • Es war beeindruckend, wie sorgfältig die tatsächlichen Probleme festgehalten wurden
• Ich habe nicht vor zu wechseln, bevor der von mir genutzte Window Manager (WM) Wayland unterstützt.
  Das größte Problem von Wayland ist, dass viele verschiedene WM-Projekte wegen Personalmangels die Umstellung nicht schaffen.
  Man kann mit XWayland ausweichen, aber ich will meinem ohnehin perfekt funktionierenden Umfeld nicht noch eine zusätzliche Schicht hinzufügen
  • Wenn du StumpWM benutzt, ist Mahogany, die Wayland-Version davon, in aktiver Entwicklung.
    Außerdem ist Wayback ein Projekt, das einen kompletten X11-Desktop auf Wayland laufen lässt
• Ich nutze Wayland auf einem Framework-Laptop, und es funktioniert perfekt.
  4K-Monitor, Umschalten auf Einzelbildschirm, fractional scaling — alles problemlos.
  Sogar auf einem alten Chromebook ist Screen Tearing verschwunden, und alles läuft flüssig.
  Ich habe bislang keine Nachteile bemerkt; der einzige Nachteil ist eher, dass mir ständig gesagt wird, es sei „falsch“
  • Schön, wenn es gut funktioniert, aber man muss auch anerkennen, dass es umgekehrt bei manchen Leuten nicht funktioniert
  • Nur weil man Glück hatte und keine Probleme erlebt, heißt das nicht, dass es keine Nachteile gibt
• Für mich hat Wayland nur Nachteile und keine Vorteile. Ich halte die Struktur, Komplexität auf andere Schichten abzuwälzen, für falsch.
  Ich werde weiter Xorg und Openbox benutzen
  • Komplexität von einer Stelle auf viele Stellen zu verteilen, ist eine nicht nachvollziehbare Entscheidung
  • Trotzdem wird Xorg immer weniger gepflegt, und die wichtigsten Entwickler wechseln zu Wayland.
    Am Ende wird Wayland wohl die einzige aktiv gepflegte Option sein