guides

Expansion de texte sous Wayland : pourquoi ça casse et ce qui fonctionne vraiment

Trofin Sorin-IoanTrofin Sorin-IoanCTO, Lightning Assist26 juillet 20269 min de lecture
waylandlinuxx11text-expandergnomekdexwaylandinput
Partager :
Expansion de texte sous Wayland : pourquoi ça casse et ce qui fonctionne vraiment

Réponse rapide : les correcteurs d'expansion de texte doivent surveiller chaque frappe au niveau du système entier et simuler la saisie dans l'application qui a le focus. X11 autorisait les deux par défaut ; les compositeurs de Wayland restreignent délibérément les deux pour des raisons de sécurité, ce qui explique qu'un correcteur d'expansion de texte fonctionnant parfaitement sous Ubuntu 20.04 puisse s'installer proprement et ne rien faire du tout sur une session Wayland moderne — sans aucun message d'erreur. Il n'y a pas de solution unique ; les vraies options sont XWayland (fonctionner à l'ancienne, dans une couche de compatibilité), un backend evdev/uinput avec accès explicite au groupe input, ou un backend d'entrée bas niveau dédié qui demande une autorisation ponctuelle. Lightning Assist utilise cette dernière option.

Si vous avez installé un correcteur d'expansion de texte, tapé votre déclencheur, et constaté qu'il ne se passait rien — pas d'erreur, pas de plantage, juste le silence — vous êtes très probablement sous Wayland, et c'est une catégorie de problème connue, pas un bug propre à l'outil que vous avez choisi.

Pourquoi Wayland bloque l'écoute globale du clavier

Sous X11, n'importe quel processus peut enregistrer un hook clavier bas niveau et lire chaque frappe du système, et n'importe quel processus peut simuler des frappes dans la fenêtre qui a actuellement le focus — c'est littéralement ce que font des outils comme xdotool, et c'est pourquoi les correcteurs d'expansion de texte, les gestionnaires de raccourcis et les logiciels de contrôle à distance fonctionnent sous Linux depuis deux décennies sans trop de friction. C'est aussi, du point de vue de la sécurité, exactement le genre de chose que l'on ne veut pas par défaut : n'importe quelle application, y compris une application compromise, peut enregistrer vos frappes ou injecter des entrées arbitraires dans votre session bancaire.

Les compositeurs de Wayland (Mutter pour GNOME, KWin pour KDE Plasma, ceux basés sur wlroots pour Sway et similaires) ont été conçus autour du défaut opposé : une application ne voit que les événements d'entrée destinés à sa propre fenêtre, et rien ne peut injecter d'entrée synthétique dans une autre application sans un mécanisme explicite et délibéré prévu à cet effet. Ce n'est ni un oubli ni une fonctionnalité manquante — c'est le modèle de sécurité qui fonctionne comme prévu. Le coût, c'est que chaque outil qui reposait sur le comportement X11 « n'importe quel processus peut observer et injecter » a besoin d'une manière différente, et généralement plus limitée, d'accomplir la même tâche.

Le résultat concret : un correcteur d'expansion de texte qui capte les frappes à la manière X11 ne voit rien sur une session Wayland pure, et un correcteur d'expansion de texte qui injecte du texte à la manière X11 n'a rien où injecter. Il échoue généralement en silence plutôt qu'avec une erreur claire, car aucune exception n'est levée — les événements qu'il écoute n'arrivent tout simplement jamais.

Pourquoi les extensions de navigateur ne couvrent pas le bureau

Une solution de contournement naturelle est un correcteur d'expansion de texte basé sur une extension de navigateur, et pour les seuls onglets de navigateur, ça fonctionne — les extensions opèrent à l'intérieur du DOM de la page, ce qui n'a rien à voir avec le modèle d'entrée de Wayland. Le problème, c'est la portée : une extension ne voit jamais que le navigateur dans lequel elle est installée. Elle ne peut pas développer un snippet dans votre terminal, votre IDE, une application native GTK ou Qt, le client de bureau de Slack ou de Discord, ou un lecteur de PDF. Si votre journée comporte quoi que ce soit en dehors d'un onglet de navigateur — ce qui, pour les développeurs et les équipes support, représente la majeure partie de la journée — une extension de navigateur ne résout qu'une fraction du problème et laisse le reste de votre bureau sans couverture.

