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