Von Arch Linux Minimal zu dwm 6.8: Mein kompletter Cthulhu-Gaming-Desktop

Mein Hauptrechner heißt Cthulhu. Er hat einen Ryzen 7 5800X3D, eine PowerColor Radeon RX 9060 XT mit 16 GiB und zwei Monitore. Mit ihm arbeite ich an GitHub-Projekten, meiner Website und dem NEBUVERSE, spiele über Steam und Lutris und nehme gelegentlich mit OBS auf. Mein Ziel bei diesem Neuaufbau war kein Screenshot-Rekord: ein schnelles, überschaubares System, das im Alltag tatsächlich alles kann.

Am 20. Oktober 2026 fing ich erneut mit Arch Linux Minimal an. Am Folgetag stand dwm 6.8 mit sauber konfiguriertem Xorg, Fastfetch, Chrome, deutschen Tastenkürzeln und funktionierenden Spiele-Laufwerken. Unser letzter praktische Erfolg war eine echte Vulkan-Spielaufnahme in OBS – nicht irgendein schwarzer Game-Capture-Bildschirm. Dieser Artikel hält den überprüfbaren Weg vom Minimal-System bis zum funktionierenden Recording fest.

Warum ich Cthulhu erneut aufgebaut habe

Ich mag NixOS und XMonad, und mein Kanagawa-Dragon-XMonad-Desktop bleibt ein eigenständiges, dokumentiertes Projekt. Diesmal wollte ich aber etwas anderes: einen Rechner, den ich auf Arch-Minimal-Basis installiere und dann mit einem kleinen, selbst gepflegten dwm 6.8 aufbaue. Kein Plasma als Übergangslösung, kein vollständiges Desktop-Environment im Hintergrund, keine Komponente nur deshalb, weil ein großes Desktop-Paket sie mitbringt.

Wichtig war auch mein bisheriges AMD-Problem: Anspruchsvolle Spiele hatten unter mehreren Distributionen schon GPU-Hänger und sogar schwarze Bildschirme mit einem auf 100 Prozent laufenden Lüfter ausgelöst. Die Neuinstallation war kein Beweis für eine Reparatur. Zuerst wollte ich die Arbeitsumgebung stabil einrichten – und dann AMD-Treiber, Vulkan und Spiele nachvollziehbar prüfen.

1. Arch Minimal: erst die Basis, dann der Desktop

Vor der Installation waren die Laufwerke eine wesentliche Sicherheitsfrage. Ich wollte ausschließlich die vorgesehene System-NVMe neu installieren. Die beiden Samsung-860-EVO-Spiele-SSDs und die separate Homelab-NVMe sollten unangetastet bleiben. Gerade auf einem Rechner mit mehreren ähnlich großen Datenträgern ist die Seriennummer des Ziellaufwerks wichtiger als eine flüchtige Bezeichnung wie /dev/nvme0n1, die sich ändern kann.

Das Ergebnis ist ein schlankes Arch Linux mit systemd, lokaler Benutzeranmeldung und ohne grafischen Login-Manager. Die Basiseinrichtung – Benutzer, Netzwerk, Arch-Pakete, Boot und Mounts – blieb bewusst getrennt vom späteren Desktop-Bootstrap. Genau diese Grenze ist auch im öffentlichen Cthulhu-Repository beschrieben.

2. Btrfs, systemd-boot und die echten Laufwerke

Wir hatten zwischenzeitlich über GRUB, Btrfs-Snapshots und weitere Boot-Varianten gesprochen. Der tatsächlich geprüfte Cthulhu-Stand verwendet jedoch systemd-boot mit einer Unified Kernel Image (UKI), arch-linux.efi. Die Root-Partition nutzt Btrfs mit Subvolume @. Für den Bootloader wurde ein dreisekündiges Menü eingerichtet; zusätzlich liegt eine separate Rettungs-UKI bereit. Secure Boot war bei der Prüfung deaktiviert.

