Gaming unter Wayland - Ein Erfahrungsbericht mit Tipps und Tricks

Wayland hört man immer häufiger. Wir haben für euch getestet, wie es sich mit dem neuem Oberflächen-Server und Spielen verhält. Aber erstmal ein wenig Einführung in die wunderbare Welt der grafischen Oberflächen unter Linux...

Was ist Wayland?

Wayland ist einfach gesagt der neue Standard unter den grafischen Oberflächen für Linux. Was zuvor XFree86 mit X11 und später Xorg mit X11 waren, geht nun immer mehr in Richtung Wayland. Dabei sind viele der früheren X11-Entwickler inzwischen zum Wayland-Entwicklungsteam rübergewechselt. Der X11-Desktop ist damit faktisch tot und wird nicht mehr weiter entwickelt.

Wie genau funktioniert nun Wayland gegenüber dem früheren Standard X11? Unter eurer Linux-Distribution läuft zunächst das Basis-Betriebssystem. Hier auf wird der X11-Server gestartet, zumeist von Xorg. Eine grafische Applikation, die sich nun anzeigen lassen möchte, muss mit diesem X-Server kommunizieren. Dazu nutzt sie das X11-Protokoll. Dieses Protokoll wird inzwischen von vielen GUI-Toolkits implementiert, so dass normale Anwendungen eigentlich nicht mehr direkt mit dem X-Server kommunizieren müssen, sondern es stattdessen hinter einigen Abstraktionsschichten verberben.

Nun ist dieses Protokoll schon sehr sehr alt. Es wurde für leistungsschwache Systeme konzipiert, die es in den 80ern/90ern zuhauf gab. Die leistungshungrigen Applikationen liefen dann auf starken Hauptcomputern, die Ausgabe wurde dann über das X-Protokoll auf die Anzeigecomputer übertragen. Die leistungsschwachen Rechner mussten also nur die Applikation anzeigen und Maus, sowie Tastaturinteraktionen zurückliefern. Weil sich im Laufe der Zeit die Anforderungen an die grafischen Oberflächen unter Linux massiv verändert haben, man möge nur einmal ans Font-Rendering, schnelle Auflösungswechsel durch Vollbildapplikationen, 3D-Beschleunigung, Video-Darstellung denken, wurden viele Erweiterungen geschaffen, die nachträglich an das Protokoll und den X-Server angeflanscht worden sind.

Inzwischen platzt das System jedoch aus allen Nähten und ist nahezu unwartbar geworden. Daher haben sich die Entwickler entschlossen eine neue X-Server-Version herauszubringen. So wie es vor X11 auch schon X10 und weitere Vorgänger gab, sollte es nun einen Nachfolger geben, der mit den Altlasten aufräumen soll. X12 hätte eigentlich ins Namensschema gepasst, aber der Name ist letztlich auf Wayland gefallen. Die Entwicklung wurde 2008 aufgenommen und inzwischen ist es sehr häufig als Standardauswahl in vielen Distributionen zu finden.

Wie bekomme ich Wayland?

Wayland selbst ist über die Freedesktop-Webseite organisiert. Allerdings werden eure Distributionen sehr wahrscheinlich schon mit einem Wayland-Desktop ausgeliefert werden. OpenSUSE Tumbleweed liefert zum Beispiel seit dem Wechsel von Plasma 5 auf Plasma 6 standardmäßig Plasma über Wayland aus. Aber auch Fedora hat schon sehr früh, seit Fedora 25 für GNOME und seit Fedora 34 auch mit Plasma, begonnen Wayland prominent auszuliefern.

Gnome für Wayland, Plasma für Wayland? Was??

