Séparer le compositeur Wayland du gestionnaire de fenêtres

• Les environnements Wayland existants reposaient sur une architecture où le compositeur et le gestionnaire de fenêtres formaient un seul programme, mais river 0.4.0 les sépare en processus distincts
• Le nouveau protocole river-window-management-v1 confère au gestionnaire de fenêtres l’autorité complète sur les politiques comme le placement des fenêtres et les raccourcis clavier, tout en préservant la perfection d’image (frame perfection) et les performances
• Cette architecture fonctionne sans latence d’entrée (latency) et garantit un rendu propre, même avec des dispositions en mosaïque complexes, grâce à des mises à jour d’état atomiques
• Grâce à cette séparation, le gestionnaire de fenêtres peut être développé et redémarré indépendamment, et il devient plus facile à implémenter même dans des langages de haut niveau
• Cette approche favorise une plus grande diversité des gestionnaires de fenêtres dans l’écosystème Wayland, et river prend déjà en charge plus de 15 gestionnaires compatibles

---

Structure traditionnelle de Wayland et approche de séparation de river

• Les compositeurs Wayland traditionnels intègrent en un seul processus trois rôles : serveur d’affichage, compositeur et gestionnaire de fenêtres
  • Le serveur d’affichage achemine les événements d’entrée et transmet les buffers d’affichage au noyau
  • Le compositeur assemble les buffers de plusieurs fenêtres pour produire l’écran final
  • Le gestionnaire de fenêtres applique les politiques utilisateur, comme le placement des fenêtres et les raccourcis clavier
• Dans l’architecture X11, le serveur d’affichage existe comme processus séparé, ce qui entraîne des allers-retours inutiles et de la latence
• Wayland a résolu ce point en intégrant serveur et compositeur, mais il n’est pas nécessaire d’y coupler aussi le gestionnaire de fenêtres
• river défait ce couplage en séparant le gestionnaire de fenêtres dans un programme distinct

Principes de conception du protocole river-window-management-v1

• Conçu pour que le gestionnaire de fenêtres dispose d’un contrôle maximal tout en conservant les avantages de Wayland
• Aucun aller-retour n’est nécessaire à chaque frame ou événement d’entrée, donc aucune latence d’entrée
• Maintien de la perfection d’image (frame perfection) : lors de l’ouverture d’une fenêtre ou d’un changement de taille, l’actualisation de l’écran se fait sans trous ni chevauchements
  • Le rendu est différé jusqu’à ce que toutes les fenêtres aient soumis leur nouveau buffer, avec un traitement par timeout au-delà d’un certain délai
• Plus une application est bien implémentée, plus une synchronisation complète des frames est possible

Architecture de gestion de fenêtres fondée sur une machine à états

• Le protocole sépare l’état en état de gestion des fenêtres et état de rendu
  • État de gestion des fenêtres : taille des fenêtres, mode plein écran, focus clavier, raccourcis clavier, etc.
  • État de rendu : position des fenêtres, ordre, décorations, recadrage, etc.
• Les modifications sont regroupées et traitées sous forme de mises à jour atomiques (manage/render sequence)
• Le compositeur démarre la séquence et, en l’absence de changement d’état, le gestionnaire de fenêtres reste en attente
• Cette structure formalise explicitement des concepts déjà présents de manière implicite dans river-classic, sway et d’autres

Avantages de l’architecture séparée

• Les développeurs de gestionnaires de fenêtres peuvent se concentrer uniquement sur les politiques, sans avoir à implémenter l’ensemble du compositeur
• Débogage et redémarrage sont facilités, et un crash du gestionnaire de fenêtres n’entraîne pas la fin de la session
• Même écrit dans un langage à ramasse-miettes, il n’y a pas de perte de performances ni de retard d’affichage
• Il existe déjà plus de 15 gestionnaires de fenêtres compatibles avec river, avec l’espoir d’atteindre une diversité comparable à celle de X11

Limites et feuille de route

• Le protocole actuel ne prend en charge que les environnements de bureau 2D ; la VR et d’autres usages ne sont pas pris en charge
• Les effets visuels complexes (par exemple des fenêtres qui ondulent) sortent du périmètre, mais des animations simples restent possibles
• La prise en charge de shaders personnalisés est envisagée à l’avenir, sans être prévue à court terme
• river 0.4.0 est déjà suffisant pour un usage quotidien, et des améliorations de l’UX sont prévues avant le passage en version 1.0.0
• Pour poursuivre le développement, un soutien est sollicité via liberapay, GitHub Sponsors, Ko-fi

Exemples et galerie

• Présentation de plusieurs exemples de gestionnaires de fenêtres fonctionnant avec river
  • Canoe : gestionnaire de fenêtres empilé classique
  • reka : gestionnaire de fenêtres basé sur Emacs
  • tarazed : environnement de bureau centré sur la concentration
  • rhine : gestion récursive et modulaire des fenêtres avec prise en charge des animations
