Pourra-t-on enfin utiliser Wayland en 2026 ?

• Wayland est la pile graphique successeure de X11, lancée en 2008, mais l’auteur estime ne pas avoir pu l’utiliser correctement sur son système pendant 18 ans
• En 2025, la prise en charge de GBM et de l’explicit sync par les pilotes nVidia permet enfin un lancement de base, mais une transition complète reste difficile en raison de limites comme l’absence de prise en charge du TILE sur les moniteurs 8K
• Sway 1.11 et wlroots 0.19.0 ont apporté des avancées techniques majeures, mais de nombreux obstacles à l’usage réel subsistent, comme la latence d’entrée, des glitches graphiques et des problèmes de mise à l’échelle sous Xwayland
• Des applications clés comme Chrome et Emacs présentent encore des problèmes de baisse de performances, de différences de rendu et d’instabilité de l’accélération matérielle
• Globalement, Wayland « entre enfin dans le champ du réellement utilisable », mais pour un usage quotidien, la combinaison X11/i3 reste encore plus stable

---

Contexte historique de Wayland

• Wayland est un projet successeur du serveur X (X11, Xorg), lancé en 2008, et l’auteur a développé en 2009 le gestionnaire de fenêtres en mosaïque i3 pour X11
• Au début, seul le compositeur de démonstration Weston pouvait être lancé, puis GNOME en 2014, suivi plus tard par KDE, ont commencé à prendre en charge Wayland
• Des applications majeures comme Firefox, Chrome et Emacs ne pouvaient utiliser Wayland qu’au moyen de flags expérimentaux
• Les GPU nVidia ont longtemps été inutilisables sous Wayland ou provoquaient des erreurs graphiques, et les problèmes de compatibilité avec les moniteurs 8K ont perduré
• Récemment, des distributions majeures comme Fedora, RHEL et Asahi Linux ont adopté Wayland comme pile de bureau par défaut, voire unique, ce qui accroît la pression pour la transition

Configuration de l’environnement d’exécution Wayland

• Le système de test utilise une nVidia RTX 4070 Ti (PC portable) et une RTX 3060 Ti (PC principal)
• À partir du pilote nVidia 495 (2021), la prise en charge de GBM a été ajoutée, et la fonction explicit sync a été implémentée dans Sway 1.11 (2025) et wlroots 0.19.0
• Toutefois, en raison de l’absence de prise en charge de la propriété TILE du moniteur 8K Dell UP3218K, l’écran apparaît scindé en deux dans Sway
  • Grâce à un patch de EBADBEEF et à l’analyse de Claude Code, l’auteur a découvert un bug de propriété DRM SRC_X et a réussi à afficher l’écran en plein format via un patch de contournement
• GNOME prend en charge TILE, mais un fort tearing au centre de l’écran se produit
• Dans un environnement NixOS 25.11, GDM, GNOME et Sway sont configurés en parallèle, avec l’ajout d’outils dédiés à Wayland comme foot, fuzzel et wayland-utils

Résultats de l’expérimentation : environnement Sway

• Sway reste majoritairement compatible avec la configuration i3, et l’auteur a ajusté la disposition de clavier NEO ainsi que les paramètres d’entrée/sortie
• Principaux problèmes :
  • latence du pointeur de la souris et mouvements peu fluides (probablement liés à l’absence de prise en charge du curseur matériel nVidia)
  • impossibilité de mettre à l’échelle les applications Xwayland, ce qui les rend floues ou doublement agrandies
  • certains raccourcis sont déclenchés deux fois (ghost key press)
• Dans les applications GTK, le problème initial de taille de police excessive a été résolu avec gsettings reset
• GTK3 n’utilise que les réglages dconf ; il faut donc définir font-name dans dconf pour obtenir un rendu cohérent
• swaylock, contrairement à i3lock, laisse l’écran dans un état « rouge » à sa fermeture et ne peut être déverrouillé qu’avec SIGUSR1
• Les outils d’automatisation basés sur l’IPC de i3 ne sont que partiellement compatibles en raison de différences de chemin de socket, de processus résiduels et de l’absence de prise en charge de la restauration de layout

Test des principales applications

• Le terminal foot est léger, mais présente quelques différences de couleur, des problèmes de gestion de Ctrl+Enter, de sélection d’URL et de couleurs avec screen
• Emacs s’exécute par défaut via Xwayland et apparaît flou ; la version pgtk souffre d’une latence d’entrée et de différences d’espacement des caractères
• Chrome voit son processus GPU planter, ce qui désactive l’accélération matérielle, et lors de la restauration des fenêtres, les informations sur l’espace de travail précédent ne sont pas conservées
• Le partage d’écran fonctionne via xdg-desktop-portal-wlr, mais il ne prend pas en charge le partage fenêtre par fenêtre et pose des problèmes de transmission en basse résolution
• Lors de l’activation de la mise à l’échelle des sorties, des glitches font momentanément bouger ou flouter le contenu des fenêtres
• Les notifications dunst et rofi (2.0.0 ou supérieur) fonctionnent correctement, tandis que l’outil de capture grim rend la sélection de fenêtre peu pratique