Die drei Datenlaufwerke wurden über ihre UUIDs in /etc/fstab eingebunden und anschließend mit findmnt und beim Steam-Test kontrolliert. Beim Übertragen auf andere Rechner müssen die eigenen UUIDs eingesetzt werden. Niemand sollte fremde UUIDs, PARTUUIDs oder EFI-Pfade blind übernehmen.

Die richtige Reihenfolge war deshalb: erst Boot und Datenträger verifizieren, dann die grafische Umgebung aufbauen. Das bewahrte uns davor, für ein hübsches dwm-Setup versehentlich ein funktionierendes Boot-System oder die Spielebibliotheken anzufassen.

3. Meine dwm-Dateien von GitHub statt einer Desktop-Distribution

Das gewünschte Repository-Verzeichnis war von Anfang an klar: dennishilk/cthulhu/Arch/dwm. Die dwm-Quellen und Konfiguration sollten unter meinem Home-Verzeichnis liegen – konkret ~/.config/dwm/. Keine wilden Quelldateien direkt unter /usr/local, kein „ich kopiere irgendetwas in den Root-Bereich“-Setup.

Nach der fertigen Arch-Basis gab es einen wiederholbaren Bootstrap-Weg. Im Wiki-/Tutorial-Modus gilt: jeden Schritt einzeln ausführen, Ausgabe kontrollieren und erst dann weitergehen.

git clone https://github.com/dennishilk/cthulhu.git

cd cthulhu/Arch/dwm

bash ./install.sh

Das Skript installiert unter anderem Xorg/Xinit, Kitty, Fish, Rofi, Fastfetch, feh, Picom, Thunar und PipeWire; es kümmert sich um Mesa/RADV und die 32-Bit-Vulkan-Grundlage. Anschließend lädt es den offiziellen dwm-Tag 6.8, wendet unsere kleinen, gezielten Änderungen an und kompiliert den Window Manager lokal. yay und Google Chrome folgen über das AUR – dessen Build-Skripte sollte man wie bei jedem AUR-Projekt prüfen.

Der Installer kontrolliert vorab, ob Arch, sudo und das aktivierte multilib-Repository vorhanden sind. Er partitioniert keine Platten und schreibt weder Bootloader noch fstab. Unser installiertes dwm-Binary liegt schließlich unter ~/.local/bin/dwm.

4. dwm 6.8: Mein Fensterverhalten, meine Tastenkürzel

Standard-dwm ist winzig und lässt sich im Quelltext konfigurieren. Unsere Version bleibt bewusst reduziert: keine dwm-Leiste, kein Systray, keine blinkenden Effekte, keine unnötigen Tags. Ein Monitor, ein Arbeitsbereich; Fenster kacheln in Master-/Stack-Anordnung. Bei zwei normalen Fenstern ist die Aufteilung 50/50, mit 12 px äußeren und 8 px inneren Abständen. Rahmenbreite: null.

Wir haben Rofi bewusst im schlichten Standarddesign gelassen. dmenu wurde überflüssig und entfernt. Ebenso tauschten wir den zunächst installierten Screenshoter flameshot gegen maim: Drucktaste, Bereich aufziehen, PNG landet im Screenshot-Verzeichnis. Ohne zusätzlichen Dialog und ohne Screenshot-Portal.

Ein spätere dwm-Änderung wird lokal neu gebaut – das ist bei einem Quelltext-Window-Manager kein Bug, sondern die Idee:

~/.config/dwm/rebuild.sh

Der Build installiert das Binary wieder nach ~/.local/bin/dwm; die neue Version wird beim nächsten Xorg-Start geladen. Die vollständigen Einstellungen stehen in Arch/dwm/config.h und den zugehörigen Patch-Skripten.

5. Kitty, Fish, Fastfetch, Wallpaper und btop

