Sway auf WSL2 zum Laufen bringen (und ein eigenes Tastaturlayout zähmen)
Ein Community-Repo, ein Proxy in meinem Netzwerk, drei Browser mit eigenen Zertifikatsspeichern und ein ergonomisches Tastaturlayout, das sich gelegentlich selbst vergisst.
Sway auf WSL2 lief größtenteils. Dann, ganz am Ende, schaltete ich ein ergonomisches Tastaturlayout ein und konnte plötzlich überhaupt nichts mehr tippen — ein passender Abschluss für eine Woche, die fast vollständig aus kleinen, dummen Ursachen hinter beunruhigenden Symptomen bestand.
Dies ist Teil vier einer Sway-Serie, die mit einem schwarzen Bildschirm auf meinem Dell XPS 13 begann, sich mit einer Statusleiste, die über meine Lautstärke log fortsetzte und mit einem Fedora-Upgrade im Dunkeln einen Umweg machte. Diesmal war die Maschine überhaupt nicht Linux — es war Windows, mit Sway innerhalb von WSL2.
Sway überhaupt zum Laufen bringen
Aufbau · Debian auf WSL2Ich begann mit einer frischen Debian-Installation auf WSL2 und folgte einem Community-Repo für den Betrieb von Sway dort. Die Installation von git scheiterte sofort mit unable to locate package — der Cache des Paketmanagers war leer. Einmal apt update auszuführen, bevor sonst irgendetwas auf einer frischen Installation installiert wurde, behob das.
Das Klonen des Repos scheiterte dann mit server verification failed: certificate signer not trusted, was auf einen Proxy in meinem Netzwerk zurückging, der HTTPS-Verkehr inspiziert. Ich exportierte das Root-Zertifikat des Proxys aus Windows (certmgr.msc → Trusted Root Certification Authorities → Export as Base-64 .CER), kopierte es mit der Endung .crt nach /usr/local/share/ca-certificates/ und führte update-ca-certificates aus.
Sway startete — technisch gesehen. Auf dem Bildschirm zeigte sich nichts, obwohl in der Windows-Taskleiste etwas mit einem seltsamen [WARN:COPY MODE]-Hinweis beim Überfahren mit der Maus auftauchte. Ein bekannter, rein kosmetischer WSLg-Anzeigefehler: wsl --update, gefolgt von wsl --shutdown aus PowerShell, dann ein Neustart, behob ihn.
Dann tat kein Tastaturkürzel mehr etwas. Ich nahm an, Windows würde die Windows-Taste abfangen. Der wahre Grund war einfacher: Die kopierte Sway-Konfigurationsdatei war völlig leer, es gab also überhaupt keine Tastenbelegungen, nicht einmal Standardwerte. Debians echte Standardkonfiguration von /etc/sway/config nach ~/.config/sway/config als Ausgangspunkt zu kopieren, löste das in einem Zug.
Es alltagstauglich machen
Aufbau · von funktionierend zu nutzbarAls Sway tatsächlich lief, begann ich, Alltagsanwendungen zu installieren, angefangen mit einem Browser. Dasselbe Zertifikatsproblem kam danach unabhängig in jedem Browser zurück, weil Browser nicht den Zertifikatsspeicher des Betriebssystems nutzen — sie führen ihren eigenen. Firefox brauchte das Zertifikat direkt importiert über Settings → Privacy & Security → View Certificates → Authorities → Import, oder alternativ p11-kit-trust.so als Sicherheitsgerät geladen, damit er den Systemspeicher automatisch liest. Ein separat installierter Chromium-basierter Browser brauchte dasselbe Zertifikat in seine eigene NSS-Datenbank importiert mit certutil -d sql:$HOME/.pki/nssdb (oder ~/.local/share/pki/nssdb, je nach Version) — die Korrektur auf Betriebssystemebene deckte keinen von beiden ab.
Ein UML-Diagrammwerkzeug öffnete sich als komplett leeres graues Fenster — ein bekannter, langjähriger Fehler, bei dem Java-Swing/AWT-Anwendungen unter nicht-reparentenden Tiling-Fenstermanagern wie Sway fehlerhaft dargestellt werden. Die Umgebungsvariable _JAVA_AWT_WM_NONREPARENTING=1 vor dem Start der Anwendung zu setzen, oder dauerhaft in ~/.bashrc, behob es.
Terminaltext sah merklich zu klein aus, aber nur auf dem eingebauten Bildschirm des Laptops, nicht auf einem externen Monitor. WSLg erkennt bildschirmspezifische DPI-Skalierung nicht zuverlässig automatisch, besonders bei gebrochenen Windows-Skalierungsprozentsätzen. Einen expliziten Skalierungsfaktor pro Ausgang direkt in Sways Konfiguration zu setzen — output WL-1 scale 1.25, wobei der Ausgangsname über swaymsg -t get_outputs gefunden wurde — behob, was WSLg nicht selbst ableiten konnte.
Die Geschichte des Tastaturlayouts
Geschichte · Ergonomie, zweimalDas letzte Projekt war Ergonomie: Neo2 einzuschalten, ein deutsches ergonomisches Tastaturlayout, für besseren Tippkomfort. Es schlug sofort fehl — ich konnte überhaupt nichts mehr tippen, weil Neo2 weit mehr Shift-Ebenen und Modifikator-Kombinationen nutzt, als ältere X11-Anwendungen erwarten, und die grundlegende Eingabe zerbrach. Ich erholte mich, ohne die Tastatur anzufassen: fügte mit der Maus per Rechtsklick swaymsg input "type:keyboard" xkb_variant "" in ein Terminal ein, was sofort zu normalem Deutsch zurückkehrte.
Ich entschied mich für einen Hybrid statt vollem Neo2: nur Neo2s ergonomische Buchstabenpositionen, während Zahlen, Satzzeichen und AltGr-Symbole genau als Standard-Deutsch blieben. Ich baute ihn mit einem Skript, das die echte Neo2-Definition direkt aus der installierten Tastaturdatenbank las (/usr/share/X11/xkb/symbols/de, der Abschnitt neo_base), statt das Layout aus dem Gedächtnis zu erraten, um eine exakte Übereinstimmung zu garantieren.
Ein Tastenkürzel, das zwischen den beiden Layouts umschalten sollte, tat still gar nichts. Ich jagte einigen falschen Fährten hinterher — einer doppelten Tastenbelegung, versteckten Windows-artigen Zeilenenden, Fokusannahmen — bevor ich mit xkbcli compile-keymap --verbose die eigentliche Ursache fand: Die Tastatur-Bibliothek des Compositors durchsuchte ~/.config/xkb gar nicht nach eigenen Layouts, wie es die Dokumentation nahelegte. Eine fertige Keymap-Datei vorab zu kompilieren mit xkbcli compile-keymap --include ~/.config/xkb --include-defaults --layout de,mylayout > ~/.config/xkb/mykeymap.xkb und Sway dann mit xkb_file in der Eingabekonfiguration direkt auf diese Datei zu verweisen, statt es das Layout live auflösen zu lassen, behob es.
Der Bau der Nur-Buchstaben-Version hatte still die AltGr-Sonderzeichen zerstört — wie @ —, die auf denselben Tasten lebten: Einen Teil der Symbolliste einer Taste zu überschreiben, ersetzt die ganze Liste, jede Ebene eingeschlossen, nicht nur die angegebenen Ebenen. Die Lösung war, beim Erzeugen des eigenen Layouts die AltGr-Ebene (Ebene 3+) für jede Taste aus dem Standard-Deutsch-Layout zu holen und hinter die neuen Neo2-Buchstaben anzuhängen, statt nur die ersten beiden Ebenen zu behalten.
Selbst nach alldem kehrte das eigene Layout still zu Standard-Deutsch zurück, jedes Mal, wenn der Fokus zu einem anderen Fenster wechselte. Die wahre Ursache: WSLgs RDP-basierte Tastaturbrücke synchronisiert das aktive Layout bei jedem Fokuswechsel neu aus Windows’ eigener Eingabesprache und kennt das Konzept eines Layouts, das nur innerhalb von Linux’ Keymap existiert, überhaupt nicht — eine echte, noch offene WSLg-Plattformbeschränkung, nicht etwas, das sich von der Linux-Seite aus beheben lässt.
Der Workaround ist eine Taste, die nach dem Fensterwechsel direkt zum Index des eigenen Layouts zurückspringt, statt zu versuchen, das Zurücksetzen selbst zu verhindern — ich nutzte Einfg, eine Taste, zu der ich sonst fast nie greife. Der tatsächliche Alltagsablauf ist also: Super+Links oder Super+Rechts, um eine Anwendung zu fokussieren, Einfg, um das Layout zurückzusetzen, dann tippen. Drei Tastendrücke, wo ich mir einen sauberen Wechsel gewünscht hatte. Aber es ist eine Taste, die mir nicht fehlt, und ich tippe im Hybrid-Layout, das ich von Anfang an wollte — nur mit einem kleinen Ritual daran.
Manchmal führt der einzige Weg zurück zur Tastatur über die Maus.