Musste früher der GNOME-Desktop oder KDE Plasma das X11-Protokoll implementieren, so müssen sie heute das Wayland-Protokoll implementieren. Darüber hinaus ist es mit Wayland nun so von der Architektur her, dass die Oberflächen ihren eigenen sogenannten Compositor zur Verfügung stellen müssen. Das ermöglicht zum einen bessere Kontrolle über die Darstellung auf der grafischen Oberfläche und mehr Eingriffsmöglichkeiten, ist aber natürlich auch aufwändiger in der Entwicklung. Daher war die Wayland-Integration in KDE Plasma erst mit Version 6 vollständig, weil diese auch noch auf die Unterstüzung in QT6 warten mussten. Bei GNOME war man etwas früher schon soweit. Es gibt aber auch noch einige Oberflächen, wie z.B. XFCE, die bislang noch keinen Wayland-Compositor implementiert haben.

Damit nicht immer alles in jedem Lager neu entwickelt werden muss, hat die Community sich auf ein paar Basis-Libraries geeignigt, die einen Großteil der immer wieder anfallenden Arbeiten übernehmen.

Grafiktreiber-Unterstützung

NVIDIA

Der Linux-native NVIDIA-Treiber hat seit Version 490 beschleunigte Unterstützung für Wayland. Diese stützt sich allerdings auf eine mitlaufende und existierende XWayland-Bridge. Diese stellt einen Wayland-Compositor bereit, der X11-Befehle entgegennimmt, so wie sie die bisherigen Applikationen gewohnt waren zu sprechen und wandelt diese in entspreche Wayland-Befehle um. Performancemäßig macht das eigentlich keinen nennenswerten Unterschied. Jedoch gibt es natürlich ein paar Limitierungen, die NVIDIa jedoch in der Dokumentation entsprechend benennen. Ein großes Manko ist die mangelnde GLX-Unterstützung. Dadurch funktionieren Java-Spiele, die sich auf JLWGL stützen, nicht. Auch ist bei Treibern vor 470 keine Beschleunigung unter dem XWayland verfügbar.

Der Grafiktreiber muss über eine Buffer-API mit dem Compositor sprechen. Dazu stehen GBM und EGL zur Auswahl. Seit NVIDIA auch GBM unterstützt hat sich z.B. Plasma sehr schnell auch auf Wayland committet.

AMD

Mit AMD gibt es kein Java-Problem unter Wayland. Mehr konnte ich allerdings mit dem Testgerät nicht ausprobieren.

Testrechner

Ich habe Wayland unter opensuse Tumbleweed mit Plasma 6 unter Wayland auf einem AMD Ryzen 5 3500 mit 48GB RAM und einer NVIDIA RTX 2060 SUPER mit 8GB VRAM ausprobiert. Der NVIDIA-Treiber liegt in Version 550.100 vor.

Hab ich schon Wayland?

Mit einer aktuellen Distribution hast du sehr wahrscheinlich bereits Wayland irgendwo laufen. In der Anmeldemaske kannst du zumeist auswählen, welchen Desktop du starten möchtest. Hier ist dann eine Auswahl zwischen beispielsweise "Plasma (Wayland)" und "Plasma (X11)" möglich.

Um herauszufinden, was in deiner laufenden Desktop-Session aktuell läuft, kannst du an der Konsole

comrad@Comrad-PC:~> echo $XDG_SESSION_TYPE 
wayland

ausführen. Steht dann dort "wayland", läuft dein X11-Server nicht mehr, sondern schon ein Wayland-Compositor. Alternativ kannst du in KDE unter Systemeinstellungen nachschauen und dann ganz unten "Über dieses System" im Feld "Grafik-Plattform" überprüfen, was gerade läuft.

Troubleshooting

In meinen Tests habe ich versucht soviele Spiele mit den unterschiedlichsten Ansätzen Grafik aufs Display zu bringen zu finden. Dabei sind ein paar Gemeinsamkeiten aufgefallen, die ich hier zusammengesammelt habe. Bis auf Minecraft lies sich somit für nahe zu jedes Spiel eine Lösung finden, wenn man das Problem entsprechend vorher kategorisieren und eingrenzen konnte.

So haben die Overlays von Mumble und Steam keinerlei Probleme sich dazwischen zu schalten. Allerdings scheinen das Steam Overlay und das Mumble Overlay nicht gleichzeitig aktiv sein zu können. Im Gegentest mit X11 funktionieren beide Overlays aber tatsächlich auch nicht gleichzeitig.

