guides

Expansión de texto en Wayland: por qué falla y qué funciona de verdad

Trofin Sorin-IoanTrofin Sorin-IoanCTO, Lightning Assist26 de julio de 20269 min de lectura
waylandlinuxx11text-expandergnomekdexwaylandinput
Compartir:
Expansión de texto en Wayland: por qué falla y qué funciona de verdad

Respuesta rápida: los expansores de texto necesitan vigilar cada pulsación de tecla en todo el sistema y simular la escritura en la app que tenga el foco. X11 permitía ambas cosas por defecto; los compositors de Wayland restringen ambas deliberadamente por razones de seguridad, por lo que un expansor de texto que funciona perfectamente en Ubuntu 20.04 puede instalarse sin problemas y no hacer absolutamente nada en una sesión Wayland moderna, sin ningún mensaje de error. No hay una solución única; las opciones reales son XWayland (funcionar a la manera antigua, dentro de una capa de compatibilidad), un backend evdev/uinput con acceso explícito al grupo de entrada, o un backend de entrada de bajo nivel dedicado que pide un permiso puntual. Lightning Assist usa esta última opción.

Si has instalado un expansor de texto, escrito tu disparador, y visto que no pasaba nada —sin error, sin cuelgue, solo silencio—, es muy probable que estés en Wayland, y esta es una categoría de problema conocida, no un fallo específico de la herramienta que elegiste.

Por qué Wayland bloquea la escucha global de teclas

En X11, cualquier proceso puede registrar un hook de teclado de bajo nivel y leer cada pulsación de tecla del sistema, y cualquier proceso puede simular pulsaciones en la ventana que tenga el foco en ese momento; eso es literalmente lo que hacen herramientas como xdotool, y por eso los expansores de texto, los gestores de atajos y el software de control remoto han funcionado en Linux durante dos décadas sin demasiada fricción. También es, desde el punto de vista de la seguridad, exactamente el tipo de cosa que no quieres por defecto: cualquier aplicación, incluida una comprometida, puede registrar tus pulsaciones de teclado o inyectar entradas arbitrarias en tu sesión bancaria.

Los compositors de Wayland (Mutter para GNOME, KWin para KDE Plasma, los basados en wlroots para Sway y similares) se diseñaron con el valor por defecto opuesto: una aplicación solo ve los eventos de entrada destinados a su propia ventana, y nada puede inyectar entradas sintéticas en otra aplicación sin un mecanismo explícito y deliberado para hacerlo. Esto no es un descuido ni una función ausente: es el modelo de seguridad funcionando como se pretendía. El coste es que cada herramienta que dependía del comportamiento de X11 de "cualquier proceso puede vigilar e inyectar" necesita una forma distinta, y normalmente más limitada, de hacer el mismo trabajo.

El resultado práctico: un expansor de texto que engancha las pulsaciones a la manera de X11 no ve nada en una sesión Wayland pura, y un expansor de texto que inyecta texto a la manera de X11 no tiene nada en qué inyectar. Normalmente falla en silencio en lugar de con un error claro, porque no se lanza ninguna excepción: los eventos que está escuchando simplemente nunca llegan.

Por qué las extensiones de navegador no cubren el escritorio

Una solución alternativa natural es un expansor de texto basado en una extensión de navegador, y solo para las pestañas del navegador, funciona: las extensiones operan dentro del DOM de la página, algo que no tiene nada que ver con el modelo de entrada de Wayland. El problema es el alcance: una extensión solo ve nunca el navegador en el que está instalada. No puede expandir un snippet en tu terminal, tu IDE, una aplicación nativa de GTK o Qt, el cliente de escritorio de Slack o Discord, o un lector de PDF. Si tu día incluye algo fuera de una pestaña de navegador —que para desarrolladores y equipos de soporte es la mayor parte del día—, una extensión de navegador resuelve una fracción del problema y deja el resto de tu escritorio sin cubrir.

Qué existe realmente en Wayland hoy

No hay una solución universal, pero sí un puñado de enfoques reales y documentados, cada uno con sus contrapartidas.

