Sunshine/Moonlight unter Linux: KDE-Desktop mit niedriger Latenz auf den Fernseher streamen

Ich hab ein paar Stunden gebraucht, um meinen KDE-Desktop überhaupt vernünftig auf den Fernseher im Wohnzimmer zu bekommen. Die naheliegende erste Idee — Streaming über den Chromecast Default Media Receiver, so als wär es eine Videodatei — kam nie unter ein paar Sekunden Verzögerung, egal wie sehr ich an Bitrate und Auflösung geschraubt habe. Irgendwann war klar: Am Tuning lag es nicht. Googles Cast Default Media Receiver ist für gepuffertes Video gebaut, nicht fürs Mirroring, und da gibt es eine harte Grenze, an der kein Tuning mehr hilft.
Was tatsächlich funktioniert hat, war Sunshine und Moonlight. Beide sind Open Source, bauen auf derselben Idee wie Nvidias GameStream auf, und sind technisch eine völlig andere Baustelle als Screen-Mirroring: Statt Frames über ein Medienplayer-Protokoll zu schieben, hostet Sunshine eine echte Streaming-Session, die Moonlight auf der anderen Seite dekodiert. Ich will das nicht als wissenschaftliche Benchmark verkaufen, aber beim Streamen auf einen Android-TV-Projektor im Wohnzimmer fühlte sich der Desktop responsiv genug an, um ihn wirklich zu benutzen und nicht nur zuzuschauen. Gefühlt deutlich unter einer Sekunde.
Alles Folgende hab ich auf openSUSE Tumbleweed, KDE Plasma 6, Wayland, mit einer AMD RX 6650 XT getestet, gestreamt auf einen JMGO N1S Pro (Android-TV-Projektor). Bei einer anderen Distro oder GPU bleibt das Konzept gleich, aber manche Befehle passen dann nicht 1:1.
Casten ist nicht gleich Casten
Wenn Leute vom Bildschirm-Casten reden, meinen sie damit oft zwei verschiedene Technologien.
Miracast spiegelt einen Bildschirm über Wi-Fi Direct. Wo es sauber unterstützt wird, braucht es keine zusätzliche Software auf dem PC — aber die Linux-Treiberunterstützung ist durchwachsen, und in der Praxis sind Bildrate und Latenz je nach Treiber und Empfänger oft weniger gut für Spiele oder interaktive Arbeit geeignet.
Sunshine und Moonlight funktionieren anders. Sunshine läuft auf dem PC und hostet eine Streaming-Session — kodiert Video, Audio und Eingaben und schickt sie über ein eigenes Protokoll, statt über den normalen Mirroring-Pfad des Desktops. Moonlight dekodiert das auf der Empfängerseite. Darum geht es in diesem Artikel: Diese Technik ist dafür gedacht, einen entfernten Desktop tatsächlich zu benutzen, statt nur zuzuschauen.
Miracast oder Sunshine/Moonlight?
| Miracast | Sunshine/Moonlight | |
|---|---|---|
| Latenz | Mirroring-Niveau, hardwareabhängig | Gefühlt unter einer Sekunde in meinem Test |
| Für Gaming geeignet | Eher nicht | Ja |
| Empfänger | Miracast/WFD-fähiges Gerät | Android/Google TV mit App-Support |
| Aufwand beim Einrichten | Gering, wo es funktioniert | Installation und Pairing nötig |
| Am besten für | Schnelles Mirroring, Präsentationen | Gaming, Video, echtes Arbeiten am Remote-Desktop |
Willst du nur kurz etwas auf den Fernseher werfen, und sowohl PC als auch Fernseher unterstützen Miracast sauber über Wi-Fi Direct, nimm Miracast. Willst du einen Desktop, den du vom Sofa aus bedienen kannst, lies weiter.
Wie das zusammenspielt
KDE-Desktop (Sunshine-Host)
│ normales LAN, kein Wi-Fi Direct nötig
▼
Moonlight-Client (TV / Android-TV-Box)
Für diese Anleitung sollten beide Geräte im selben lokalen Netzwerk sein — dann findet Moonlight den Host automatisch, und du musst nichts an Routing oder VPN einrichten. Auf KDE/Wayland erfasst Sunshine den Desktop über xdg-desktop-portal und PipeWire — das ist der Weg, der bei mir funktioniert hat, weil KWin wlr-export-dmabuf nicht unterstützt, das Protokoll, das manche andere Compositoren für einen direkteren Weg nutzen. Ob direktes KMS-Capture bei einem nativen Paket-Build auch ohne den Portal-Umweg funktioniert, hab ich nicht getestet — behandle capture = portal also als die Einstellung, von der ich weiß, dass sie funktioniert, nicht zwangsläufig als die einzig mögliche.

