Wayland पर Text Expansion: यह क्यों टूटता है और असल में क्या काम करता है

संक्षिप्त उत्तर: Text expanders को हर keystroke को पूरे सिस्टम में देखना होता है और जिस भी ऐप पर focus हो, उसमें टाइपिंग simulate करनी होती है। X11 डिफ़ॉल्ट रूप से दोनों की इजाज़त देता था; Wayland के compositors सुरक्षा कारणों से जान-बूझकर दोनों को सीमित करते हैं, और यही वजह है कि जो text expander Ubuntu 20.04 पर बिल्कुल सही काम करता है, वह किसी आधुनिक Wayland session पर बिना किसी error message के साफ़-सुथरा install तो हो जाता है, लेकिन बिल्कुल कुछ नहीं करता। इसका कोई एक ही समाधान नहीं है; असली विकल्प हैं XWayland (पुराने तरीके से, एक compatibility layer के अंदर चलाना), explicit input-group access वाला एक evdev/uinput backend, या एक बार की permission माँगने वाला dedicated low-level input backend। Lightning Assist इनमें से आख़िरी तरीका इस्तेमाल करता है।

अगर आपने कोई text expander install किया, अपना trigger टाइप किया, और कुछ भी नहीं हुआ — न error, न crash, बस खामोशी — तो बहुत मुमकिन है कि आप Wayland पर हैं, और यह एक जानी-पहचानी समस्या की श्रेणी है, न कि आपके चुने हुए किसी खास tool का bug।

Wayland Global Key Listening को क्यों Block करता है

X11 पर, कोई भी process एक low-level keyboard hook register कर सकता है और सिस्टम पर हर keystroke पढ़ सकता है, और कोई भी process जिस भी window पर फ़िलहाल focus हो, उसमें keypress simulate कर सकता है — xdotool जैसे tools ठीक यही करते हैं, और यही वजह है कि text expanders, hotkey managers, और remote-control software दो दशकों से Linux पर बिना ज़्यादा घर्षण के काम करते आए हैं। यह, सुरक्षा के नज़रिए से, ठीक वही चीज़ भी है जो आप डिफ़ॉल्ट रूप से नहीं चाहेंगे: कोई भी application, यहाँ तक कि कोई compromised app भी, आपके keystrokes log कर सकता है या आपके banking session में मनमाना input inject कर सकता है।

Wayland के compositors (GNOME के लिए Mutter, KDE Plasma के लिए KWin, Sway जैसों के लिए wlroots-आधारित compositors) बिल्कुल उलटे डिफ़ॉल्ट के इर्द-गिर्द डिज़ाइन किए गए हैं: कोई application सिर्फ़ अपनी ही window के लिए भेजे गए input events देख सकता है, और किसी explicit, जान-बूझकर बनाए गए तंत्र के बिना कोई भी दूसरे application में synthetic input inject नहीं कर सकता। यह कोई चूक या छूटी हुई सुविधा नहीं है — यह सुरक्षा मॉडल का ठीक वैसे ही काम करना है जैसा इरादा था। इसकी कीमत यह है कि हर वह tool जो X11 के "कोई भी process देख और inject कर सकता है" वाले व्यवहार पर निर्भर था, उसे वही काम करने के लिए एक अलग, और आमतौर पर ज़्यादा सीमित, तरीका चाहिए।

व्यावहारिक नतीजा यह है: जो text expander X11 के तरीके से keystrokes hook करता है, उसे pure Wayland session पर कुछ भी नज़र नहीं आता, और जो text expander X11 के तरीके से text inject करता है, उसके पास inject करने के लिए कुछ होता ही नहीं। यह आमतौर पर किसी साफ़ error के बजाय चुपचाप fail होता है, क्योंकि कोई exception throw नहीं होता — जिन events को यह सुन रहा होता है, वे बस कभी पहुँचते ही नहीं।

Browser Extensions Desktop को पूरी तरह Cover क्यों नहीं करते

