guides

Textexpansion unter Wayland: Warum sie ausfällt und was wirklich funktioniert

Trofin Sorin-IoanTrofin Sorin-IoanCTO, Lightning Assist26. Juli 20269 Min. Lesezeit
waylandlinuxx11text-expandergnomekdexwaylandinput
Teilen:
Textexpansion unter Wayland: Warum sie ausfällt und was wirklich funktioniert

Kurzantwort: Text-Expander müssen systemweit jeden Tastenanschlag beobachten und Tippen in die jeweils fokussierte App simulieren. X11 erlaubte beides standardmäßig; die Compositors von Wayland schränken beides aus Sicherheitsgründen bewusst ein – deshalb kann ein Text-Expander, der unter Ubuntu 20.04 perfekt funktioniert, sauber installieren und in einer modernen Wayland-Sitzung absolut gar nichts tun – ohne Fehlermeldung. Es gibt keine einzelne Lösung; die echten Optionen sind XWayland (die alte Methode, innerhalb einer Kompatibilitätsschicht), ein evdev/uinput-Backend mit explizitem Zugriff über die Input-Gruppe, oder ein dediziertes Low-Level-Input-Backend, das einmalig um eine Berechtigung bittet. Lightning Assist nutzt Letzteres.

Wenn Sie einen Text-Expander installiert, Ihren Trigger getippt und zugesehen haben, wie nichts passiert – kein Fehler, kein Absturz, nur Stille –, sind Sie sehr wahrscheinlich unter Wayland unterwegs, und das ist eine bekannte Problemkategorie, kein Bug, der spezifisch für das gewählte Tool ist.

Warum Wayland globales Tastatur-Mithören blockiert

Unter X11 kann jeder Prozess einen Low-Level-Tastatur-Hook registrieren und jeden Tastenanschlag im System lesen, und jeder Prozess kann Tastenanschläge in das jeweils fokussierte Fenster simulieren – genau das tun Tools wie xdotool, und deshalb funktionieren Text-Expander, Hotkey-Manager und Fernsteuerungssoftware seit zwei Jahrzehnten unter Linux ohne große Reibung. Aus Sicherheitssicht ist das aber auch genau die Art Verhalten, die man standardmäßig nicht will: Jede Anwendung, auch eine kompromittierte, kann Ihre Tastenanschläge protokollieren oder beliebige Eingaben in Ihre Banking-Sitzung einschleusen.

Waylands Compositors (Mutter für GNOME, KWin für KDE Plasma, wlroots-basierte für Sway und Ähnliches) wurden um den gegenteiligen Standard herum entworfen: Eine Anwendung sieht nur die Eingabeereignisse, die für ihr eigenes Fenster bestimmt sind, und nichts kann synthetische Eingaben in eine andere Anwendung einschleusen, ohne einen expliziten, bewusst dafür vorgesehenen Mechanismus. Das ist kein Versehen oder fehlendes Feature – es ist das Sicherheitsmodell, das wie beabsichtigt funktioniert. Der Preis: Jedes Tool, das sich auf X11s Verhalten „jeder Prozess kann mithören und einschleusen" verlassen hat, braucht einen anderen, meist eingeschränkteren Weg, dieselbe Aufgabe zu erledigen.

Das praktische Ergebnis: Ein Text-Expander, der Tastenanschläge auf die X11-Art abfängt, sieht in einer reinen Wayland-Sitzung nichts, und ein Text-Expander, der Text auf die X11-Art einschleust, hat nichts, wohin er einschleusen könnte. Meist scheitert das lautlos statt mit einer klaren Fehlermeldung, weil keine Exception geworfen wird – die Ereignisse, auf die er wartet, kommen einfach nie an.

Warum Browser-Erweiterungen den Desktop nicht abdecken

Ein naheliegender Workaround ist ein Text-Expander auf Basis einer Browser-Erweiterung, und für Browser-Tabs allein funktioniert das auch – Erweiterungen arbeiten innerhalb des DOM der Seite, was mit Waylands Eingabemodell nichts zu tun hat. Das Problem ist der Umfang: Eine Erweiterung sieht immer nur den Browser, in dem sie installiert ist. Sie kann kein Snippet in Ihrem Terminal, Ihrer IDE, einer nativen GTK- oder Qt-Anwendung, dem Desktop-Client von Slack oder Discord oder einem PDF-Reader expandieren. Wenn Ihr Tag irgendetwas außerhalb eines Browser-Tabs beinhaltet – was für Entwickler und Support-Teams die meiste Zeit des Tages ausmacht –, löst eine Browser-Erweiterung nur einen Bruchteil des Problems und lässt den Rest Ihres Desktops ungedeckt.

Was auf Wayland heute tatsächlich existiert

Es gibt keine universelle Lösung, aber eine Handvoll echter, dokumentierter Ansätze, jeder mit eigenen Kompromissen.