XWayland: funcionar a la manera antigua, dentro de una capa de compatibilidad

La mayoría de los entornos de escritorio Wayland (GNOME, KDE Plasma de fábrica en Ubuntu 22.04+, Fedora 38+ y similares) ejecutan XWayland junto al compositor Wayland nativo: una capa de compatibilidad que permite que las aplicaciones exclusivas de X11 sigan funcionando. Una herramienta construida sobre hooks de entrada de X11 sigue funcionando para las aplicaciones que corren dentro de XWayland. La trampa está en el alcance: si estás en una sesión donde XWayland está explícitamente desactivado (algunas configuraciones de GNOME reforzadas), o la aplicación concreta en la que estás escribiendo es un cliente Wayland nativo en vez de uno de XWayland, el enganche al estilo X11 no llega hasta ella.

El protocolo zwp_virtual_keyboard_v1

Algunos compositors de Wayland —entre ellos Mutter de GNOME y KWin de KDE— implementan el protocolo Wayland zwp_virtual_keyboard_v1, que le da a una aplicación una forma sancionada de simular eventos de teclado. Esto se acerca más a una respuesta integrada a nivel de protocolo que a una solución alternativa, pero depende del compositor: una app que se apoya en él funciona solo donde el compositor ha decidido implementar ese protocolo, y el comportamiento puede seguir variando; algunas configuraciones recurren a un sustituto basado en pegar desde el portapapeles, que puede comportarse de forma distinta en apps con un manejo especial del pegado (una terminal con modo de pegado entre corchetes, por ejemplo).

La interfaz RemoteDesktop de xdg-desktop-portal

La especificación de portals de freedesktop.org define una interfaz RemoteDesktop construida explícitamente para "permitir el control remoto de una sesión de escritorio": puede inyectar eventos de teclado y de puntero, pero solo después de que el usuario conceda acceso KEYBOARD/POINTER al iniciar la sesión, y es un mecanismo de sesión limitado por permisos, no un hook de sistema siempre activo. Es la puerta sancionada que Wayland ofrece para la inyección de entradas, pero se diseñó pensando en herramientas de control remoto y compartición de pantalla, no en "detectar en silencio cada disparador que escribo, para siempre, en segundo plano", que es justo lo que necesita un expansor de texto.

evdev/uinput con acceso al grupo de entrada

La opción de más bajo nivel consiste en leer entradas en bruto directamente desde /dev/input (evdev) e inyectar eventos sintéticos a través de /dev/uinput, saltándose por completo el modelo de entrada del compositor. Esto es genuinamente independiente del compositor: no le importa si estás en GNOME, KDE o Sway, porque opera por debajo de los tres, en la capa de entrada del kernel. Espanso usa exactamente este enfoque para su soporte de Wayland, que su propia documentación describe como "currently experimental": requiere una concesión puntual de setcap cap_dac_override+p sobre el binario (o pertenecer al grupo input, según la configuración) para leer entradas en bruto sin ejecutarse como root, y viene con advertencias conocidas: las distribuciones de teclado no estadounidenses necesitan configuración explícita, las sesiones de GNOME pueden mostrar parpadeo del backend del portapapeles, y conectar un teclado nuevo requiere reiniciar manualmente el servicio. Funciona, pero "experimental" es la palabra adecuada para describir dónde está hoy.

Herramientas que simplemente no admiten Wayland

Algunas herramientas de automatización de Linux están construidas directamente sobre xdotool y el árbol de ventanas de X11, sin ninguna vía hacia Wayland; AutoKey es el ejemplo más claro: es exclusivo de X11, y XWayland no ayuda porque su simulación de entrada apunta directamente al árbol de ventanas de X11, no al compositor. Si estás en una sesión Wayland pura, herramientas como esta simplemente no funcionan, punto, sea cual sea la configuración.

Cómo lo gestiona Lightning Assist