• Il existe également de nombreux autres gestionnaires de fenêtres compatibles avec river

[GN⁺]

Avis sur Hacker News

• Dans les commentaires, il est difficile de comprendre la frustration envers Wayland (le protocole)
  des bibliothèques comme wlroots prennent déjà en charge les parties lourdes, et désormais river fournit une abstraction de plus haut niveau
  le projet Wayland aurait peut-être pu proposer ce type d’abstraction plus tôt, mais c’était selon moi quelque chose que n’importe qui pouvait faire
  au final, nous bénéficions de ces avancées gratuitement, donc il n’y a pas lieu de se plaindre que quelqu’un d’autre ne l’ait pas fait à notre place

  • Le problème a commencé, selon moi, quand Wayland a adopté au départ une position de principe du type interdiction des captures d’écran
    les questions d’accessibilité ont aussi été considérées comme des risques de sécurité, ce qui a compliqué la conception, et maintenant qu’on entre dans l’ère de l’Agentic AI, cela pourrait devenir un point intéressant
    Pipewire comble peu à peu ce qui manquait à Wayland, mais il reste l’impression qu’il manque encore une conception vraiment conviviale
    malgré tout, même si Wayland recule parfois d’un ou deux pas, dans l’ensemble il avance de deux pas
  • La cause profonde du mécontentement vient selon moi de la communauté Wayland, en particulier de l’attitude du camp GNOME
    il y a souvent des réponses du genre « à prendre ou à laisser », et peu de souplesse face aux demandes externes
    le fait que ce soit fourni gratuitement est appréciable, mais l’imposer de force alors que Xorg est abandonné et qu’il n’y a pas d’alternative me semble problématique

• C’est la première fois qu’en voyant ce projet, j’ai l’impression que Wayland n’est pas une perte de temps
  un serveur d’affichage n’a pas nécessairement besoin de compliquer les choses en gérant aussi les fenêtres
  à l’origine, si Wayland a fusionné window manager et compositeur, c’était probablement simplement la voie de moindre résistance
  cela dit, l’accès à distance reste problématique. Des choses qui fonctionnaient bien sous X11 ont eu beaucoup de bugs sous Wayland

  • Sous X11, le Xserver et le window manager étant séparés, il était difficile de résoudre des problèmes comme le placement initial des fenêtres
    Wayland a intégré cela pour corriger le problème, mais a créé d’autres effets secondaires
  • La plupart des petits compositeurs Wayland utilisent des bibliothèques comme wlroots ou smithay
    les frontières d’API sont bien définies, ce qui facilite le partage de code
    je me demande si le bug de rotation à 90 degrés vient du compositeur ou de wlroots
  • L’accès distant sous X11 était un désastre. Sous Wayland, on peut au contraire avoir une architecture plus propre via EGL ou Vulkan, donc je trouve cela plutôt meilleur
  • Sous X11, c’était le window manager qui gérait les décorations, donc les séparer complique la messagerie et la configuration
  • Il est aussi possible que les environnements de bureau aient construit leurs propres écosystèmes et aient ensuite retiré l’échelle derrière eux

• J’ai l’impression qu’on commence seulement maintenant à corriger l’un des nombreux défauts de conception de Wayland
  il faudra sans doute encore 15 ans pour que des protocoles communs s’imposent et que les window managers atteignent le niveau de maturité de X11
  puis, au final, quelqu’un abandonnera encore Wayland pour repartir de zéro en disant qu’il va « faire mieux »

  • C’est pourquoi, ces temps-ci, je pense que des solutions comme WSL ou Virtualization Framework sont les réponses réalistes pour le desktop Linux
    après avoir souffert avec des problèmes UEFI, je suis finalement passé à Samsung DEX
  • Même si on recréait Wayland à partir de zéro, le résultat serait probablement similaire
    les limites relèvent selon moi moins de la technique que de questions politiques

• Utilisateur de Linux depuis 25 ans, je suis passé à Wayland il y a 5 ans et j’en suis satisfait depuis, sans problème de screen tearing
  du point de vue des développeurs, cela crée peut-être plus de travail, mais du point de vue de l’utilisateur c’est une amélioration évidente

  • Cela dit, l’absence de window shading est regrettable
    je me demande si je vais continuer à en parler, comme ceux qui regrettaient autrefois cette fonctionnalité de CDE

