guides

Espansione del Testo su Wayland: Perché si Blocca e Cosa Funziona Davvero

Trofin Sorin-IoanTrofin Sorin-IoanCTO, Lightning Assist26 luglio 20269 min di lettura
waylandlinuxx11text-expandergnomekdexwaylandinput
Condividi:
Espansione del Testo su Wayland: Perché si Blocca e Cosa Funziona Davvero

Risposta rapida: i text expander devono osservare ogni pressione di tasto a livello di sistema e simulare la digitazione nell'app che ha il focus, qualunque essa sia. X11 permetteva entrambe le cose di default; i compositor di Wayland le limitano deliberatamente entrambe per motivi di sicurezza, ed è per questo che un text expander che funziona perfettamente su Ubuntu 20.04 può installarsi senza problemi e non fare assolutamente nulla in una sessione Wayland moderna — senza alcun messaggio di errore. Non esiste un'unica soluzione; le opzioni reali sono XWayland (funzionare alla vecchia maniera, dentro un livello di compatibilità), un backend evdev/uinput con accesso esplicito al gruppo input, oppure un backend di input dedicato a basso livello che richiede una singola autorizzazione una tantum. Lightning Assist usa quest'ultimo.

Se hai installato un text expander, digitato il tuo trigger, e non è successo nulla — nessun errore, nessun crash, solo silenzio — molto probabilmente sei su Wayland, ed è un problema di categoria nota, non un bug specifico dello strumento che hai scelto.

Perché Wayland blocca l'ascolto globale dei tasti

Su X11, qualsiasi processo può registrare un hook di tastiera a basso livello e leggere ogni pressione di tasto sul sistema, e qualsiasi processo può simulare pressioni di tasti nella finestra che ha il focus in quel momento — è letteralmente ciò che fanno strumenti come xdotool, ed è il motivo per cui text expander, gestori di hotkey e software di controllo remoto funzionano su Linux da vent'anni senza troppo attrito. È anche, dal punto di vista della sicurezza, esattamente il tipo di cosa che non vorresti per impostazione predefinita: qualsiasi applicazione, inclusa una compromessa, può registrare i tuoi tasti premuti o iniettare input arbitrario nella tua sessione bancaria.

I compositor di Wayland (Mutter per GNOME, KWin per KDE Plasma, quelli basati su wlroots per Sway e simili) sono stati progettati attorno al comportamento opposto: un'applicazione vede solo gli eventi di input destinati alla propria finestra, e nulla può iniettare input sintetico in un'altra applicazione senza un meccanismo esplicito e deliberato per farlo. Questa non è una svista o una funzionalità mancante — è il modello di sicurezza che funziona come previsto. Il costo è che ogni strumento che dipendeva dal comportamento "qualsiasi processo può osservare e iniettare" di X11 ha bisogno di un modo diverso, e solitamente più limitato, per fare lo stesso lavoro.

Il risultato pratico: un text expander che intercetta i tasti alla maniera di X11 non vede nulla in una sessione Wayland pura, e un text expander che inietta testo alla maniera di X11 non ha nulla in cui iniettarlo. Tipicamente fallisce silenziosamente invece che con un errore chiaro, perché non viene sollevata alcuna eccezione — gli eventi che sta ascoltando semplicemente non arrivano mai.

Perché le estensioni del browser non coprono il desktop

Una soluzione naturale è un text expander basato su estensione del browser, e per le sole schede del browser funziona — le estensioni operano dentro il DOM della pagina, che non ha nulla a che fare con il modello di input di Wayland. Il problema è l'ambito: un'estensione vede solo il browser in cui è installata. Non può espandere uno snippet nel tuo terminale, nel tuo IDE, in un'applicazione nativa GTK o Qt, nel client desktop di Slack o Discord, o in un lettore PDF. Se la tua giornata coinvolge qualcosa al di fuori di una scheda del browser — il che per sviluppatori e team di supporto è la maggior parte della giornata — un'estensione del browser risolve una frazione del problema e lascia scoperto il resto del tuo desktop.

Cosa esiste davvero su Wayland oggi