Auf meinem Screenshot siehst du links das transparente Kitty mit unserem Fastfetch und rechts den btop-Systemmonitor. Das ist keine Mock-up-Oberfläche: Der Screenshot entstand am 22. Oktober auf Cthulhu. Fastfetch zeigt unter anderem „I use Arch btw“, dwm, die AMD-GPU und die eingebundenen Datenträger. Sein eigenes Bild ist in der Projektkonfiguration unter Arch/fastfetch/ hinterlegt.

Kitty nutzt JetBrains Mono Nerd Font, 12 pt, 10 px Innenabstand und eine Hintergrund-Deckkraft von 0,85. picom liefert dezente Schatten, aber weder Blur noch Fade. Genau diese Zurückhaltung macht das Wallpaper sichtbar, ohne dass das Terminal seine Lesbarkeit verliert.

Fish übernimmt die interaktive Shell. Wichtig ist eine Kleinigkeit aus unserem Feinschliff: Fastfetch startet nur in interaktiven Kitty-Fenstern, nicht auf einer Textkonsole, nicht über SSH und nicht in Skripten. Die normale Fish-Begrüßung haben wir abgeschaltet. Den Fastfetch-Zähler haben wir als persönlichen Rechner-Gag auf 1500 Tage gesetzt; er ist kein gemessener Arch-Installationszeitraum.

Der grafische Start braucht keinen Display Manager: Eine lokale Anmeldung auf TTY1 führt über Fish zu startx und dann zu ~/.config/dwm/start.sh. SSH-Sitzungen lösen das ausdrücklich nicht aus. So bleibt der Weg vom Login bis zum Window Manager leicht nachvollziehbar.

6. Zwei Monitore mit 144 Hz und 60 Hz

Mit einem Ultrawide-Display und einem Full-HD-Monitor ist eine pauschale „Auto“-Konfiguration nicht besonders hilfreich. Wir haben die echten XRandR-Namen unter nativem Xorg geprüft:

Der zweite Monitor sitzt dabei vertikal zentriert. Das Startskript prüft beide Anschlüsse und den 144-Hz-Modus, bevor es die Anordnung setzt; die Wallpaper werden pro Bildschirm mit feh geladen. Die erkannten Namen können sich mit GPU, Monitoranschluss und Xorg-Version ändern – HDMI-A-1 aus einer DRM-Ausgabe ist beispielsweise nicht automatisch der XRandR-Name.

7. Audio, Dateien, Zwischenablage und Systemdienste

Ein Window Manager macht allein noch keine Workstation. Wir wollten Chrome, Thunar mit Wechseldatenträger-Unterstützung, Mousepad, Archive, VLC, einen brauchbaren Clipboard-Manager und selbstverständlich Ton. Deshalb sind PipeWire, pipewire-pulse, WirePlumber und wpctl integriert. Die Lautstärketasten sprechen den Standard-Ausgang direkt an – ohne ein vollständiges Desktop-Environment.

Thunar arbeitet zusammen mit Tumbler, GVfs, udisks2 und einem Polkit-Agenten. xfce4-clipman läuft allein, ohne XFCE-Panel; das Clipboard bleibt nach dem Schließen eines Quellfensters erhalten, die Historie wird beim Beenden nicht dauerhaft gespeichert. NetworkManager, Zeitabgleich, regelmäßiges TRIM und eine wöchentliche Pacman-Cachebereinigung gehören ebenfalls zum vorgesehenen Basissystem. Die Firewall ist auf eingehend verweigern, ausgehend erlauben angelegt; der Installer aktiviert sie ausdrücklich nicht aus einer SSH-Sitzung heraus.

Auch GIMP wurde später installiert, für Bildbearbeitung neben dem schlanken Desktop. Wir haben bewusst auf Bluetooth-Dienste, Drucker-Stack, zusätzliche Benachrichtigungsprogramme und weitere Panel-Apps verzichtet. Das ist weniger ein Wettkampf um hundert MiB RAM als der Wunsch, jede aktive Komponente erklären zu können.

