ADR-007 — Compositeur de console air-console, symétrie avec air-wm

Statut : Accepté — document fondateur. Édition directe autorisée en phase de design pré-ouverture publique ; immuable après ouverture publique (toute évolution via RFC, ADR-015). Catégorie : Architecture (couche 3 — compositeur de console).

Contexte

Les applications en mode texte passent par la VT du noyau ou par un émulateur de terminal. Les deux masquent l’état réel des entrées : modificateurs incomplets, relâchement de touche invisible, souris et multi-touch inaccessibles.

Une application texte ambitieuse s’y heurte, non par manque d’idées, mais parce que le canal ne transporte pas l’information.

Décision

Air fournit un compositeur de mode texte qui bypasse la VT kernel via DRM/KMS pour le rendu et evdev pour l’input. Backend partagé (DRM, evdev, seats, xkbcommon, glyph rasterizer) avec le compositeur Wayland air-wm. Permet aux apps TUI d’accéder à l’état réel des inputs (modifiers complets, key release, souris, multi-touch) là où la VT et les terminaux classiques l’interdisent.

Conséquences

Symétrie architecturale forte : tout comme Air est compositeur Wayland pour le graphique au lieu d’être client d’un compositeur existant, Air est compositeur de console pour le texte au lieu d’être client de la VT kernel.

Alternatives rejetées

Aucune alternative n’a été consignée lors de l’instruction.

Amendement — la promesse d’« état réel des inputs » ne vaut qu’en local (2026-08-22)

La décision ci-dessus promet aux applications TUI « l’accès à l’état réel des inputs (modifiers complets, key release, souris, multi-touch) là où la VT et les terminaux classiques l’interdisent ». Cette promesse est vraie en local, et fausse à distance. Rien ne le disait, et un développeur qui la lit n’a aucune raison de le deviner.

Pourquoi

air-console tient cette promesse parce qu’il lit evdev — les vrais événements du matériel, sur la machine où le matériel se trouve. En session distante, ce matériel n’existe pas localement : le clavier et le pointeur sont chez le client, et ce qui traverse le réseau est un flux d’octets.

Ce n’est donc pas une limite du noyau ni de la VT — c’est une limite du transport. Un air-tui lancé par air-sshd reçoit les mêmes caractères qu’un vim sous xterm, pour la même raison : le protocole SSH transporte un pseudo-terminal, et un pseudo-terminal est un tuyau d’octets.

Ce que cela implique pour une application TUI

Une application qui s’appuie sur les événements réels — relâchement de touche, modificateurs complets, multi-touch — doit dégrader quand ils sont absents, et le contrat d’air-tui (ADR-026) doit lui donner de quoi le savoir. Écrire une TUI qui exige le relâchement de touche revient à écrire une TUI qui ne marche pas en SSH — ce qui, pour un système dont le démonstrateur est un serveur SSH, serait une contradiction.

Formulation retenue :

air-console donne l’état réel des périphériques d’entrée là où ces périphériques existent — c’est-à-dire en session locale. En session distante, une application air-tui reçoit le flux d’octets d’un pseudo-terminal, comme n’importe quel programme en mode texte.

Ce qui n’est pas tranché ici

Faire traverser les événements d’entrée au réseau est concevable — une extension du protocole qui transporterait les événements du client vers le serveur. Ce n’est pas décidé, et deux objections doivent être levées d’abord :

1. C’est un canal d’exfiltration de frappe par construction. Expédier les événements matériels bruts d’un client vers un serveur, c’est offrir au serveur ce qu’un enregistreur de frappe cherche. La même primitive qu’AirDeviceOperation::GrabInput refuse localement.
2. Cela lie le serveur au matériel du client — dispositions de clavier, capacités multi-touch, pilotes. Une application distante se mettrait à dépendre de ce qu’elle ne contrôle pas.

À instruire par un ADR de sécurité si le besoin se présente, pas par extension silencieuse du protocole.

Licence du document : MPL 2.0