एक स्वाभाविक workaround है browser-extension-आधारित text expander, और सिर्फ़ browser tabs के लिए यह काम करता है — extensions पेज के DOM के अंदर काम करते हैं, जिसका Wayland के input मॉडल से कोई लेना-देना नहीं। समस्या है scope की: कोई extension सिर्फ़ उसी browser को देख पाता है जिसमें वह install है। यह आपके terminal, आपके IDE, किसी native GTK या Qt application, Slack या Discord के desktop client, या किसी PDF reader में कोई snippet expand नहीं कर सकता। अगर आपके दिन में browser tab के बाहर भी कुछ काम शामिल है — जो developers और support teams के लिए दिन का ज़्यादातर हिस्सा होता है — तो browser extension समस्या के एक छोटे हिस्से का ही हल करता है और आपके desktop का बाक़ी हिस्सा बिना किसी cover के छोड़ देता है।

आज Wayland पर असल में क्या मौजूद है

कोई universal समाधान नहीं है, लेकिन कुछ असली, दस्तावेज़ीकृत approaches मौजूद हैं, जिनमें से हर एक के अपने trade-offs हैं।

XWayland — एक compatibility layer के अंदर पुराने तरीके से चलाना

ज़्यादातर Wayland desktop environments (GNOME, Ubuntu 22.04+ और Fedora 38+ जैसों पर out of the box मिलने वाला KDE Plasma, और इसी तरह के अन्य) native Wayland compositor के साथ-साथ XWayland भी चलाते हैं — एक compatibility layer जो X11-only applications को चलते रहने देती है। X11 input hooks पर बना कोई tool XWayland के अंदर चल रहे applications के लिए काम करता रहता है। पेच scope में है: अगर आप किसी ऐसे session में हैं जहाँ XWayland जान-बूझकर disable किया गया है (कुछ hardened GNOME configurations में), या जिस specific application में आप टाइप कर रहे हैं वह XWayland के बजाय एक native Wayland client है, तो X11-style hooking वहाँ तक नहीं पहुँचती।

zwp_virtual_keyboard_v1 Protocol

कुछ Wayland compositors — जिनमें GNOME का Mutter और KDE का KWin शामिल हैं — zwp_virtual_keyboard_v1 नाम का Wayland protocol implement करते हैं, जो किसी application को keyboard events simulate करने का एक स्वीकृत तरीका देता है। यह किसी workaround के बजाय एक built-in, protocol-level समाधान के ज़्यादा क़रीब है, लेकिन यह compositor पर निर्भर है: जो app इस पर निर्भर करता है वह सिर्फ़ वहीं काम करता है जहाँ compositor ने उस protocol को implement करने का फ़ैसला किया हो, और व्यवहार अब भी अलग-अलग हो सकता है — कुछ setups clipboard-paste विकल्प पर fall back करते हैं, जो special paste handling वाले apps (जैसे bracketed-paste mode वाला कोई terminal) में अलग तरह से व्यवहार कर सकता है।

xdg-desktop-portal का RemoteDesktop Interface

freedesktop.org का portal specification एक RemoteDesktop interface परिभाषित करता है जो साफ़ तौर पर "किसी desktop session को remote control करने की इजाज़त देने" के लिए बनाया गया है — यह keyboard और pointer events inject कर सकता है, लेकिन सिर्फ़ तब जब session शुरू होते समय user KEYBOARD/POINTER access दे। और यह एक हमेशा-चालू रहने वाला system hook नहीं बल्कि permission-scoped session तंत्र है। यह वह स्वीकृत दरवाज़ा है जो Wayland input injection के लिए देता है, लेकिन इसे remote-control और screen-sharing tools को ध्यान में रखकर डिज़ाइन किया गया था, न कि उस चीज़ के लिए जो एक text expander को असल में चाहिए होती है: "बैकग्राउंड में, हमेशा के लिए, चुपचाप हर वह trigger पहचानना जो मैं टाइप करता हूँ।"

input-group Access के साथ evdev/uinput