8. RX 9060 XT: Mesa, RADV und 32-Bit-Vulkan

Die Radeon RX 9060 XT ist eine RDNA4-/Navi44-Karte. Ein sichtbarer Xorg-Desktop genügt nicht, um einen funktionierenden Linux-Gaming-Stack zu bestätigen. Wir haben deshalb den amdgpu-Treiber, den Mesa-/RADV-Pfad, Vulkan sowie die benötigten 32-Bit-Bibliotheken für Steam und Proton zum ausdrücklichen Teil des Setups gemacht. Wichtig sind die Arch-Pakete mesa, lib32-mesa, vulkan-radeon, lib32-vulkan-radeon, vulkan-icd-loader und lib32-vulkan-icd-loader.

Die Installation verwendete das aktivierte multilib-Repository. Danach haben wir OpenGL, Vulkan und die 32-Bit-Grafikunterstützung überprüft, bevor die Spiele an die Reihe kamen. Das ist keine Beliebigkeit: Viele Windows-Spiele unter Proton brauchen neben 64-Bit-Vulkan auch den 32-Bit-Pfad oder gemischte Bibliotheken.

Dass dwm und Chrome laufen, sagt noch nichts über die alten GPU-Hardlocks in S.T.A.L.K.E.R. 2 aus. Die zeitlich spätere AMDGPU-Blackbox-Untersuchung dokumentiert auf genau diesem Arch-System einen echten GFXHUB Page Fault mit Ring-Timeout und gerettetem Coredump. Die Ursache ist weiterhin offen.

9. Steam, Proton und die Spielbibliotheken

Erst als Audio und Grafik-Grundlage passten, installierten und prüften wir die Spieleprogramme. Steam läuft, die beiden bestehenden ext4-Spielebibliotheken auf Games.Vol1 und Games.Vol2 sind wieder erreichbar. Lutris kam für Spiele außerhalb von Steam hinzu. Das ist für mich der praktische Maßstab: Ich möchte mich nicht nach jedem Distributionswechsel durch Hunderte GiB Downloads kämpfen, nur weil die Mounts fehlen.

Für Windows-Spiele nutzen wir Steam Play/Proton; beim S.T.A.L.K.E.R.-Test war Proton 11.0.2 eingestellt. Nicht jede Spielkompatibilität und nicht jeder moderne Vulkan-Titel ist damit automatisch garantiert. Insbesondere unsere AMDGPU-Abstürze in anspruchsvollen Spielen bleiben eine getrennte technische Baustelle.

10. OBS: Erst VAAPI/AV1, dann richtige Vulkan-Spielaufnahme

Hier endet die eigentliche Installationsgeschichte – mit dem Teil, der mir bei einem schlanken X11-Window-Manager besonders wichtig war: nicht bloß OBS öffnen können, sondern wirklich flüssig aufnehmen.

Erste Stufe: funktionierende Hardware-Aufnahme

Wir installierten OBS Studio und prüften zunächst Bild und Ton. Für die Aufnahme verwendeten wir die Hardware-Encoding-Funktion der Radeon über FFmpeg VAAPI mit AV1. Die tatsächlich getesteten Einstellungen waren 3440 × 1440, 60 FPS, CQP/QP 24 und ein MKV-Ausgabeformat. Das Aufnahmeziel lag auf der separat eingebundenen NVMe unter /mnt/Homelab/Obs.

Die ersten Tests zeigten 60,00 FPS ohne verworfene Frames, Bild und Ton funktionierten. OBS meldete dabei ungefähr 0,5 % CPU-Auslastung. Diese Zahl stammt aus OBS' Anzeige, nicht aus einem unabhängig gemessenen Benchmark. Auf diese Weise mussten wir die eigentliche Aufnahme nicht mehr gegen die Leistungsfähigkeit des Encoders erraten.

