KDE Plasma 6.8 ohne X11-Sitzung: Was mit XWayland weiter funktioniert

Deine alten X11-Anwendungen verschwinden nicht

„KDE entfernt X11“ klingt zunächst, als könnte man einen ganzen Stapel vertrauter Programme ins Computermuseum tragen. Ich mag alte Software, aber so ist diese Änderung nicht gemeint. Entscheidend ist die Unterscheidung zwischen der Desktop-Sitzung beim Anmelden und der Schnittstelle einer einzelnen Anwendung.

Plasma 6.8 beendet die Plasma-X11-Anmeldesitzung. Ältere X11-Anwendungen können in einer Wayland-Sitzung grundsätzlich weiterhin über XWayland laufen. Die KDE-Veröffentlichung vom 14. Oktober 2026 bestätigt außerdem die fortbestehende X11-Unterstützung von KDE-Anwendungen. Andere Desktops und bereits veröffentlichte Plasma-Versionen sind davon getrennt zu betrachten.

Dieser Artikel ist eine Entscheidungshilfe mit Quellen- und Paketstand vom 5. November 2026. Er enthält keine neuen Benchmarks von Cthulhu, meinem Arch-Rechner mit AMD-Radeon-Grafik, und behauptet keine dort installierte Plasma-6.8-Version. Eine gelungene Umstellung muss deine tatsächliche Arbeit ermöglichen — einschließlich des unscheinbaren Tastenkürzels, das du fünfzigmal täglich benutzt.

X11, Wayland, KWin und der Anmeldebildschirm

X11 ist das lange etablierte Anzeigeprotokoll klassischer grafischer Linux-Sitzungen. Ein X-Server verbindet Anwendungen mit Eingabe und Bildausgabe. Ein Fenstermanager ordnet Fenster an; Compositing setzt die sichtbaren Inhalte zusammen. Um diese Architektur herum hat sich modernes Rendering stark weiterentwickelt. Ihr Alter allein erklärt weder ihre Möglichkeiten noch ihre Grenzen.

Wayland beschreibt die Kommunikation zwischen Anwendungen und einem Compositor. Dieser ist hier zugleich der Displayserver. Unter Plasma übernimmt KWin diese Rolle und verbindet Fensterverwaltung, Eingabeverteilung und Darstellung. Anwendungen liefern Inhalte für ihre Oberflächen; der Compositor entscheidet, wie sie auf den Ausgängen erscheinen. Die Wayland-Architekturdokumentation erläutert diesen Zusammenhang.

Der Displaymanager wiederum ist die Anmeldung, über die eine Sitzung gestartet wird. Er ist nicht mit KWin identisch. Verschwindet „Plasma (X11)“ aus der Auswahl, bedeutet das nicht, dass die Anmeldung grundsätzlich keine X11-Sitzung eines anderen Desktops mehr starten kann. Eine erfolgreiche Anmeldung beweist umgekehrt noch keine vollständige Anwendungskompatibilität.

Zwei Programmwege auf demselben Desktop

Die eigene Grafik zeigt zwei Pfade. Eine native Wayland-Anwendung spricht über Wayland direkt mit KWin. Eine X11-Anwendung verbindet sich mit XWayland. Dieses tritt gegenüber KWin als Wayland-Client auf. Beide Fensterarten werden anschließend über Grafikstack und Bildschirme gemeinsam dargestellt.

XWayland ist ein X-Server, keine vollständige Übersetzung sämtlicher X11-Fähigkeiten in globale Wayland-Rechte. Viele gewöhnliche Programmfunktionen bleiben dadurch verfügbar. Eine Komponente, die den ganzen X-Desktop verwalten wollte, wird aber nicht automatisch zur Verwaltung nativer Wayland-Fenster. Das betrifft beispielsweise alternative X11-Fenstermanager.