ज़्यादा low-level विकल्प है /dev/input (evdev) से सीधे raw input पढ़ना और /dev/uinput के ज़रिए synthetic events inject करना, यानी compositor के input मॉडल को पूरी तरह bypass करना। यह सच में cross-compositor है — इसे कोई फ़र्क़ नहीं पड़ता कि आप GNOME पर हैं, KDE पर, या Sway पर, क्योंकि यह इन सबसे नीचे, kernel input layer पर काम करता है। Espanso अपने Wayland support के लिए बिल्कुल यही approach इस्तेमाल करता है, जिसे उसका अपना documentation "फ़िलहाल experimental" बताता है: root के रूप में चलाए बिना raw input पढ़ने के लिए इसे binary पर एक बार का setcap cap_dac_override+p grant चाहिए (या setup के हिसाब से input group की membership), और इसके साथ कुछ जाने-पहचाने caveats भी आते हैं — non-US keyboard layouts को explicit configuration चाहिए, GNOME sessions में clipboard-backend flicker दिख सकता है, और कोई नया keyboard जोड़ने पर service को मैनुअली restart करना पड़ता है। यह काम करता है, लेकिन आज की स्थिति के लिए "experimental" ही सही शब्द है।

वे Tools जो Wayland को बिल्कुल Support नहीं करते

कुछ Linux automation tools सीधे xdotool और X11 window tree पर बने हैं, जिनके पास Wayland के लिए कोई रास्ता ही नहीं है — AutoKey इसका सबसे साफ़ उदाहरण है: यह X11-only है, और XWayland भी मदद नहीं करता क्योंकि इसका input simulation सीधे X11 window tree को target करता है, न कि compositor को। अगर आप किसी pure Wayland session पर हैं, तो ऐसे tools चाहे जो भी configuration हो, बस काम नहीं करते।

Lightning Assist इसे कैसे Handle करता है

Lightning Assist session के प्रकार के आधार पर दो अलग रास्ते अपनाता है। X11 और XWayland sessions पर, यह standard X11 input hooks इस्तेमाल करता है — वही तंत्र जो सालों से Linux पर भरोसेमंद तरीके से काम करता आया है। किसी pure Wayland session पर, यह एक dedicated low-level input backend पर switch हो जाता है: जब पहली बार इसकी ज़रूरत पड़ती है, ऐप एक बार input access माँगता है (एक "Grant access" prompt), और उस एक बार की अनुमति के बाद, global key detection और text expansion GNOME, KDE, और दूसरे compositors पर एक जैसे तरीके से काम करते हैं — न कोई YAML, न ख़ुद चलाने के लिए कोई setcap command, न per-keyboard-layout configuration का कोई step। यह कोई बाद में जोड़ा गया fallback नहीं बल्कि इसी मक़सद के लिए maintain किया गया backend है, और एक बार की grant मॉडल का मतलब है कि आपको हर session में कोई मैनुअल step दोहराना नहीं पड़ता।

कोई Tool चुनने से पहले एक व्यावहारिक Checklist

tools के बीच इतनी variation होने को देखते हुए, किसी Wayland desktop पर किसी एक tool को अपनाने से पहले कुछ चीज़ें जाँच लेना समझदारी है:

• क्या यह Wayland support को साफ़ तौर पर document करता है, या सिर्फ़ व्यापक रूप से "Linux support" का दावा करता है? व्यापक दावों का अक्सर मतलब होता है "X11 पर test किया गया" जबकि Wayland पर व्यवहार untested है।
• क्या इसे Wayland पर काम करने के लिए मैनुअल setcap या root वाला step चाहिए? यह कोई dealbreaker नहीं है, लेकिन installation के बाद पता चलने के बजाय आपको यह पहले से पता होना चाहिए।
• क्या यह एक सामान्य "Wayland पर काम करता है" कहने के बजाय specific compositor caveats (GNOME, KDE, Sway) बताता है? जो tools compositor-specific quirks (clipboard flicker, keyboard-layout config, नए device पर restart) के बारे में ईमानदार होते हैं, वे आमतौर पर वही होते हैं जिन्हें वहाँ असल में test किया गया है।
• क्या XWayland को enabled रखना ज़रूरी है? अगर कोई tool सिर्फ़ XWayland के ज़रिए काम करता है, तो compatibility मान लेने से पहले पुष्टि कर लें कि आपके desktop environment में यह डिफ़ॉल्ट रूप से on है (ज़्यादातर में होता है)।