XWayland – die alte Methode, innerhalb einer Kompatibilitätsschicht

Die meisten Wayland-Desktop-Umgebungen (GNOME, KDE Plasma standardmäßig unter Ubuntu 22.04+, Fedora 38+ und Ähnliches) lassen XWayland parallel zum nativen Wayland-Compositor laufen – eine Kompatibilitätsschicht, die reine X11-Anwendungen weiter funktionieren lässt. Ein Tool, das auf X11-Input-Hooks basiert, funktioniert weiterhin für Anwendungen, die innerhalb von XWayland laufen. Der Haken ist der Umfang: Wenn Sie in einer Sitzung sind, in der XWayland explizit deaktiviert ist (manche gehärteten GNOME-Konfigurationen), oder die konkrete Anwendung, in die Sie tippen, ein nativer Wayland-Client statt ein XWayland-Client ist, erreicht X11-artiges Hooking sie nicht.

Das Protokoll zwp_virtual_keyboard_v1

Manche Wayland-Compositors – darunter GNOMEs Mutter und KDEs KWin – implementieren das Wayland-Protokoll zwp_virtual_keyboard_v1, das einer Anwendung einen sanktionierten Weg gibt, Tastaturereignisse zu simulieren. Das kommt einer eingebauten, protokollbasierten Antwort näher als einem Workaround, ist aber compositor-abhängig: Eine App, die sich darauf verlässt, funktioniert nur dort, wo der Compositor sich entschieden hat, dieses Protokoll zu implementieren, und das Verhalten kann trotzdem variieren – manche Setups weichen auf einen Zwischenablage-Einfüge-Ersatz aus, der sich in Apps mit besonderer Paste-Behandlung anders verhalten kann (etwa ein Terminal mit Bracketed-Paste-Modus).

Die RemoteDesktop-Schnittstelle von xdg-desktop-portal

Die freedesktop.org-Portal-Spezifikation definiert eine RemoteDesktop-Schnittstelle, die explizit dafür gebaut wurde, „das Fernsteuern einer Desktop-Sitzung zu erlauben" – sie kann Tastatur- und Mausereignisse einschleusen, aber erst, nachdem der Nutzer beim Sitzungsstart KEYBOARD/POINTER-Zugriff gewährt hat, und es ist ein berechtigungsbeschränkter Sitzungsmechanismus statt eines dauerhaft aktiven Systemhooks. Es ist die von Wayland vorgesehene, sanktionierte Tür für Input-Injection, aber sie wurde für Fernsteuerungs- und Bildschirmfreigabe-Tools entworfen, nicht dafür, „lautlos jeden von mir getippten Trigger dauerhaft im Hintergrund zu erkennen" – genau das, was ein Text-Expander eigentlich braucht.

evdev/uinput mit Zugriff über die Input-Gruppe

Die Low-Level-Option besteht darin, rohe Eingaben direkt aus /dev/input (evdev) zu lesen und synthetische Ereignisse über /dev/uinput einzuschleusen, wobei Waylands Eingabemodell komplett umgangen wird. Das ist wirklich compositor-übergreifend – es spielt keine Rolle, ob Sie GNOME, KDE oder Sway nutzen, weil es unterhalb von allen dreien, auf Kernel-Input-Ebene, operiert. Espanso nutzt genau diesen Ansatz für seine Wayland-Unterstützung, den die eigene Dokumentation als „currently experimental" beschreibt: Es braucht eine einmalige setcap cap_dac_override+p-Freigabe auf der Binärdatei (oder Mitgliedschaft in der input-Gruppe, je nach Setup), um rohe Eingaben zu lesen, ohne als Root zu laufen, und es kommt mit bekannten Einschränkungen – Nicht-US-Tastaturlayouts brauchen explizite Konfiguration, GNOME-Sitzungen können Zwischenablage-Backend-Flackern zeigen, und das Anschließen einer neuen Tastatur erfordert einen manuellen Neustart des Dienstes. Es funktioniert, aber „experimentell" ist das richtige Wort für den aktuellen Stand.

Tools, die Wayland schlicht nicht unterstützen

Manche Linux-Automatisierungstools sind direkt auf xdotool und dem X11-Fensterbaum aufgebaut, ganz ohne Wayland-Pfad – AutoKey ist das klarste Beispiel: Es ist reines X11, und XWayland hilft nicht, weil seine Input-Simulation direkt auf den X11-Fensterbaum zielt, nicht auf den Compositor. Wenn Sie in einer reinen Wayland-Sitzung sind, funktionieren solche Tools schlicht nicht, unabhängig von der Konfiguration.

Wie Lightning Assist damit umgeht