Ebenso isoliert ein gemeinsam genutzter XWayland-Server seine X11-Clients nicht automatisch voneinander. Die zusätzlichen Grenzen für native Wayland-Anwendungen und die Kompatibilität alter Programme existieren nebeneinander. Daraus wird noch keine vollständige Sandbox für jedes historische Programm.

Was sich mit Plasma 6.8 ändert

David Edmundsons Entwicklerbeitrag vom 2. Juni 2026 benennt Plasma 6.7 als letzte Veröffentlichung mit Plasma-X11-Sitzung. Er trennt den Wegfall sitzungsspezifischer Codepfade von weiterhin unterstütztem XWayland und KDE-Anwendungen auf anderen Desktops. Die Oktober-Ankündigung bestätigt die veröffentlichte Umstellung.

Zwei Desktopwege zu pflegen kostet Entwicklung und Tests. Die Konzentration auf eine Architektur kann zukünftige Arbeit vereinfachen. Das ist ein nachvollziehbares Wartungsargument; es beweist noch keine Gleichwertigkeit für jede Spezialanwendung. Auch der Entwicklerbeitrag räumt ein, dass Werkzeuge, Skripte und Arbeitsabläufe angepasst werden müssen.

Die Compositor-Architektur bietet eine sinnvolle Grundlage für unterschiedliche Skalierung und Bildwiederholraten pro Bildschirm sowie moderne Darstellungsfunktionen. HDR und Farbmanagement hängen trotzdem von Anwendung, Compositor, Treiber und Displayweg ab. Das Wort Wayland allein garantiert weder korrekte Farben noch niedrigere Latenz auf einer bestimmten Maschine.

Die Sicherheitsgrenzen verändern außerdem das Verhalten alter Hilfsprogramme. Eine gewöhnliche Anwendung soll nicht beliebig fremde Fenster lesen oder Eingaben auf dem gesamten Desktop einschleusen. Manche X11-Werkzeuge nutzten genau diese Möglichkeiten. Eine explizite Desktopschnittstelle kann den gewünschten Arbeitsablauf erhalten, verlangt aber unter Umständen ein anderes Werkzeug.

Welche Sitzung läuft gerade wirklich?

Führe diese lesenden Befehle in einem Terminal deiner grafischen Sitzung aus. Eine SSH-Shell, eine alte tmux-Umgebung oder manuell veränderte Variablen können etwas anderes beschreiben. Beginne mit dem Sitzungstyp:

echo "$XDG_SESSION_TYPE"

Typische Werte sind wayland und x11. Eine leere Ausgabe ist zunächst unklar. Danach kannst du die Verbindungsvariablen ansehen:

echo "$WAYLAND_DISPLAY"

echo "$DISPLAY"

Ein gesetztes DISPLAY ist unter Wayland mit verfügbarem XWayland völlig normal. Es macht die gesamte Sitzung nicht zu X11. Ein Desktop kann native Wayland-Programme und Programme mit X11-Backend gleichzeitig ausführen.

Auf Systemen mit systemd-logind liefert der folgende Aufruf eine weitere Sicht, sofern XDG_SESSION_ID für die betreffende Sitzung gesetzt ist:

loginctl show-session "$XDG_SESSION_ID" -p Type

Ist die Variable leer, identifiziere die passende Sitzung zunächst mit loginctl list-sessions. Eine zufällige Kennung einzusetzen hilft nicht. Diese Befehle zeigen Zustände, keine Kompatibilitätsbewertung. Für das Backend eines einzelnen Programms können dessen eigene Diagnoseinformationen nötig sein.

Kompatibilität entscheidet sich am Arbeitsablauf

Die Matrix beschreibt architektonische Erwartungen und sinnvolle Prüfungen. Sie zertifiziert keine beliebigen Programmversionen. „Üblicherweise nutzbar“ verlangt weiterhin einen Test der eigenen Pakete. „Abhängig“ bedeutet, dass Anwendung, Compositor, Portal oder Treiber die betreffende Funktion unterstützen müssen.