Non esiste una soluzione universale, ma esiste una manciata di approcci reali e documentati, ciascuno con i propri compromessi.

XWayland — funzionare alla vecchia maniera, dentro un livello di compatibilità

La maggior parte degli ambienti desktop Wayland (GNOME, KDE Plasma di serie su Ubuntu 22.04+, Fedora 38+ e simili) eseguono XWayland insieme al compositor Wayland nativo — un livello di compatibilità che permette alle applicazioni solo-X11 di continuare a funzionare. Uno strumento costruito sugli hook di input X11 continua a funzionare per le applicazioni che girano dentro XWayland. Il problema è l'ambito: se sei in una sessione dove XWayland è esplicitamente disabilitato (alcune configurazioni GNOME hardened), o l'applicazione specifica in cui stai digitando è un client Wayland nativo invece che uno XWayland, l'hooking in stile X11 non la raggiunge.

Il protocollo zwp_virtual_keyboard_v1

Alcuni compositor Wayland — tra cui Mutter di GNOME e KWin di KDE — implementano il protocollo Wayland zwp_virtual_keyboard_v1, che offre a un'applicazione un modo sancito per simulare eventi di tastiera. Questo è più vicino a una risposta integrata a livello di protocollo che a un espediente, ma dipende dal compositor: un'app che vi fa affidamento funziona solo dove il compositor ha scelto di implementare quel protocollo, e il comportamento può comunque variare — alcune configurazioni ricadono su un sostituto basato sull'incollaggio degli appunti, che può comportarsi diversamente in app con una gestione speciale dell'incolla (un terminale con modalità bracketed-paste, ad esempio).

L'interfaccia RemoteDesktop di xdg-desktop-portal

La specifica dei portal di freedesktop.org definisce un'interfaccia RemoteDesktop costruita esplicitamente per "consentire il controllo remoto di una sessione desktop" — può iniettare eventi di tastiera e del puntatore, ma solo dopo che l'utente concede l'accesso KEYBOARD/POINTER all'avvio della sessione, ed è un meccanismo di sessione con permessi limitati piuttosto che un hook di sistema sempre attivo. È la porta sancita che Wayland offre per l'iniezione di input, ma è stata progettata pensando a strumenti di controllo remoto e condivisione dello schermo, non a "rileva silenziosamente ogni trigger che digito, per sempre, in background" — che è esattamente ciò di cui ha bisogno un text expander.

evdev/uinput con accesso al gruppo input