Lightning Assist verfolgt je nach Sitzungstyp einen zweigleisigen Ansatz. Unter X11 und in XWayland-Sitzungen nutzt es Standard-X11-Input-Hooks – denselben Mechanismus, der seit Jahren zuverlässig unter Linux funktioniert. In einer reinen Wayland-Sitzung wechselt es zu einem dedizierten Low-Level-Input-Backend: Beim ersten Mal, wenn es gebraucht wird, fragt die App einmal nach Eingabezugriff (ein „Grant access"-Prompt), und nach dieser einmaligen Freigabe funktionieren globale Tastenerkennung und Textexpansion gleichermaßen unter GNOME, KDE und anderen Compositors – kein YAML, kein selbst auszuführender setcap-Befehl, kein Konfigurationsschritt pro Tastaturlayout. Das ist ein eigens dafür gepflegtes Backend, kein nachträglich angeflanschter Fallback, und das Einmal-Freigabe-Modell bedeutet, dass Sie keinen manuellen Schritt bei jeder Sitzung wiederholen müssen.

Eine praktische Checkliste, bevor Sie sich für ein Tool entscheiden

Angesichts der vielen Unterschiede zwischen den Tools lohnt es sich, vor der Entscheidung für eines auf einem Wayland-Desktop ein paar Dinge zu prüfen:

  • Dokumentiert es Wayland-Unterstützung explizit, oder behauptet es nur pauschal „Linux-Unterstützung"? Pauschale Aussagen bedeuten oft „auf X11 getestet", mit ungetestetem Wayland-Verhalten.
  • Braucht es einen manuellen setcap- oder Root-Schritt, um unter Wayland zu funktionieren? Kein Ausschlusskriterium, aber Sie sollten das vorher wissen statt es erst nach der Installation zu entdecken.
  • Nennt es konkrete Compositor-Einschränkungen (GNOME, KDE, Sway) statt eines pauschalen „funktioniert unter Wayland"? Tools, die ehrlich über compositor-spezifische Eigenheiten sind (Zwischenablage-Flackern, Tastaturlayout-Konfiguration, Neustart bei neuem Gerät), wurden meist tatsächlich dort getestet.
  • Muss XWayland aktiviert bleiben? Wenn ein Tool nur über XWayland funktioniert, prüfen Sie, ob Ihre Desktop-Umgebung es standardmäßig aktiviert hat (die meisten tun das), bevor Sie von Kompatibilität ausgehen.

Häufig gestellte Fragen

Warum funktioniert mein Text-Expander auf einem Linux-Rechner, aber nicht auf einem anderen?

Die häufigste Ursache ist der Sitzungstyp: X11-Sitzungen und Wayland-Sitzungen behandeln globale Eingaben völlig unterschiedlich, und ein Tool, das primär um X11-Input-Hooks herum gebaut ist, kann auf dem einen einwandfrei funktionieren und auf dem anderen gar nichts tun. Führen Sie echo $XDG_SESSION_TYPE in einem Terminal aus, um zu prüfen, welchen Sitzungstyp Sie gerade nutzen.

Ist Wayland einfach kaputt für Produktivitätstools?

Nein – es ist ein anderes, restriktiveres Sicherheitsmodell, kein Bug. Dieselben Einschränkungen, die naive globale Input-Tools blockieren, machen es auch einer bösartigen App schwerer, Ihre Tastenanschläge zu protokollieren oder Eingaben in Ihre Banking-Sitzung einzuschleusen. Die Tools, die unter Wayland gut funktionieren, sind die, die gezielt um dessen Berechtigungsmodell herum gebaut wurden (Portals, zwp_virtual_keyboard_v1, oder ein dediziertes evdev/uinput-Backend mit Zugriff über die Input-Gruppe) statt solche, die X11-artigen uneingeschränkten Zugriff voraussetzen.

Zerstört das Deaktivieren von XWayland die Textexpansion?

Das kann passieren, bei jedem Tool, das sich auf X11-artige Hooks verlässt, um über XWayland laufende Anwendungen zu erreichen. Wenn Sie ein gehärtetes Setup mit explizit deaktiviertem XWayland haben, prüfen Sie gezielt, ob Ihr Text-Expander ein natives Wayland-Backend hat (nicht nur einen X11-Hook) – Lightning Assists dediziertes Wayland-Input-Backend und Espansos experimenteller evdev/uinput-Modus sind beide genau für diesen Fall gebaut; ein Tool, das rein auf xdotool oder X11-Fensterbaum-Zugriff aufbaut, wie AutoKey, ist es nicht.

Muss ich Terminal-Befehle ausführen, um Wayland-Unterstützung zum Laufen zu bringen?

Kommt auf das Tool an. Espansos Wayland-Modus braucht eine einmalige setcap-Freigabe (oder eine entsprechende Input-Gruppen-Mitgliedschaft), die Sie selbst ausführen. Lightning Assists Wayland-Backend fragt stattdessen beim ersten Mal, wenn es gebraucht wird, per In-App-Prompt einmalig nach „Grant access" – kein Terminal-Befehl nötig.

Weiterführende Artikel

Quellen

Ähnliche Artikel