Kann ein X11-Werkzeug native Wayland-Fenster nicht aufnehmen, kann das an der Architektur liegen. Es ist dann nicht automatisch eine neue Plasma-6.8-Regression. Ein Absturz eines bestimmten Pakets gehört dagegen in eine konkrete Fehlermeldung. Beides verdient eine präzise Beschreibung statt eines pauschalen Urteils über das gesamte System.

Portale und PipeWire: Freigabe statt beliebigem Zugriff

Desktopportale bieten standardisierte Schnittstellen für Aufgaben, die der Desktop vermittelt. Eine Anwendung kann Bildschirmfreigabe anfragen; das Desktopbackend zeigt die Auswahl beziehungsweise Berechtigung an. Unter Plasma gehört das KDE-Portalbackend zu den zu prüfenden Komponenten. Dass ein Paket installiert ist und dass eine Anwendung die Schnittstelle verwendet, sind zwei Voraussetzungen.

Das ScreenCast-Portal stellt die ausgewählten Aufnahmeströme über PipeWire bereit. PipeWire transportiert Medien; es entscheidet nicht allein darüber, ob irgendein Programm alles aufzeichnen darf. Bildschirmaufnahme und Tonausgabe nutzen verwandte Infrastruktur, sind aber unterschiedliche Diagnosewege. Bei Tonproblemen hilft der Linux-Audio-Ratgeber für den anderen Teil des Systems.

Auch für globale Tastenkürzel und Remote Desktop gibt es Portalschnittstellen. Ihre Existenz belegt noch keine allgemeine Implementierung. Prüfe beide Seiten: die Anwendung und das von der Distribution gelieferte Desktopbackend.

Bei Fernzugriff müssen mehrere Aufgaben auseinandergehalten werden: einen bereits angemeldeten Desktop teilen, einen gesperrten Rechner erreichen und eine unbeaufsichtigte Sitzung ohne Bildschirm starten. Teste genau die benötigte Aufgabe. Ein lokaler Freigabedialog beweist nicht, dass du nach einem Neustart aus der Ferne wieder auf den Rechner kommst.

Deine Wayland-Prüfungen auswählen

Diese lokale Lesehilfe grenzt die Prüfliste nach Einsatzzweck ein. Sie erzeugt kein automatisches „kompatibel“. Ohne JavaScript lassen sich alle Abschnitte aufklappen. Mit JavaScript öffnet die Auswahl die zugehörigen Hinweise; „alle“ stellt die vollständige Liste wieder her.

Debian, Arch, Ubuntu und Fedora haben unterschiedliche Zeitpläne

Ein Upstream-Veröffentlichungsdatum verändert nicht über Nacht jeden installierten Desktop. Die folgende Momentaufnahme wurde am 5. November anhand der verlinkten Paketseiten geprüft. Sie beschreibt diese Quellen, keine beliebigen Backports, Architekturen oder lokal installierten Maschinen. Ein Präfix wie Debians Epoch gehört zur Paketverwaltung, nicht zur Plasma-Produktversion.

Unter Debian/Ubuntu zeigt apt-cache policy plasma-desktop installierte Version und Kandidaten. Arch-Nutzer können pacman -Q plasma-desktop lesen, Fedora-Nutzer rpm -q plasma-desktop. Diese Abfragen verändern nichts, beschreiben aber auch nicht den gesamten KWin-, Treiber- und Portalstack. Nutze den unterstützten Updateweg der Distribution und vermeide teilweise vermischte Paketstände.

AMD, NVIDIA, mehrere Monitore und Spiele

Bei AMD arbeiten typischerweise Kerneltreiber, Mesa und Compositor zusammen. Proprietäre NVIDIA-Treiber bringen eigene Integrationsbedingungen mit. „AMD geht“ und „NVIDIA geht nicht“ sind beide zu grob für eine echte Entscheidung. GPU-Generation, Treiberzweig, XWayland, KWin, Anschlüsse und Anwendungsbackend spielen zusammen.

