guides

Expansiunea de text pe Wayland: de ce se blochează și ce funcționează cu adevărat

Trofin Sorin-IoanTrofin Sorin-IoanCTO, Lightning Assist26 iulie 20269 min lectură
waylandlinuxx11text-expandergnomekdexwaylandinput
Distribuie:
Expansiunea de text pe Wayland: de ce se blochează și ce funcționează cu adevărat

Răspuns rapid: un text expander trebuie să urmărească fiecare apăsare de tastă la nivel de sistem și să simuleze tastarea în orice aplicație are focalizarea. X11 permitea ambele lucruri implicit; compositoarele Wayland restricționează deliberat ambele, din motive de securitate — de aceea un text expander care funcționează perfect pe Ubuntu 20.04 se poate instala fără probleme și să nu facă absolut nimic într-o sesiune Wayland modernă, fără niciun mesaj de eroare. Nu există o singură soluție; opțiunile reale sunt XWayland (rulare „la modul vechi", într-un strat de compatibilitate), un backend evdev/uinput cu acces explicit la grupul input, sau un backend de input dedicat, de nivel jos, care cere o permisiune unică. Lightning Assist folosește ultima variantă.

Dacă ai instalat un text expander, ai tastat declanșatorul și nu s-a întâmplat nimic — fără eroare, fără crash, doar liniște — ești foarte probabil pe Wayland, iar asta este o categorie cunoscută de problemă, nu un bug specific instrumentului pe care l-ai ales.

De ce Wayland blochează ascultarea globală a tastelor

Pe X11, orice proces poate înregistra un hook de tastatură la nivel jos și poate citi fiecare apăsare de tastă din sistem, iar orice proces poate simula apăsări de taste în orice fereastră are focalizarea în acel moment — exact asta fac instrumente ca xdotool, și de aceea text expanderele, aplicațiile de hotkey-uri și software-ul de control la distanță au funcționat pe Linux de două decenii fără prea multă frecare. Din perspectiva securității, e totuși exact genul de lucru pe care nu vrei să-l ai implicit: orice aplicație, inclusiv una compromisă, poate înregistra tastele apăsate sau injecta input arbitrar în sesiunea ta de online banking.

Compositoarele Wayland (Mutter pentru GNOME, KWin pentru KDE Plasma, cele bazate pe wlroots pentru Sway și similare) au fost proiectate în jurul comportamentului opus: o aplicație vede doar evenimentele de input destinate propriei ferestre, și nimic nu poate injecta input sintetic în altă aplicație fără un mecanism explicit, deliberat, pentru asta. Nu e o scăpare sau o funcție lipsă — e modelul de securitate funcționând exact cum a fost gândit. Costul este că fiecare instrument care depindea de comportamentul „orice proces poate urmări și injecta" al X11 are nevoie de un mod diferit, de obicei mai limitat, de a face aceeași treabă.

Rezultatul practic: un text expander care interceptează tastele în stil X11 nu vede nimic într-o sesiune Wayland pură, iar un text expander care injectează text în stil X11 nu are nimic în care să injecteze. De obicei eșuează silențios, nu cu o eroare clară, pentru că nu se aruncă nicio excepție — evenimentele pe care le ascultă pur și simplu nu sosesc niciodată.

De ce extensiile de browser nu acoperă desktopul

O soluție naturală e un text expander bazat pe o extensie de browser, iar pentru tab-urile de browser, funcționează — extensiile operează în interiorul DOM-ului paginii, care nu are nicio legătură cu modelul de input al Wayland. Problema e domeniul de acoperire: o extensie vede doar browserul în care e instalată. Nu poate expanda un snippet în terminalul tău, în IDE-ul tău, într-o aplicație nativă GTK sau Qt, în clientul desktop al Slack sau Discord, sau într-un cititor de PDF. Dacă ziua ta implică orice în afara unui tab de browser — ceea ce pentru developeri și echipe de suport înseamnă cea mai mare parte a zilei — o extensie de browser rezolvă o fracțiune din problemă și lasă restul desktopului tău neacoperit.

Ce există cu adevărat pe Wayland azi

Nu există o soluție universală, dar există câteva abordări reale, documentate, fiecare cu compromisurile ei.

XWayland — rulare „la modul vechi", într-un strat de compatibilitate

Majoritatea mediilor desktop Wayland (GNOME, KDE Plasma implicit pe Ubuntu 22.04+, Fedora 38+ și similare) rulează XWayland alături de compositorul Wayland nativ — un strat de compatibilitate care permite aplicațiilor exclusiv-X11 să continue să funcționeze. Un instrument construit pe hook-uri de input X11 continuă să funcționeze pentru aplicațiile care rulează în interiorul XWayland. Problema e domeniul de acoperire: dacă ești într-o sesiune unde XWayland e dezactivat explicit (unele configurații GNOME securizate), sau aplicația specifică în care tastezi e un client Wayland nativ, nu unul XWayland, hooking-ul în stil X11 nu ajunge la ea.

Protocolul zwp_virtual_keyboard_v1

Unele compositoare Wayland — printre care Mutter de la GNOME și KWin de la KDE — implementează protocolul Wayland zwp_virtual_keyboard_v1, care oferă unei aplicații un mod aprobat oficial de a simula evenimente de tastatură. Asta e mai aproape de un răspuns nativ, la nivel de protocol, decât de o soluție ocolitoare, dar depinde de compositor: o aplicație care se bazează pe el funcționează doar acolo unde compositorul a ales să implementeze protocolul respectiv, iar comportamentul poate totuși varia — unele configurații recurg la un substitut bazat pe lipire din clipboard, care se poate comporta diferit în aplicații cu tratare specială a lipirii (un terminal cu mod bracketed-paste, de exemplu).

Interfața RemoteDesktop din xdg-desktop-portal

Specificația de portaluri freedesktop.org definește o interfață RemoteDesktop construită explicit pentru „a permite controlul de la distanță al unei sesiuni desktop" — poate injecta evenimente de tastatură și de pointer, dar doar după ce utilizatorul acordă acces KEYBOARD/POINTER la începutul sesiunii, și e un mecanism de sesiune cu permisiuni limitate, nu un hook de sistem mereu activ. E ușa aprobată oficial pe care Wayland o oferă pentru injectarea intrărilor, dar a fost proiectată în jurul instrumentelor de control la distanță și partajare a ecranului, nu în jurul ideii de „detectează silențios fiecare declanșator pe care îl tastez, mereu, în fundal" — exact de asta are nevoie un text expander.

evdev/uinput cu acces la grupul input

Opțiunea de nivel și mai jos e citirea directă a input-ului brut din /dev/input (evdev) și injectarea de evenimente sintetice prin /dev/uinput, ocolind complet modelul de input al compositorului. Asta e cu adevărat independentă de compositor — nu contează dacă ești pe GNOME, KDE sau Sway, pentru că operează sub nivelul tuturor, la nivelul de input al kernelului. Espanso folosește exact această abordare pentru suportul lui pe Wayland, pe care propria lui documentație îl descrie drept „momentan experimental": necesită acordarea unică a setcap cap_dac_override+p pe binar (sau apartenența la grupul input, în funcție de configurație) pentru a citi input brut fără să ruleze ca root, și vine cu avertismente cunoscute — layout-urile de tastatură non-US au nevoie de configurare explicită, sesiunile GNOME pot arăta pâlpâire în backend-ul de clipboard, iar conectarea unei tastaturi noi necesită repornirea manuală a serviciului. Funcționează, dar „experimental" e cuvântul potrivit pentru unde se află azi.

Instrumente care pur și simplu nu suportă Wayland

Unele instrumente de automatizare pentru Linux sunt construite direct pe xdotool și pe arborele de ferestre X11, fără nicio cale către Wayland — AutoKey e cel mai clar exemplu: e exclusiv-X11, iar XWayland nu ajută pentru că simularea lui de input țintește direct arborele de ferestre X11, nu compositorul. Dacă ești într-o sesiune Wayland pură, instrumente ca acesta pur și simplu nu funcționează, punct, indiferent de configurație.

Cum gestionează Lightning Assist această problemă

Lightning Assist adoptă o abordare cu două căi, în funcție de tipul sesiunii. Pe X11 și pe sesiunile XWayland, folosește hook-urile standard de input X11 — același mecanism care a funcționat fiabil pe Linux de ani de zile. Pe o sesiune Wayland pură, comută la un backend de input dedicat, de nivel jos: prima dată când e nevoie de el, aplicația cere o singură dată acces la input (un prompt „Grant access"), iar după acea acordare unică, detectarea globală a tastelor și expansiunea de text funcționează la fel pe GNOME, KDE și alte compositoare — fără YAML, fără vreo comandă setcap pe care să o rulezi tu însuți, fără niciun pas de configurare per layout de tastatură. Acesta e un backend întreținut, construit special pentru acest scop, nu o soluție de rezervă adăugată ulterior, iar modelul de acordare unică înseamnă că nu repeți un pas manual la fiecare sesiune.

O listă practică de verificat înainte să alegi un instrument

Având în vedere cât de multă variație există între instrumente, merită verificate câteva lucruri înainte să te angajezi la unul pe un desktop Wayland:

  • Documentează explicit suportul pentru Wayland, sau doar afirmă vag „suport Linux"? Afirmațiile vagi înseamnă adesea „testat pe X11", cu comportamentul pe Wayland netestat.
  • Are nevoie de un setcap manual sau de un pas ca root ca să funcționeze pe Wayland? Nu e un blocaj în sine, dar ar trebui să știi asta din start, nu să o descoperi după instalare.
  • Numește avertismente specifice pentru fiecare compositor (GNOME, KDE, Sway) în loc de un generic „funcționează pe Wayland"? Instrumentele oneste despre ciudățeniile specifice fiecărui compositor (pâlpâire de clipboard, configurare de layout de tastatură, repornire la dispozitiv nou) sunt de obicei cele care chiar au fost testate acolo.
  • Trebuie ca XWayland să rămână activat? Dacă un instrument funcționează doar prin XWayland, confirmă că mediul tău desktop îl are activ implicit (majoritatea îl au) înainte să presupui compatibilitatea.

Întrebări frecvente

De ce text expanderul meu funcționează pe un calculator Linux, dar nu pe altul?

Cea mai frecventă cauză e tipul sesiunii: sesiunile X11 și sesiunile Wayland gestionează input-ul global complet diferit, iar un instrument construit în principal pe hook-uri de input X11 poate funcționa impecabil pe unul și să nu facă nimic pe celălalt. Rulează echo $XDG_SESSION_TYPE într-un terminal ca să vezi ce tip de sesiune rulezi în acel moment.

Wayland e pur și simplu stricat pentru instrumentele de productivitate?

Nu — e un model de securitate diferit, mai restrictiv, nu un bug. Restricțiile care blochează instrumentele naive de input global sunt aceleași restricții care fac mai greu pentru o aplicație malițioasă să-ți înregistreze tastele apăsate sau să injecteze input în sesiunea ta de online banking. Instrumentele care funcționează bine pe Wayland sunt cele construite special în jurul modelului lui de permisiuni (portaluri, zwp_virtual_keyboard_v1, sau un backend evdev/uinput dedicat cu acces la grupul input), nu cele care presupun acces nerestricționat în stil X11.

Dezactivarea XWayland strică expansiunea de text?

Poate, pentru orice instrument care se bazează pe hook-uri în stil X11 ca să ajungă la aplicațiile rulate prin XWayland. Dacă ești pe o configurație securizată cu XWayland dezactivat explicit, verifică în mod specific dacă text expanderul tău are un backend nativ pentru Wayland (nu doar un hook X11) — backend-ul dedicat pentru Wayland al Lightning Assist și modul experimental evdev/uinput al Espanso sunt ambele construite exact pentru acest caz; un instrument construit pur pe xdotool sau pe accesul la arborele de ferestre X11, precum AutoKey, nu este.

Trebuie să rulez comenzi de terminal ca să fac suportul Wayland să funcționeze?

Depinde de instrument. Modul Wayland al Espanso are nevoie de o acordare setcap unică (sau apartenență echivalentă la grupul input) pe care o rulezi tu însuți. Backend-ul Wayland al Lightning Assist, în schimb, cere o permisiune „Grant access" în aplicație, o singură dată, prima dată când e nevoie — fără nicio comandă de terminal necesară.

Articole similare

Surse

Articole similare