अक्सर पूछे जाने वाले सवाल

मेरा text expander एक Linux मशीन पर काम क्यों करता है लेकिन दूसरी पर नहीं?

सबसे आम वजह है session का प्रकार: X11 sessions और Wayland sessions global input को बिल्कुल अलग तरीके से handle करते हैं, और मुख्य रूप से X11 input hooks पर बना कोई tool एक पर बेदाग़ काम कर सकता है और दूसरे पर कुछ भी नहीं करता। किसी terminal में echo $XDG_SESSION_TYPE चलाकर देखें कि आप फ़िलहाल किस session type पर हैं।

क्या Wayland productivity tools के लिए बस टूटा हुआ है?

नहीं — यह एक अलग, ज़्यादा restrictive security model है, कोई bug नहीं। जो restrictions naive global-input tools को block करती हैं, वही restrictions किसी malicious app के लिए आपके keystrokes log करना या आपके banking session में input inject करना मुश्किल बनाती हैं। जो tools Wayland पर अच्छी तरह काम करते हैं, वे वे हैं जो X11-style unrestricted access मान लेने के बजाय, ख़ास तौर पर उसके permission मॉडल (portals, zwp_virtual_keyboard_v1, या input-group access वाला एक dedicated evdev/uinput backend) के इर्द-गिर्द बनाए गए हैं।

क्या XWayland disable करने से text expansion टूट जाता है?

हो सकता है, उन tools के लिए जो XWayland-run applications तक पहुँचने के लिए X11-style hooks पर निर्भर हैं। अगर आप किसी hardened setup पर हैं जहाँ XWayland साफ़ तौर पर disabled है, तो ख़ास तौर पर जाँचें कि आपके text expander के पास एक native-Wayland backend है या नहीं (सिर्फ़ X11 hook नहीं) — Lightning Assist का dedicated Wayland input backend और Espanso का experimental evdev/uinput mode, दोनों बिल्कुल इसी स्थिति के लिए बनाए गए हैं; जबकि AutoKey जैसा कोई tool जो सिर्फ़ xdotool या X11 window-tree access पर बना है, ऐसा नहीं है।

क्या Wayland support को काम में लाने के लिए मुझे कोई terminal commands चलाने पड़ेंगे?

यह tool पर निर्भर करता है। Espanso के Wayland mode को एक बार का setcap grant चाहिए (या equivalent input-group membership) जिसे आपको ख़ुद चलाना पड़ता है। इसके बजाय Lightning Assist का Wayland backend पहली बार ज़रूरत पड़ने पर सिर्फ़ ऐप के अंदर एक बार की "Grant access" permission माँगता है — किसी terminal command की ज़रूरत नहीं।

संबंधित लेख

• Linux के लिए Text Expander — ख़ास तौर पर text expansion के लिए पूरा X11/XWayland/Wayland विश्लेषण
• Linux के लिए Speech-to-Text और Voice Dictation — वही input-injection सीमाएँ, voice typing पर लागू
• Linux पर Voice Dictation: 2026 में क्या काम करता है — Linux के voice-input परिदृश्य का व्यापक दौरा, उन्हीं Wayland protocol details समेत

स्रोत

• Espanso — Linux installation documentation — per-distribution install matrix and Wayland limitations
• Espanso — Get Started documentation — configuration model
• Wayland zwp_virtual_keyboard_v1 protocol specification
• freedesktop.org xdg-desktop-portal — RemoteDesktop interface
• Lightning Assist — Linux के लिए Text Expander