guides

Расширение текста на Wayland: почему оно ломается и что реально работает

Trofin Sorin-IoanTrofin Sorin-IoanCTO, Lightning Assist26 июля 2026 г.9 мин чтения
waylandlinuxx11text-expandergnomekdexwaylandinput
Поделиться:
Расширение текста на Wayland: почему оно ломается и что реально работает

Короткий ответ: текстовым экспандерам нужно отслеживать каждое нажатие клавиши в системе и симулировать набор текста в приложении, у которого сейчас фокус. X11 разрешал и то, и другое по умолчанию; композиторы Wayland намеренно ограничивают оба этих действия из соображений безопасности — поэтому текстовый экспандер, идеально работающий на Ubuntu 20.04, может установиться без единой ошибки и не делать вообще ничего в современной сессии Wayland, причём без какого-либо сообщения об ошибке. Единого решения не существует; реальные варианты — это XWayland (работа «по-старому», внутри слоя совместимости), бэкенд evdev/uinput с явным доступом к группе input, либо выделенный низкоуровневый бэкенд ввода, который запрашивает разовое разрешение. Lightning Assist использует последний вариант.

Если вы установили текстовый экспандер, набрали свой триггер — и ничего не произошло: ни ошибки, ни падения, просто тишина, — вы почти наверняка на Wayland, и это известная категория проблемы, а не баг конкретно того инструмента, который вы выбрали.

Почему Wayland блокирует глобальное прослушивание клавиш

На X11 любой процесс может зарегистрировать низкоуровневый хук клавиатуры и читать каждое нажатие клавиши в системе, и любой процесс может симулировать нажатия клавиш в том окне, у которого сейчас фокус, — именно это в буквальном смысле делают такие инструменты, как xdotool, и именно поэтому текстовые экспандеры, менеджеры горячих клавиш и программы удалённого управления два десятилетия работали на Linux почти без трения. С точки зрения безопасности это ровно то, чего вы не хотите иметь по умолчанию: любое приложение, включая скомпрометированное, может логировать нажатия ваших клавиш или внедрять произвольный ввод в вашу банковскую сессию.

Композиторы Wayland (Mutter для GNOME, KWin для KDE Plasma, композиторы на базе wlroots для Sway и подобных) спроектированы вокруг противоположного поведения по умолчанию: приложение видит только события ввода, предназначенные для его собственного окна, и ничто не может внедрить синтетический ввод в другое приложение без явного, намеренного механизма для этого. Это не недосмотр и не отсутствующая функция — это модель безопасности, работающая именно так, как задумано. Цена в том, что каждому инструменту, который полагался на поведение X11 «любой процесс может наблюдать и внедрять», теперь нужен другой, обычно более ограниченный способ делать ту же работу.

Практический результат: текстовый экспандер, перехватывающий клавиши по-X11, ничего не видит в чистой сессии Wayland, а текстовый экспандер, внедряющий текст по-X11, не имеет во что его внедрять. Обычно это происходит молча, без внятной ошибки, потому что никакое исключение не выбрасывается — события, которые он слушает, просто никогда не приходят.

Почему расширения браузера не покрывают весь рабочий стол

Естественный обходной путь — текстовый экспандер на основе расширения браузера, и для вкладок браузера это работает: расширения действуют внутри DOM страницы, что вообще не связано с моделью ввода Wayland. Проблема в охвате: расширение видит только тот браузер, в который оно установлено. Оно не может расширить сниппет в вашем терминале, в вашей IDE, в нативном приложении GTK или Qt, в десктопном клиенте Slack или Discord, или в PDF-читалке. Если ваш день включает что-то за пределами вкладки браузера — а для разработчиков и служб поддержки это большая часть дня, — расширение браузера решает лишь часть проблемы и оставляет остальной рабочий стол без покрытия.

Что реально существует на Wayland сегодня

Универсального решения нет, но есть несколько реальных, задокументированных подходов, у каждого свои компромиссы.