Zweite Stufe: echte Vulkan-Spielaufnahme

Für die nächste Stufe brauchten wir eine Game-Capture-Quelle für Vulkan-Spiele unter Linux. Wir installierten über das AUR obs-vkcapture-git und lib32-obs-vkcapture-git. Nach dem Neustart von OBS erschien in der Quellenauswahl „Spielaufnahme“. Das war der entscheidende Unterschied zu einer reinen Desktop- oder Fensteraufnahme.

yay -S --needed obs-vkcapture-git lib32-obs-vkcapture-git

Danach testeten wir mit Quake II über Steam. In den Startoptionen des Spiels stand exakt diese einzelne Umgebungsvariable:

OBS_VKCAPTURE=1 %command%

Das Ergebnis: Sieben Minuten echte Vulkan-Spielaufnahme, ausgezeichnete Bildqualität und nach OBS-Anzeige nur etwa 0,1–0,3 % CPU-Auslastung. Das ist der Abschluss, auf den ich bei Cthulhu gewartet hatte: Arch Minimal → dwm → AMD/RADV → Steam → aufgenommenes Vulkan-Spiel.

11. Was funktioniert – und was der Neuaufbau nicht beweist

Am Ende stehen Arch Linux, dwm 6.8, Google Chrome, Fish, Kitty, Fastfetch, btop, Thunar, Rofi, maim (für Screenshots), PipeWire, Steam, Lutris und OBS als funktionierender Daily-Driver-Stack. Die zwei unterschiedlichen Monitore sind eingerichtet, die Spielbibliotheken bleiben erhalten, die Radeon unterstützt die getestete Vulkan-Aufnahme.

Ich sage bewusst nicht, dass Arch, dwm oder Proton unsere früheren RX-9060-XT-Hardlocks vollständig repariert haben. Dafür gibt es keinen Beleg. Wir haben außerdem nicht gemessen, ob dwm mehr FPS bringt als Plasma oder XMonad. Die Gründe für dieses Setup sind Transparenz, nachvollziehbare Konfiguration und ein überzeugender Praxistest, keine Fantasie-Benchmarks.

Der Screenshot erzählt deshalb mehr als „schaut mal meinen Rice an“. Er zeigt einen nachvollziehbar aufgebauten Rechner, auf dem ich wieder arbeiten, entwickeln, spielen und aufnehmen kann.

Selbst nachbauen: Quellen, Sicherheit und Grenzen

Die kompletten dwm-Dateien liegen öffentlich auf GitHub: install.sh, config.h, Patches, Start- und Rebuild-Skript, Rofi-/Kitty-/Picom-Konfiguration, Fish-Hooks und Fastfetch-Vorlagen. Der Artikel ist ein Erfahrungsbericht mit reproduzierbarem Desktop-Teil, kein universeller Arch-Datenträger-Installer. Vor dem Ausführen solltest du die Befehle lesen und deine Laufwerks-/Monitor-Konfiguration separat prüfen.

Wer nur einen Teil braucht, kann direkt in die Einzeldateien schauen: Monitor- und Xorg-Start, dwm-Kürzel und Layout, Kitty und vollständige Projektanleitung. Für OBS-Vulkan-Capture siehe auch das Open-Source-Projekt obs-vkcapture.

Stand: 22. Oktober 2026. Installation und OBS-/Quake-II-Test: 20.–21. Oktober. Screenshot: Originalaufnahme des laufenden Arch-/dwm-Desktops vom 22. Oktober 2026, nur für die Website verlustbehaftet als WebP optimiert; das Wallpaper beziehungsweise Figurenmotiv ist nicht als eigenes Kunstwerk beansprucht. Grundlage: persönliche Terminaltests und versionierte Cthulhu-Quelldateien. Diese Beschreibung ist nicht als Garantie für andere Hardware zu verstehen.