Native Steam-Spiele funktionieren problemlos, dank der XWayland-Bridge. Auch Proton-basierte Spiele laufen ohne weitere Schwierigkeiten.

SDL

SDL geht standardmäßig auf das X11-Protokoll. Ohne XWayland wird es daher an der Stelle schwierig. Ihr könnt das Protokoll jedoch über die Umgebungsvariable SDL_VIDEODRIVER ändern.

Fügt einfach vor dem Starten eurer Applikation diese Zeile hinzu und das darunterliegende SDL eures Spiels spricht ab da nur noch Wayland.

SDL_VIDEODRIVER=wayland meine_applikation

Beachtet jedoch, dass diese Option nur ab SDL 2.0 zur Verfügung steht.

Flatpak

Das Applikationscontainer-Format Flatpak ist sehr beliebt bei Spielern, weil sich damit die neusten Versionen schnell und distributionsunabhängig auf den Rechner holen lassen. Da Flatpak jedoch die Applikation ein wenig vom Betriebssystem abschottet (sog. Permissions), muss man für Wayland-Unterstützung hier manchmal etwas Hand anlegen.

So müsst ihr den Wayland-Socket an die im Flatpak-Container laufende Applikation weiterreichen. Das könnt ihr wie folgt erreichen:

flatpak run --socket=wayland org.openttd.OpenTTD

Bei Applikationen, die nativ Wayland unterstützen, z.B. durch die Nutzung von SDL 2, könnt ihr das somit aktivieren. Für alle anderen bleibt es bei --socket=x11.

Flatpak reicht ein paar Umgebungsvariablen durch, jedoch hauptsächlich Flatpak bezogene und welche für XDG (Link). Wollt ihr so z.B. die SDL-Umgebungsvariable an Flatpak durchreichen, dann könnt ihr das wie folgt machen:

flatpak run --env=SDL_VIDEODRIVER=wayland --socket=wayland net.openra.OpenRA

Problemfall Fractal Scaling (125% statt 100%)

Einige Spiele haben Probleme mit Fractional Scaling (beispielsweise 125%), ein Kandidat hierfür ist OpenRA oder aber auch Command and Conquer 3: Tiberium Wars, das die Auflösung falsch ermittelt und den Bildschirm nur zum Teil darstellt. Beim C&C-Titel fühlt sich das Bild schwammig an, wenn die Maus gezogen wird, es gibt Ruckler und Aussetzer. Dieses Problem tritt unter Wayland auf auf einem eurer angeschlossenen Monitore Fractional Scaling eingestellt ist. Ein runder Wert von 100% bringt hier Besserung.

Java

Java, bzw. das OpenJDK unterstützt derzeit noch kein Wayland im Rendering. Das Wakefield-Projekt soll das ändern, bis dahin, müssen allerdings Java-Anwendungen über XWayland abgebildet werden. Damit gibt es allerdings im Zusammenhang von NVIDIA und GLX das Problem der fehlenden Implementation. Somit lassen sich LWJGL-Spiele unter NVIDIA-basierten Desktops über XWayland nicht unter Wayland darstellen. Minecraft ist damit dann leider raus. Das äussert sich beim Start in massivem Flackern des Fensters. Grund hierfür ist die mangelnde Synchronisation zwischen dem NVIDIA-Treiber und dem Compositor. Der NVIDIA-Treiber 555.58 führt das sogenannte "Explicit Sync" ein, dass diese Probleme beheben soll (Phoronix, Link), danke an Venom für den Hinweis.

Fazit

Wayland ist inzwischen auch für Spiele gut geeignet. An einigen Ecken und Kanten reibt sich das neue Fenstersystem noch mit den noch stark X11-lastigen Applikationen, aber es scheint besser zu werden. Sofern man auf Fractal Scaling verzichten kann, umgeht man bereits etliche Probleme.

Wie sehen eure Erfahrungen mit Wayland und Spielen aus? Erzählt es uns in den Kommentaren! Wir freuen uns auch über eure ergänzenden Erfahrungen mit AMD und Wayland zu hören.

Multimedia