XWayland — работа «по-старому», внутри слоя совместимости

Большинство окружений рабочего стола на Wayland (GNOME, KDE Plasma из коробки на Ubuntu 22.04+, Fedora 38+ и подобные) запускают XWayland параллельно с нативным композитором Wayland — слой совместимости, который позволяет приложениям, работающим только с X11, продолжать функционировать. Инструмент, построенный на хуках ввода X11, продолжает работать для приложений, запущенных внутри XWayland. Загвоздка — в охвате: если вы в сессии, где XWayland явно отключён (некоторые усиленные конфигурации GNOME), либо конкретное приложение, в которое вы печатаете, — нативный клиент Wayland, а не клиент XWayland, перехват в стиле X11 до него не дотягивается.

Протокол zwp_virtual_keyboard_v1

Некоторые композиторы Wayland — в их числе Mutter от GNOME и KWin от KDE — реализуют протокол Wayland zwp_virtual_keyboard_v1, который даёт приложению санкционированный способ симулировать события клавиатуры. Это ближе к встроенному, протокольному решению, чем к обходному пути, но оно зависит от композитора: приложение, полагающееся на него, работает только там, где композитор решил реализовать этот протокол, и поведение всё равно может различаться — в некоторых конфигурациях происходит откат к замене через вставку из буфера обмена, которая может вести себя иначе в приложениях со специальной обработкой вставки (например, в терминале с режимом bracketed-paste).

Интерфейс RemoteDesktop в xdg-desktop-portal

Спецификация порталов freedesktop.org определяет интерфейс RemoteDesktop, созданный явно, чтобы «разрешить удалённое управление сессией рабочего стола» — он может внедрять события клавиатуры и указателя, но только после того, как пользователь предоставит доступ KEYBOARD/POINTER при старте сессии, и это механизм сессии с ограниченными правами, а не постоянно включённый системный хук. Это санкционированная дверь, которую Wayland предоставляет для внедрения ввода, но она была спроектирована вокруг инструментов удалённого управления и демонстрации экрана, а не вокруг задачи «молча распознавай каждый мой триггер, всегда, в фоне» — а именно это и нужно текстовому экспандеру.

evdev/uinput с доступом к группе input

Более низкоуровневый вариант — читать сырой ввод напрямую из /dev/input (evdev) и внедрять синтетические события через /dev/uinput, полностью обходя модель ввода композитора. Это по-настоящему универсально для любого композитора — неважно, GNOME у вас, KDE или Sway, потому что это работает ниже них всех, на уровне ввода ядра. Именно этот подход Espanso использует для поддержки Wayland, и собственная документация проекта описывает её как «на данный момент экспериментальную»: требуется разовое предоставление setcap cap_dac_override+p для бинарника (или членство в группе input, в зависимости от настройки), чтобы читать сырой ввод без запуска от root, и есть известные оговорки — раскладки клавиатуры не-US нуждаются в явной настройке, в сессиях GNOME может мерцать бэкенд буфера обмена, а подключение новой клавиатуры требует ручного перезапуска сервиса. Это работает, но слово «экспериментальный» точно описывает нынешнее состояние.

Инструменты, которые попросту не поддерживают Wayland

Некоторые инструменты автоматизации для Linux построены напрямую на xdotool и дереве окон X11, вообще без пути на Wayland — AutoKey самый явный пример: он работает только с X11, и XWayland тут не помогает, потому что его симуляция ввода нацелена прямо на дерево окон X11, а не на композитор. Если вы в чистой сессии Wayland, такие инструменты просто не работают, и точка, независимо от настроек.

Как это решает Lightning Assist