L'opzione a livello più basso è leggere l'input grezzo direttamente da /dev/input (evdev) e iniettare eventi sintetici tramite /dev/uinput, bypassando del tutto il modello di input del compositor. Questo è genuinamente cross-compositor — non importa se sei su GNOME, KDE o Sway, perché opera al di sotto di tutti loro, a livello di input del kernel. Espanso usa esattamente questo approccio per il suo supporto Wayland, che la sua stessa documentazione descrive come "attualmente sperimentale": richiede una concessione una tantum di setcap cap_dac_override+p sul binario (o l'appartenenza al gruppo input, a seconda della configurazione) per leggere l'input grezzo senza eseguire come root, e presenta avvertenze note — i layout di tastiera non-US richiedono una configurazione esplicita, le sessioni GNOME possono mostrare sfarfallio nel backend degli appunti, e collegare una nuova tastiera richiede un riavvio manuale del servizio. Funziona, ma "sperimentale" è la parola giusta per descrivere dove si trova oggi.

Strumenti che semplicemente non supportano Wayland

Alcuni strumenti di automazione Linux sono costruiti direttamente su xdotool e sull'albero delle finestre X11, senza alcun percorso Wayland — AutoKey è l'esempio più chiaro: è solo-X11, e XWayland non aiuta perché la sua simulazione di input punta direttamente all'albero delle finestre X11, non al compositor. Se sei in una sessione Wayland pura, strumenti come questo semplicemente non funzionano, punto, indipendentemente dalla configurazione.

Come Lightning Assist lo gestisce

Lightning Assist adotta un approccio a due percorsi a seconda del tipo di sessione. Su X11 e sulle sessioni XWayland, usa gli hook di input X11 standard — lo stesso meccanismo che ha funzionato in modo affidabile su Linux per anni. Su una sessione Wayland pura, passa a un backend di input dedicato a basso livello: la prima volta che serve, l'app chiede una volta sola l'accesso all'input (un prompt "Grant access"), e dopo quella singola concessione, il rilevamento globale dei tasti e l'espansione del testo funzionano allo stesso modo su GNOME, KDE e altri compositor — nessuno YAML, nessun comando setcap da eseguire tu stesso, nessun passaggio di configurazione per layout di tastiera. Questo è un backend mantenuto, costruito apposta per lo scopo, non un ripiego aggiunto in seguito, e il modello di concessione una tantum significa che non ripeti un passaggio manuale a ogni sessione.

Una checklist pratica prima di scegliere uno strumento

Data quanta variazione esiste tra gli strumenti, vale la pena controllare alcune cose prima di impegnarti con uno su un desktop Wayland:

  • Documenta esplicitamente il supporto Wayland, o afferma solo genericamente "supporto Linux"? Le affermazioni generiche spesso significano "testato su X11" con il comportamento su Wayland non testato.
  • Ha bisogno di un setcap manuale o di un passaggio come root per funzionare su Wayland? Non è un ostacolo insormontabile, ma dovresti saperlo in anticipo piuttosto che scoprirlo dopo l'installazione.
  • Indica avvertenze specifiche per compositor (GNOME, KDE, Sway) invece di un generico "funziona su Wayland"? Gli strumenti onesti sulle stranezze specifiche del compositor (sfarfallio degli appunti, configurazione del layout di tastiera, riavvio su nuovo dispositivo) sono di solito quelli che sono stati effettivamente testati lì.
  • XWayland deve rimanere abilitato? Se uno strumento funziona solo tramite XWayland, conferma che il tuo ambiente desktop lo abbia attivo di default (la maggior parte lo fa) prima di dare per scontata la compatibilità.

Domande frequenti

Perché il mio text expander funziona su una macchina Linux ma non su un'altra?

La causa più comune è il tipo di sessione: le sessioni X11 e le sessioni Wayland gestiscono l'input globale in modo completamente diverso, e uno strumento costruito principalmente sugli hook di input X11 può funzionare perfettamente su una e non fare nulla sull'altra. Esegui echo $XDG_SESSION_TYPE in un terminale per verificare quale tipo di sessione stai usando al momento.

Wayland è semplicemente rotto per gli strumenti di produttività?

No — è un modello di sicurezza diverso, più restrittivo, non un bug. Le restrizioni che bloccano gli strumenti di input globale ingenui sono le stesse restrizioni che rendono più difficile per un'app malevola registrare i tuoi tasti premuti o iniettare input nella tua sessione bancaria. Gli strumenti che funzionano bene su Wayland sono quelli costruiti appositamente attorno al suo modello di permessi (portal, zwp_virtual_keyboard_v1, o un backend evdev/uinput dedicato con accesso al gruppo input) invece di quelli che presuppongono l'accesso senza restrizioni in stile X11.

Disabilitare XWayland blocca l'espansione del testo?

Può succedere, per qualsiasi strumento che si affida agli hook in stile X11 per raggiungere le applicazioni eseguite tramite XWayland. Se sei su una configurazione hardened con XWayland esplicitamente disabilitato, verifica in particolare se il tuo text expander ha un backend nativo Wayland (non solo un hook X11) — il backend di input Wayland dedicato di Lightning Assist e la modalità evdev/uinput sperimentale di Espanso sono entrambi costruiti esattamente per questo caso; uno strumento costruito puramente su xdotool o sull'accesso all'albero delle finestre X11, come AutoKey, non lo è.

Devo eseguire comandi da terminale per far funzionare il supporto Wayland?

Dipende dallo strumento. La modalità Wayland di Espanso richiede una concessione setcap una tantum (o un'appartenenza equivalente al gruppo input) che esegui tu stesso. Il backend Wayland di Lightning Assist invece richiede un permesso "Grant access" in-app una tantum la prima volta che serve — nessun comando da terminale richiesto.

Letture correlate

Fonti

Articoli correlati