Conclusion : Wayland sera-t-il utilisable en 2026 ?

• La session Wayland/Sway se rapproche pour la première fois d’un niveau réellement exploitable, mais de nombreux défauts subsistent
• L’environnement X11/i3 offre une faible latence d’entrée d’environ 763 μs et une stabilité parfaite
• Le passage à Wayland entraîne des glitches graphiques, de la latence d’entrée et une baisse des performances des applications clés
• Conditions nécessaires pour un usage quotidien :
  • correction des doubles frappes et des glitches de transition dans Sway
  • stabilisation de l’accélération matérielle de Chrome et prise en charge de la restauration des fenêtres
  • amélioration de la latence d’entrée et du rendu d’Emacs (pgtk)
• En conclusion, Wayland n’est pas encore prêt pour un usage professionnel quotidien, et l’auteur prévoit de continuer à utiliser X11/i3

[GN⁺]

Réactions sur Hacker News

• Wayland n’est qu’un protocole, donc il existe plusieurs implémentations (GNOME, KDE, wlroots, etc.)
  Xorg reposait sur une base unique et solide sur laquelle venait se greffer le bureau, tandis qu’avec Wayland, chaque environnement de bureau réinvente en quelque sorte la roue
  Weston est utile comme référence, mais inadapté à un usage quotidien
  Il faudrait selon moi une bibliothèque standard commune à tous les bureaux. wlroots vise ce rôle, mais il semble peu probable que GNOME ou KDE y migrent bientôt
  • Je pense que X.org avait trouvé le bon niveau d’abstraction. Le gestionnaire de fenêtres n’avait pas besoin de gérer directement les entrées ou les sorties, ce qui apportait simplicité et efficacité énergétique. Wayland n’a donc pas retenu les leçons de X11
  • J’ai utilisé Sway, Hyprland, et maintenant niri. Sway et niri, basés sur wlroots, sont plutôt bons, mais il reste beaucoup de bugs aléatoires. Problèmes de pointeur dans les applis Wine, plantages du partage d’écran, problèmes de couleur 10 bits, etc. Peut-être que ce sera stable vers 2027, mais pour 20 ans de développement, ça donne une impression d’inefficacité
  • KDE et GNOME ont chacun leur propre implémentation de xdg-desktop-portal, ce qui crée des problèmes de compatibilité. Avec wlroots, il faut xdg-desktop-portal-wlr, et avec Hyprland, xdg-desktop-portal-hyprland.
    L’architecture de Wayland elle-même semble séduisante en théorie, comme l’indique la documentation officielle de l’architecture, mais en pratique il manque encore beaucoup de choses au niveau du protocole
  • En réalité, X aussi était un protocole, mais comme il y avait une implémentation unique avec X.org, il y avait moins de confusion. Avoir une bibliothèque standardisée au niveau de wlroots n’a rien de techniquement impossible
  • Les développeurs de Wayland l’avaient conçu au départ comme un protocole uniquement pour l’affichage. Ils espéraient que les protocoles d’entrée ou de gestion des fenêtres seraient créés par d’autres groupes, mais cela n’a pas vraiment abouti.
    À ce stade, vouloir remplacer Wayland risque surtout de gaspiller des efforts à recréer ce qui est déjà mature
• Je ne vois toujours pas pourquoi il faudrait utiliser Wayland. Xorg est stable, et la plupart des guides de résolution de problèmes commencent par « si vous utilisez Wayland, repassez sur Xorg ».
  L’adoption massive n’augmentera sans doute vraiment que lorsque les distributions l’imposeront par défaut, comme avec systemd
  • L’utilisateur lambda n’a pas vraiment de raison de changer. En revanche, Wayland gère bien les points faibles de X11, comme le scaling multi-écran.
    Du point de vue de GNOME et KDE, migrer vers Wayland sert surtout à réduire la charge de maintenance continue de X11.
    Je pense que l’objectif cette année est d’atteindre un niveau où il n’y a plus de défauts majeurs
  • Wayland donne une impression de performances plus fluides, mais je dois rester sur Xorg à cause de certaines applications.
    GNOME 49 sur Arch et Ubuntu a déjà retiré Xorg du mode par défaut, et KDE devrait bientôt suivre. L’ère de Xorg touche à sa fin
  • À l’époque, il fallait modifier xorg.conf à la main, mais après avoir testé Wayland à titre expérimental sur Ubuntu, j’ai complètement basculé. Avec un GPU AMD, tout semble fluide et sans problème
  • L’avantage de Wayland, c’est le fractional scaling
  • J’ai besoin d’outils comme x2x, xev et xdotool, mais à cause du modèle de sécurité de Wayland, c’est impossible, donc je reste sur Xorg