Ce qui existe réellement sous Wayland aujourd'hui

Il n'y a pas de solution universelle, mais il existe une poignée d'approches réelles et documentées, chacune avec ses compromis.

XWayland — fonctionner à l'ancienne, dans une couche de compatibilité

La plupart des environnements de bureau Wayland (GNOME, KDE Plasma par défaut sous Ubuntu 22.04+, Fedora 38+ et similaires) font tourner XWayland aux côtés du compositeur Wayland natif — une couche de compatibilité qui permet aux applications exclusivement X11 de continuer à fonctionner. Un outil construit sur des hooks d'entrée X11 continue de fonctionner pour les applications tournant dans XWayland. Le piège est dans la portée : si vous êtes dans une session où XWayland est explicitement désactivé (certaines configurations GNOME durcies), ou que l'application spécifique dans laquelle vous tapez est un client Wayland natif plutôt qu'un client XWayland, le hooking à la X11 ne l'atteint pas.

Le protocole zwp_virtual_keyboard_v1

Certains compositeurs Wayland — dont Mutter de GNOME et KWin de KDE — implémentent le protocole Wayland zwp_virtual_keyboard_v1, qui donne à une application un moyen sanctionné de simuler des événements clavier. C'est plus proche d'une réponse intégrée au niveau du protocole que d'une solution de contournement, mais cela dépend du compositeur : une application qui s'appuie dessus ne fonctionne que là où le compositeur a choisi d'implémenter ce protocole, et le comportement peut quand même varier — certaines configurations se rabattent sur un substitut de collage presse-papiers, qui peut se comporter différemment dans les applications avec une gestion spéciale du collage (un terminal en mode bracketed-paste, par exemple).

L'interface RemoteDesktop de xdg-desktop-portal

La spécification de portals de freedesktop.org définit une interface RemoteDesktop construite explicitement pour « permettre le contrôle à distance d'une session de bureau » — elle peut injecter des événements clavier et souris, mais seulement après que l'utilisateur a accordé l'accès KEYBOARD/POINTER au démarrage de la session, et c'est un mécanisme de session limité par des permissions plutôt qu'un hook système toujours actif. C'est la porte sanctionnée que Wayland fournit pour l'injection d'entrées, mais elle a été conçue autour d'outils de contrôle à distance et de partage d'écran, pas autour de « détecter silencieusement chaque déclencheur que je tape, en permanence, en arrière-plan » — ce qui est exactement ce dont un correcteur d'expansion de texte a besoin.

evdev/uinput avec accès au groupe input