Die NVIDIA-Hinweise von KDE behandeln EGL-Integration, DRM-Modesetting und explizite Synchronisierung. Ältere Mindestversionsangaben sind historische Voraussetzungen, keine Empfehlung, veraltete Treiber zu installieren. Verwende den gepflegten, zu Hardware und Distribution passenden Treiber. Eine globale Änderung von Kernelparametern schreibt dieser Artikel nicht vor.

Ein konkretes, versionsgebundenes Beispiel liefert NVIDIAs Wayland-Kapitel zum Treiber 580.178.04: Es dokumentiert Einschränkungen von nvidia-settings und bestimmten GLX-Pfaden. Das beschreibt diesen Treiberzweig, keine Liste neu durch Plasma 6.8 entstandener Fehler. Lies die Hinweise deines installierten Treibers, bevor du einen alten Workaround zur neuen Systemeinstellung machst.

Bei mehreren Monitoren zählt die tatsächliche Kombination aus Skalierung, Frequenz und Ausrichtung. Wiederhole Tests nach Suspend, Abziehen des Docks und erneutem Anschließen. Nicht ganzzahlige Skalierungsfaktoren können Unterschiede zwischen nativen und XWayland-Anwendungen sichtbar machen. Scharfe Schrift, korrekte Zeigerkoordinaten und Aufnahmeauflösung sind genauso relevant wie ein erfolgreich geöffnetes Fenster.

Für Spiele braucht ein sinnvoller Vergleich identische Titel, Einstellungen und Laufzeitversionen. Durchschnittliche FPS können ungleichmäßige Bildausgabe oder Eingabeprobleme verdecken. Overlays und Aufnahmen beanspruchen möglicherweise einen weiteren Pfad. Für diesen Artikel wurden auf Cthulhu keine Messungen durchgeführt; entsprechend gibt es hier keine erfundene Latenz- oder Benchmarkverbesserung.

Ein Umstiegsplan mit funktionierendem Rückweg

1. Unverzichtbare Anwendungen, Kürzel, Geräte und Fernzugriffsaufgaben aufschreiben.
2. Distribution, Sitzung sowie Plasma-, KWin- und Treiberversion festhalten.
3. Upgradehinweise der Distribution und Dokumentation wichtiger Anwendungen lesen.
4. In einer unterstützten Sitzung oder geeigneten Testumgebung prüfen; Hardwarefragen brauchen reale Hardware.
5. Die Arbeitsabläufe einschließlich assistiver Technik und Wiederherstellungszugang testen.
6. Über unterstützte Quellen aktualisieren und Backup sowie Administrationsweg bereithalten.
7. Reproduzierbare Hindernisse mit Versionen und Bedingungen an das zuständige Projekt melden.

Nach dem Upgrade auf 6.8 ist „einfach wieder Plasma X11 auswählen“ für diese Version kein Rückweg mehr. Ein anderer unterstützter Desktop, Konsolenzugang oder eine getestete Wiederherstellung kann helfen. Vorübergehend auf einem unterstützten älteren Distributionsrelease zu bleiben, ist bei einem wichtigen Hindernis legitim. Einzelne alte Plasma-Pakete gewaltsam in ein neueres System einzubauen, ist eine andere und riskantere Entscheidung.

Wer den Wechsel zu Linux insgesamt plant, kann diese Liste zusammen mit dem Linux Migration Companion für die Bestandsaufnahme verwenden. Betriebssystemwechsel und Sitzungswechsel sind unterschiedliche Entscheidungen; die unverzichtbaren Anwendungen zuerst aufzuschreiben hilft bei beiden.

Die praktische Schlussfolgerung lautet: Die Kompatibilität gewöhnlicher X11-Anwendungen bleibt erhalten; Annahmen über Zugriff auf den gesamten Desktop müssen überprüft werden. Plasma ändert seine Sitzungsarchitektur. Ob sie für deinen Rechner passt, beantwortet sich an zuverlässig erledigten Aufgaben und nicht am gewonnenen Protokollstreit im Internet.