Lightning Assist использует подход с двумя путями в зависимости от типа сессии. На X11 и в сессиях XWayland он использует стандартные хуки ввода X11 — тот же механизм, который годами надёжно работал на Linux. В чистой сессии Wayland он переключается на выделенный низкоуровневый бэкенд ввода: при первой необходимости приложение один раз запрашивает доступ к вводу (запрос «Grant access»), и после этого единственного разрешения глобальное распознавание клавиш и расширение текста работают одинаково на GNOME, KDE и других композиторах — никакого YAML, никакой команды setcap, которую нужно выполнять самому, никакого шага настройки под каждую раскладку клавиатуры. Это поддерживаемый бэкенд, созданный именно для этой цели, а не костыль, добавленный потом, а модель разового разрешения означает, что вам не нужно повторять ручной шаг в каждой сессии.

Практический чек-лист перед выбором инструмента

Учитывая, насколько сильно инструменты отличаются друг от друга, стоит проверить несколько вещей, прежде чем остановиться на одном из них на рабочем столе Wayland:

  • Явно документирует ли инструмент поддержку Wayland, или просто заявляет о «поддержке Linux» в целом? Общие заявления часто означают «протестировано на X11», а поведение на Wayland не проверялось.
  • Нужен ли ручной setcap или шаг с правами root, чтобы это заработало на Wayland? Не обязательно повод отказаться, но лучше знать об этом заранее, а не обнаружить после установки.
  • Называет ли инструмент конкретные особенности композиторов (GNOME, KDE, Sway), а не общее «работает на Wayland»? Инструменты, честно рассказывающие о специфичных для композитора нюансах (мерцание буфера обмена, настройка раскладки клавиатуры, перезапуск при новом устройстве), обычно и есть те, что реально там тестировались.
  • Должен ли оставаться включённым XWayland? Если инструмент работает только через XWayland, убедитесь, что в вашем окружении рабочего стола он включён по умолчанию (в большинстве так и есть), прежде чем полагаться на совместимость.

Часто задаваемые вопросы

Почему мой текстовый экспандер работает на одном компьютере с Linux, но не на другом?

Самая частая причина — тип сессии: сессии X11 и сессии Wayland совершенно по-разному обрабатывают глобальный ввод, и инструмент, построенный в основном на хуках ввода X11, может безупречно работать на одной и не делать ничего на другой. Выполните echo $XDG_SESSION_TYPE в терминале, чтобы узнать, какой тип сессии у вас сейчас запущен.

Wayland просто сломан для инструментов продуктивности?

Нет — это другая, более строгая модель безопасности, а не баг. Ограничения, блокирующие наивные инструменты глобального ввода, — это те же ограничения, которые затрудняют вредоносному приложению логирование ваших нажатий клавиш или внедрение ввода в вашу банковскую сессию. Инструменты, хорошо работающие на Wayland, — это те, что построены именно вокруг его модели разрешений (порталы, zwp_virtual_keyboard_v1 или выделенный бэкенд evdev/uinput с доступом к группе input), а не те, что предполагают неограниченный доступ в стиле X11.

Ломает ли отключение XWayland расширение текста?

Может — для любого инструмента, полагающегося на хуки в стиле X11, чтобы достучаться до приложений, запущенных через XWayland. Если у вас усиленная конфигурация с явно отключённым XWayland, проверьте именно то, есть ли у вашего текстового экспандера нативный бэкенд для Wayland (а не только хук X11) — выделенный бэкенд ввода Lightning Assist для Wayland и экспериментальный режим evdev/uinput у Espanso созданы именно для этого случая; инструмент, построенный исключительно на xdotool или доступе к дереву окон X11, как AutoKey, — нет.

Нужно ли выполнять какие-то команды в терминале, чтобы включить поддержку Wayland?

Зависит от инструмента. Режиму Wayland у Espanso нужно разовое предоставление setcap (или эквивалентное членство в группе input), которое вы выполняете сами. Бэкенд Wayland у Lightning Assist вместо этого один раз запрашивает разрешение «Grant access» прямо в приложении при первой необходимости — никакая команда в терминале не требуется.

Похожие материалы

Источники

Похожие статьи