L'option de plus bas niveau consiste à lire les entrées brutes directement depuis /dev/input (evdev) et à injecter des événements synthétiques via /dev/uinput, en contournant entièrement le modèle d'entrée du compositeur. C'est véritablement indépendant du compositeur — peu importe que vous soyez sous GNOME, KDE ou Sway, car cela opère en dessous des trois, au niveau de la couche d'entrée du noyau. Espanso utilise exactement cette approche pour son support Wayland, que sa propre documentation décrit comme « currently experimental » : cela nécessite une autorisation ponctuelle setcap cap_dac_override+p sur le binaire (ou l'appartenance au groupe input, selon la configuration) pour lire les entrées brutes sans s'exécuter en root, et cela s'accompagne de mises en garde connues — les dispositions clavier non américaines nécessitent une configuration explicite, les sessions GNOME peuvent afficher un scintillement du backend presse-papiers, et brancher un nouveau clavier nécessite un redémarrage manuel du service. Ça fonctionne, mais « expérimental » est le mot juste pour décrire où cela en est aujourd'hui.

Les outils qui ne prennent tout simplement pas en charge Wayland

Certains outils d'automatisation Linux sont construits directement sur xdotool et l'arbre de fenêtres X11, sans aucune voie vers Wayland — AutoKey en est l'exemple le plus clair : il est exclusivement X11, et XWayland n'aide pas car sa simulation d'entrée cible directement l'arbre de fenêtres X11, pas le compositeur. Si vous êtes sur une session Wayland pure, des outils comme celui-ci ne fonctionnent tout simplement pas, point final, quelle que soit la configuration.

Comment Lightning Assist gère cela

Lightning Assist adopte une approche à deux voies selon le type de session. Sous X11 et sur les sessions XWayland, il utilise les hooks d'entrée X11 standards — le même mécanisme qui fonctionne de manière fiable sous Linux depuis des années. Sur une session Wayland pure, il bascule vers un backend d'entrée bas niveau dédié : la première fois qu'il en a besoin, l'application demande une seule fois l'accès aux entrées (une invite « Grant access »), et après cette autorisation unique, la détection globale des touches et l'expansion de texte fonctionnent de la même façon sous GNOME, KDE et d'autres compositeurs — pas de YAML, pas de commande setcap à exécuter vous-même, pas d'étape de configuration par disposition clavier. C'est un backend maintenu, construit dans ce but précis, pas une solution de repli ajoutée après coup, et le modèle d'autorisation ponctuelle signifie que vous ne répétez pas une étape manuelle à chaque session.

Une check-list pratique avant de choisir un outil

Vu l'ampleur des variations entre les outils, il vaut la peine de vérifier quelques points avant de vous engager sur l'un d'eux sur un bureau Wayland :

  • Documente-t-il explicitement le support Wayland, ou se contente-t-il d'affirmer un « support Linux » général ? Les affirmations générales signifient souvent « testé sous X11 », avec un comportement Wayland non testé.
  • A-t-il besoin d'une étape manuelle setcap ou root pour fonctionner sous Wayland ? Ce n'est pas rédhibitoire, mais il vaut mieux le savoir avant plutôt que de le découvrir après l'installation.
  • Nomme-t-il des mises en garde spécifiques à un compositeur (GNOME, KDE, Sway) plutôt qu'un « fonctionne sous Wayland » général ? Les outils honnêtes sur les particularités propres à chaque compositeur (scintillement du presse-papiers, configuration de disposition clavier, redémarrage à la connexion d'un nouvel appareil) sont généralement ceux qui ont réellement été testés là-bas.
  • XWayland doit-il rester activé ? Si un outil ne fonctionne que via XWayland, vérifiez que votre environnement de bureau l'active par défaut (la plupart le font) avant de présumer la compatibilité.

Questions fréquentes

Pourquoi mon correcteur d'expansion de texte fonctionne-t-il sur une machine Linux mais pas sur une autre ?

La cause la plus courante est le type de session : les sessions X11 et les sessions Wayland gèrent l'entrée globale de manière complètement différente, et un outil construit principalement autour des hooks d'entrée X11 peut fonctionner parfaitement sur l'une et ne rien faire sur l'autre. Exécutez echo $XDG_SESSION_TYPE dans un terminal pour vérifier quel type de session vous utilisez actuellement.

Wayland est-il tout simplement cassé pour les outils de productivité ?

Non — c'est un modèle de sécurité différent, plus restrictif, pas un bug. Les restrictions qui bloquent les outils d'entrée globale naïfs sont les mêmes restrictions qui rendent plus difficile pour une application malveillante d'enregistrer vos frappes ou d'injecter des entrées dans votre session bancaire. Les outils qui fonctionnent bien sous Wayland sont ceux construits spécifiquement autour de son modèle de permissions (portals, zwp_virtual_keyboard_v1, ou un backend evdev/uinput dédié avec accès au groupe input), plutôt que ceux supposant un accès sans restriction à la X11.

Désactiver XWayland casse-t-il l'expansion de texte ?

Cela peut arriver, pour tout outil qui dépend des hooks à la X11 pour atteindre les applications tournant dans XWayland. Si vous avez une configuration durcie avec XWayland explicitement désactivé, vérifiez spécifiquement si votre correcteur d'expansion de texte dispose d'un backend Wayland natif (pas seulement d'un hook X11) — le backend d'entrée Wayland dédié de Lightning Assist et le mode evdev/uinput expérimental d'Espanso sont tous deux construits exactement pour ce cas ; un outil construit purement sur xdotool ou l'accès à l'arbre de fenêtres X11, comme AutoKey, ne l'est pas.

Dois-je exécuter des commandes terminal pour faire fonctionner le support Wayland ?

Cela dépend de l'outil. Le mode Wayland d'Espanso nécessite une autorisation setcap ponctuelle (ou l'appartenance équivalente au groupe input) que vous exécutez vous-même. Le backend Wayland de Lightning Assist demande à la place une permission ponctuelle « Grant access » dans l'application, la première fois qu'elle est nécessaire — aucune commande terminal requise.

Lectures associées

Sources

Articles similaires