Bevor du anfängst
- KDE Plasma 6 unter Wayland. Auf X11 oder älterem Plasma hab ich es nicht probiert.
- Eine Distro mit Sunshine-Paket, oder Flathub, falls deine keins hat.
- Ein Android/Google-TV-Gerät mit Moonlight aus dem jeweiligen App Store. Ein „Chromecast built-in"-Fernseher ohne App-Unterstützung reicht nicht.
- Beide Geräte im selben LAN. Gäste-Netzwerke und WLANs mit aktivierter Client-Isolation blockieren die Erkennung.
- Hardware-Video-Encoding hilft enorm. Software-Encoding funktioniert, aber man merkt den Unterschied.
- Sunshine lauscht standardmäßig im lokalen Netzwerk. Leite die Ports nicht ins Internet weiter, außer du willst das bewusst und weißt, was das offenlegt.
Einrichtung
1. Sunshine installieren
Auf openSUSE Tumbleweed:
sudo zypper addrepo https://download.opensuse.org/repositories/games:/tools/openSUSE_Tumbleweed/games:tools.repo
sudo zypper install sunshine sunshine-firewalld
Beim nativen Paket musst du dich nicht mit den Besonderheiten einer Flatpak-Sandbox oder eines AppImages herumschlagen. Andere Distros: erst im eigenen Repo nachsehen, Sunshine gibt es auch auf Flathub als dev.lizardbyte.app.Sunshine, falls nichts Natives da ist. sunshine-firewalld öffnet die nötigen Ports automatisch.
2. Erster Start
Sunshine über das App-Menü starten oder sunshine im Terminal ausführen, dann https://localhost:47990 im Browser öffnen. Der Browser meckert wegen des Zertifikats — das ist erwartet, Sunshine nutzt ein selbstsigniertes Zertifikat, einfach akzeptieren. Beim ersten Mal legst du einen Benutzernamen und ein Passwort fürs Web-UI an. Notier sie dir.
3. Capture-Backend einstellen
Im Web-UI im Tab "Configuration" die Capture-Methode auf portal setzen. Steht auch in ~/.config/sunshine/sunshine.conf als capture = portal, falls du lieber die Datei direkt bearbeitest. Speichern, Sunshine bei Bedarf neu starten.
4. Moonlight installieren
Auf dem TV/der Box: aus dem App Store installieren. Für einen Desktop-Client gibt es Builds auf moonlight-stream.org.
5. Koppeln — die PIN kommt von der ungewohnten Seite
Moonlight auf dem Client öffnen und den PC hinzufügen. Er sollte automatisch im LAN gefunden werden, sonst per IP hinzufügen. Moonlight fragt dann nach einer PIN — diese PIN erscheint auf dem Client, eingegeben wird sie im Sunshine-Web-UI, auf der PIN-Seite in der Navigationsleiste, zusammen mit einem Namen für das Gerät. Das ist genau andersrum, als man erstmal denkt.
6. Erster Stream
Wenn du den Stream zum ersten Mal startest, zeigt KDEs Portal einen Berechtigungsdialog, welcher Bildschirm geteilt werden soll — das ist die Zustimmung zur Bildschirmfreigabe, getrennt von Eingabeberechtigungen, die kommen erst später. Bestätigen. Bei mehreren Monitoren wählst du hier auch, welcher erfasst wird.
7. Prüfen, ob es wirklich läuft — nicht nur startet
Bild und Ton sollten nach ein paar Sekunden da sein. In Sunshines Logs nachsehen, welcher Encoder aktiv ist — da sollte der Name deines GPU-Hardware-Encoders stehen, nicht ein Software-Fallback, denn das ist der Unterschied zwischen "responsiv" und "warum ruckelt das". Tastatur, Maus und Controller vom Client aus sollten den Host-Desktop steuern. Reagiert ein Controller nicht: Die Bildschirmfreigabe deckt den Zugriff auf /dev/uinput nicht mit ab, das läuft über eine separate Geräteberechtigung — bei mir hat's beim ersten Mal auch nicht auf Anhieb geklappt.
Eine Lücke, die ich noch nicht geschlossen hab: Das läuft aktuell als manuell gestarteter Prozess, kein systemd-Benutzerdienst, übersteht also keinen Reboot von selbst. Eine systemd-User-Unit würde das lösen. Hab ich bisher nur noch nicht eingerichtet.
Wie es sich tatsächlich angefühlt hat
Beim Streamen auf den JMGO N1S Pro über ein normales Heimnetzwerk fühlte sich der Desktop responsiv genug an, um ihn zu bedienen, nicht nur zuzuschauen, und Ton und Bild blieben synchron. Das ist ein echter Eindruck aus echter Nutzung, keine Zahl aus einer reproduzierbaren Benchmark — ich hab weder Auflösung noch Bitrate noch eine gemessene Round-Trip-Zeit protokolliert. Wenn du für was Latenzkritisches harte Zahlen brauchst, miss dein eigenes Setup.
Wo Hermes einen Blick wert sein könnte
Wenn du mit normalem Sunshine bei deinem speziellen Linux/Wayland/AMD-Setup nicht weiterkommst — sei es der Portal-Capture-Schritt oder ein VAAPI-Treiberpfad-Mismatch — gibt es Hermes: einen Fork von Apollo, das selbst wiederum ein Fork von Sunshine ist. Es setzt unter anderem auf ein eigenes Kernelmodul für direktes Capture statt über das Desktop-Portal und kann bei bestimmten AMD-/Wayland-Konfigurationen eine Alternative sein. Das Projekt wird aktiv gepflegt, auch wenn die geerbte Fork-Historie auf GitHub auf den ersten Blick einen anderen Eindruck erwecken kann. Die eigene Doku ist allerdings für Arch und CachyOS geschrieben, auf openSUSE heißt das also: Build aus dem Quellcode statt Paketinstallation — ein echter Schritt mehr Aufwand als die normale Sunshine-Installation oben.
Und hier kommt der Teil, wegen dem ich es wieder ins "nur für Fortgeschrittene"-Regal gestellt hab: Das Kernelmodul muss signiert werden, und das Zertifikat dazu muss über Secure Boots MOK-Manager (Machine Owner Key) registriert werden — ein einmaliger Schritt, der physischen Tastatur-/Monitor-Zugriff beim Booten braucht. Bei mir hat's nicht ohne diesen Schritt geklappt: Ich hab das Modul selbst gebaut, aber laden ließ es sich erst, nachdem ich den Schlüssel über den physischen MOK-Manager-Bildschirm eingetragen hatte. Auf vielen vorinstallierten oder entsprechend eingerichteten Systemen ist Secure Boot aktiv — das ist also kein seltener Sonderfall, auch wenn sich Secure Boot grundsätzlich abschalten lässt.
Erst normales Sunshine probieren. Hermes nur ansehen, wenn du auf ein Problem stößt, das es nachweislich löst.
Fehlerbehebung
- Kein Berechtigungsdialog beim Streaming-Start: prüfen, ob
xdg-desktop-portalund das KDE-Portal-Backend tatsächlich laufen, und obcapture = portalin der Konfiguration wirklich gesetzt ist. - Schwarzes Bild, Ton geht: häufig liegt es am Capture-Backend — nachsehen, ob die Einstellung im Tab "Configuration" wirklich übernommen wurde und Sunshine danach neu gestartet wurde. Kann aber auch an Codec-, Treiber- oder Decoder-Problemen liegen.
- Kein Ton beim Client: Sunshines Audiogeräte-Auswahl im Web-UI prüfen; das Standard-Audiogerät des Systems kann sich nach einem Reboot ändern.
- Controller reagiert nicht: separate Geräteberechtigung nötig,
uinput-Zugriff prüfen. - Ruckelnde Wiedergabe: erst Auflösung/Bitrate senken, um Netzwerk- von Encoding-Problemen zu unterscheiden.
- Hohe Latenz trotz gutem Netzwerk: aktiven Encoder in den Logs prüfen — sicherstellen, dass er nicht stillschweigend auf Software umgeschaltet hat.
- Host wird nicht gefunden: prüfen, ob beide Geräte im selben LAN sind, nicht in einem Gäste-Netzwerk oder isolierten WLAN, notfalls per IP direkt hinzufügen.
Also, was soll ich nehmen?
Musst du kurz was spiegeln und deine Hardware kann Miracast sauber? Nimm Miracast. Willst du einen Desktop auf dem Fernseher, den du wirklich bedienen kannst, für Gaming oder alles Interaktive? Sunshine und Moonlight, nach der Anleitung oben. Kommst du bei normalem Sunshine an eine Grenze und bist mit Secure-Boot-Key-Enrollment vertraut? Schau dir Hermes an — aber nicht als ersten Schritt.
Bist du hier gelandet, weil dich Chromecast im Stich gelassen hat: Das hier ist kein Workaround dafür. Es ist ein anderer, responsiverer Weg, das Ganze zu machen — dafür musst du allerdings einmal etwas Zeit in die Einrichtung stecken.