• Dire que Nvidia a refusé l’API GBM de Wayland est une idée reçue. GBM était une API non officielle interne à Mesa, donc Nvidia ne pouvait pas l’implémenter directement.
  Nvidia a donc proposé une alternative neutre vis-à-vis des fournisseurs, EGLStreams.
  Le vrai problème, c’est plutôt que l’écosystème freedesktop n’avait pas fourni une architecture permettant au pilote Nvidia de fonctionner
  • Je me demande quand même comment un projet open source comme Mesa peut dépendre d’une API non publique
• J’utilise Wayland sur Gnome depuis des années et je n’ai aucun problème.
  C’est peut-être aussi parce que je n’ai pas de matériel Nvidia très compliqué, mais je veux souligner que Wayland peut très bien fonctionner
  • Même constat pour moi avec Sway (depuis 2016) et KDE Plasma 6, où tout fonctionne parfaitement. Je ne lance les jeux Steam sous XWayland. La combinaison AMD/Intel est bien plus stable
  • Même avec du matériel Nvidia, ça fonctionne désormais de façon assez fluide. Avant c’était saccadé, mais aujourd’hui j’ai l’impression que c’est mieux que Xorg.
    En revanche, il faut encore contourner certaines limites via des extensions Gnome Shell pour des fonctions comme le contrôle de la position des fenêtres ou l’exploration d’autres applications
  • Comme pour ceux qui ne percevaient pas le scintillement des anciens écrans CRT, les petites gênes de Wayland, comme le ressenti subtil de l’entrée ou les différences de rendu des polices, peuvent être perçues très différemment selon les personnes
• J’utilise Wayland basé sur wlroots/swaywm depuis plusieurs années, et même l’eGPU fonctionne parfaitement.
  Cela dit, c’est peut-être lié au fait que je suis sur du matériel AMD. La vie est trop courte pour la gaspiller avec des problèmes Nvidia
  • À l’inverse, sur un GPU intégré Intel, sway plante souvent, donc je suis revenu à i3+Xorg
  • J’utilise Nvidia depuis 23 ans sans gros problème. Je pense simplement que cela relève du choix de chacun
  • Autrefois, ça marchait bien aussi avec Nvidia, et avec le patch TILE, même les écrans 5K passaient correctement.
    Je suis passé à Wayland pour le support du scaling sur plusieurs sorties, puis je suis finalement revenu en arrière
• Je suis passé récemment de Windows à Linux, et avant c’était impossible à cause de l’absence de fractional scaling.
  Wayland a résolu ce problème, ce qui est une grosse amélioration. En revanche, comme toutes les distributions n’utilisent pas Wayland par défaut, j’ai choisi Ubuntu.
  Le Firefox en Snap n’utilisait pas l’accélération matérielle, ce qui était un peu gênant
  • Pour moi aussi, le fractional scaling est ce qui manque le plus à Linux.
    Sur macOS, le réglage « ressemble à du 1440p » est parfait, et sur Windows c’est un peu flou.
    Sur Linux, X11 est lent et Wayland a encore une certaine latence de performance
• Moi aussi, j’utilise une combinaison i3+NixOS+urxvt+zsh+Emacs+rofi+maim+xdotool.
  Remplacer cette pile qui fonctionne parfaitement par Sway apporterait plus de pertes que de gains.
  Je trouve remarquable que Michael ait tenté l’expérience et l’ait documentée
  • J’ai trouvé impressionnant le soin apporté à documenter les problèmes réels
• Je n’ai pas l’intention de migrer tant que mon gestionnaire de fenêtres (WM) ne prendra pas en charge Wayland.
  Le principal problème de Wayland, c’est que beaucoup de projets de WM ne peuvent pas faire la transition faute de ressources humaines.
  On peut contourner cela avec XWayland, mais je n’ai pas envie d’ajouter une couche à un environnement qui fonctionne déjà parfaitement
  • Si vous utilisez StumpWM, sa version Wayland, Mahogany, est en développement actif.
    Et Wayback est un projet qui fait tourner tout un bureau X11 au-dessus de Wayland
• J’utilise Wayland sur un laptop Framework, et tout fonctionne parfaitement.
  Moniteur 4K, bascule en écran unique, fractional scaling : aucun souci.
  Même sur un vieux Chromebook, le tearing a disparu et tout est fluide.
  Je n’ai encore constaté aucun inconvénient ; au contraire, le seul défaut, c’est d’entendre qu’on aurait « tort » de l’utiliser
  • Tant mieux si ça fonctionne bien pour vous, mais il faut aussi reconnaître que pour d’autres, ça ne marche pas
  • Ce n’est pas parce qu’on a eu la chance de ne pas rencontrer de problèmes qu’il n’y a pas de défauts
• Pour moi, Wayland n’a que des inconvénients et aucun avantage. Je trouve que sa conception, qui repousse la complexité vers d’autres couches, est mauvaise.
  Je compte continuer à utiliser Xorg et Openbox
  • Répartir la complexité en plusieurs endroits au lieu de la centraliser en un seul est une décision incompréhensible
  • Malgré tout, Xorg est de moins en moins maintenu, et les principaux développeurs migrent vers Wayland.
    Au final, Wayland risque de devenir la seule option activement maintenue