Lightning Assist adopta un enfoque de dos vías según el tipo de sesión. En X11 y en sesiones XWayland, usa los hooks de entrada estándar de X11: el mismo mecanismo que ha funcionado de forma fiable en Linux durante años. En una sesión Wayland pura, cambia a un backend de entrada de bajo nivel dedicado: la primera vez que lo necesita, la app pide acceso a la entrada una sola vez (un aviso de "Grant access"), y después de esa concesión única, la detección global de teclas y la expansión de texto funcionan igual en GNOME, KDE y otros compositors, sin YAML, sin ningún comando setcap que tengas que ejecutar tú mismo, sin ningún paso de configuración por distribución de teclado. Este es un backend mantenido construido para este propósito, no un parche añadido después; y el modelo de concesión puntual significa que no repites un paso manual en cada sesión.

Una lista de comprobación práctica antes de elegir una herramienta

Dada la cantidad de variación que existe entre herramientas, vale la pena revisar algunas cosas antes de decidirte por una en un escritorio Wayland:

  • ¿Documenta explícitamente el soporte de Wayland, o solo afirma "soporte para Linux" en general? Las afirmaciones genéricas suelen significar "probado en X11", con el comportamiento en Wayland sin probar.
  • ¿Necesita un paso manual de setcap o de root para funcionar en Wayland? No es motivo de descarte, pero es mejor saberlo de antemano que descubrirlo después de instalarlo.
  • ¿Menciona advertencias específicas de compositor (GNOME, KDE, Sway) en lugar de un genérico "funciona en Wayland"? Las herramientas que son honestas sobre peculiaridades específicas del compositor (parpadeo del portapapeles, configuración de distribución de teclado, reinicio al conectar un dispositivo nuevo) suelen ser las que realmente se han probado allí.
  • ¿Necesita que XWayland siga activado? Si una herramienta solo funciona a través de XWayland, confirma que tu entorno de escritorio lo tiene activado por defecto (la mayoría lo tiene) antes de dar la compatibilidad por hecha.

Preguntas frecuentes

¿Por qué mi expansor de texto funciona en un equipo Linux pero no en otro?

La causa más habitual es el tipo de sesión: las sesiones X11 y las sesiones Wayland gestionan la entrada global de forma completamente distinta, y una herramienta construida principalmente en torno a los hooks de entrada de X11 puede funcionar sin problemas en una y no hacer nada en la otra. Ejecuta echo $XDG_SESSION_TYPE en una terminal para comprobar qué tipo de sesión estás usando ahora mismo.

¿Wayland está simplemente roto para las herramientas de productividad?

No; es un modelo de seguridad distinto, más restrictivo, no un fallo. Las restricciones que bloquean las herramientas de entrada global ingenuas son las mismas que dificultan que una app maliciosa registre tus pulsaciones de teclado o inyecte entradas en tu sesión bancaria. Las herramientas que funcionan bien en Wayland son las construidas específicamente en torno a su modelo de permisos (portals, zwp_virtual_keyboard_v1, o un backend evdev/uinput dedicado con acceso al grupo de entrada), no las que asumen un acceso sin restricciones al estilo X11.

¿Desactivar XWayland rompe la expansión de texto?

Puede hacerlo, para cualquier herramienta que dependa de hooks al estilo X11 para llegar a aplicaciones que corren en XWayland. Si tienes una configuración reforzada con XWayland explícitamente desactivado, comprueba específicamente si tu expansor de texto tiene un backend nativo de Wayland (no solo un hook de X11): el backend de entrada dedicado a Wayland de Lightning Assist y el modo experimental evdev/uinput de Espanso están construidos exactamente para este caso; una herramienta construida puramente sobre xdotool o acceso al árbol de ventanas de X11, como AutoKey, no lo está.

¿Necesito ejecutar algún comando de terminal para que funcione el soporte de Wayland?

Depende de la herramienta. El modo Wayland de Espanso necesita una concesión puntual de setcap (o la pertenencia equivalente al grupo de entrada) que ejecutas tú mismo. El backend de Wayland de Lightning Assist, en cambio, pide un permiso puntual de "Grant access" dentro de la app la primera vez que lo necesita, sin necesidad de ningún comando de terminal.

Lecturas relacionadas

Fuentes

Artículos relacionados