• River était déjà excellent avant cette séparation. La suite s’annonce prometteuse
  je suis passé un temps sur Niri, mais j’ai l’intention de revenir un jour
  pour les utilisateurs de Xmonad, River semble être ce qui convient le mieux

  • J’utilise aussi Xmonad, mais Hyprland ne gérait pas correctement la pile master/slave
    je me demande si, dans River, une nouvelle fenêtre est insérée au-dessus de la fenêtre actuellement sélectionnée
    j’aimerais aussi savoir quel sera le nom du projet côté window manager après la séparation

• Au fond, nous sommes simplement en train de réinventer une à une les fonctionnalités de X11
  peut-être qu’un jour les fenêtres Wayland sauront même où elles se trouvent

  • Les idéalistes hésitent encore à expliciter ne serait-ce qu’une grille virtuelle de pixels 2D
    il faudra sans doute encore attendre un moment
  • Mais cela n’aura probablement pas beaucoup d’importance, puisque la plupart des systèmes GNU/Linux servent désormais surtout de serveurs headless ou de systèmes embarqués
    le desktop sera probablement occupé par Android, ChromeOS ou des VM sur Windows/macOS

• J’utilise un window manager River entièrement personnalisé
  sur Hyprland, seul le tiling BSP était vraiment possible par défaut, ce qui était gênant, tandis que sur River je peux faire du tiling uniforme comme je le souhaite
  cette séparation a eu un impact important sur mon workflow

  • Si vous cherchez du « tiling uniforme », hy3 vaut le détour
    j’étais moi aussi un ancien utilisateur de i3, et hy3 m’a permis d’utiliser Hyprland
  • J’ai eu un problème similaire sous Hyprland, et j’ai fini par passer à Niri pour retrouver un environnement de développement stable
    ma configuration est rassemblée dans mes dotfiles
  • J’aimerais demander ce que signifie BSP

• Il me semble que l’un des principes fondamentaux de Wayland était l’intégration du window manager et du compositeur
  je me demande pourquoi cela a été conçu ainsi

  • Si le window manager est un processus séparé qui communique de manière asynchrone, cela crée des problèmes de synchronisation des frames
    Wayland traite cela de manière synchrone pour éliminer les incohérences visuelles
  • Wayland a tout regroupé dans un seul processus pour minimiser les commutations de contexte
    ce protocole cherche justement à séparer le serveur graphique et le window manager tout en conservant cet avantage de performance

• Le plus grand manque de Wayland par rapport à X11 est selon moi l’impossibilité de remplacer facilement le window manager enfichable
  ceux qui essaient de résoudre ce problème sont vraiment précieux

  • En tant que personne qui utilise le même window manager depuis des décennies, il est difficile de passer à Wayland sans interface de remplacement complète
    j’espère que des couches comme River ou Wayback pourront jouer ce rôle
  • Cette contrainte est aussi un obstacle majeur au développement de nouveaux WM et DE
    j’ai moi aussi des idées expérimentales pour le desktop, mais je n’ai d’autre choix que de commencer sur X11, qui permet une itération rapide
    Wayland a encore des faiblesses de conception
  • En réalité, je pense qu’il suffirait qu’une seule implémentation fournisse une API d’extension WM
    il n’est pas nécessaire que le standard impose une structure particulière
  • Dans l’idéal, la structure la plus propre serait une architecture en couches avec un serveur Wayland racine, des serveurs Wayland par utilisateur en dessous, puis un serveur X11, puis au-dessus le window manager

• J’utilise i3 depuis 15 ans, et chaque fois qu’un projet comme celui-ci apparaît, je me demande pourquoi Wayland est nécessaire
  X11 a ses défauts, mais on peut y faire presque tout ce qu’on veut
  Wayland semble toujours générer beaucoup de friction

  • J’utilise Wayland depuis l’époque de KDE 5, et la mise à l’échelle HiDPI était excellente
    pour un utilisateur de portable, c’était un gros avantage, et la prise en charge de VRR ou du HDR est aussi bien plus simple que sur X.org
  • Du point de vue de l’utilisateur, cela fonctionne tout simplement bien
    l’ajustement du DPI par écran, la suppression du screen tearing et le blocage des enregistrements d’écran non autorisés par les applications sont gérés par défaut
  • Si je suis passé de i3 à sway, c’est aussi à cause de la prise en charge du DPI
    je n’ai plus besoin de toucher à Xorg.conf, ce qui améliore nettement le confort au quotidien
    j’utilise encore aujourd’hui des ratios d’échelle différents selon les écrans
  • Sous X11, le réglage des hautes fréquences de rafraîchissement a toujours été un problème
  • Le problème le plus récent que j’ai rencontré, c’est que Wayland ne prend pas en charge DeviceEvent
    j’ai besoin d’une fonction permettant à une fenêtre de recevoir des entrées même lorsqu’elle est inactive, et seul le déplacement de la souris fonctionne de manière exceptionnelle
    j’ai fini par passer à Window Event, mais cela reste contraignant