Wayland 1.23 est disponible.

Après plus d'un an de développement, la version stable du protocole, du mécanisme de communication inter-processus et des bibliothèques Wayland 1.23 est présentée. La branche 1.23 est rétrocompatible au niveau de l'API et de l'ABI avec les versions 1.x et contient principalement des corrections de bogues et des mises à jour mineures du protocole. Les travaux du projet sont distribués sous licence MIT. Le serveur composite de référence Weston, qui fournit le code et des exemples de travail pour utiliser Wayland dans les environnements de bureau et les solutions embarquées, continue de se développer dans le cadre d'un cycle de développement distinct.

Les principales modifications du protocole :

• L'API de libwayland permet au client de définir la taille maximale du tampon interne des connexions côté serveur. La taille maximale de base du tampon est définie via l'interface wl_display, et la nouvelle API permet aux clients de la modifier pour chaque connexion client. D'un point de vue pratique, ce changement permet d'utiliser des tampons de plus grande taille dans des clients Wayland spécifiques, tels que Xwayland, qui nécessitent une plus grande intensité d'événements d'entrée.
• Pour les requêtes (request), événements (event) et énumérations (enum), il est possible d'utiliser l'attribut XML « deprecated-since » pour marquer les éléments obsolètes. Dans la terminologie Wayland, les requêtes sont des messages envoyés par le client à serveur; les événements sont des messages envoyés du serveur au client ; les énumérations sont des ensembles de valeurs numériques associées à un nom spécifique, que le protocole manipule.
• L'outil wayland-scanner, destiné à générer des fichiers d'en-tête et du code en C à partir de fichiers XML décrivant le protocole, a ajouté un mode « enum-header », qui inclut uniquement l'indication dans les fichiers d'en-tête des « énumérations ».
• Dans wayland-scanner, la génération de fonctions de validation (validator) pour les « énumérations » côté serveur a été assurée.
• La possibilité d'attribuer des noms aux files d'attente d'événements a été ajoutée pour faciliter le débogage.
• Les fonctions wl_client_get_user_data() et wl_client_set_user_data() ont été ajoutées, facilitant l'attachement de données arbitraires au client.
• La requête wl_shm.release a été ajoutée, permettant au client d'informer le serveur de la fin de l'utilisation de l'objet partagé, ce qui permet au serveur de libérer la mémoire y afférente.
• Ajout du support de la plateforme OpenBSD.

Les événements liés à Wayland qui se sont produits depuis la publication de la dernière version :

• Publication de XWayland 24.1.0 avec prise en charge de la technologie Explicit Sync et amélioration du support des architectures d'accélération 2D GLAMOR et EXA.
• Mise à jour du serveur composite labwc (Lab Wayland Compositor) avec des fonctionnalités ressemblant à celles du gestionnaire de fenêtres Openbox.
• Projet wprs développant pour Wayland un gestionnaire de sessions similaire à l'outil screen, mais pour les applications graphiques.
• Publication du serveur composite Niri, utilisant Wayland et offrant une méthode de composition en mosaïque (tiling) avec regroupement des fenêtres dans un défilement infini à l'écran.
• Mise à jour de l'ensemble de protocoles et d'extensions Wayland-Protocols : 1.34, 1.33, 1.32, 1.35.
• Développement de la bibliothèque SDL3, utilisant Wayland par défaut.
• Sortie de l'environnement de bureau LXQt 2.0.0 avec prise en charge de Wayland dans le gestionnaire de fichiers PCManFM-Qt, système de notifications, bureau, utilitaire de lancement de programmes (Runner), panneau, interface de déconnexion, interface de configuration LXQt et la plupart des applications.
• Publication de l'environnement utilisateur Sway 1.9 utilisant Wayland.
• Nouveau gestionnaire composite miracle-wm, basé sur Wayland et des composants pour la construction de gestionnaires composites Mir.
• Louvre — nouvelle bibliothèque pour le développement de gestionnaires composites serveurs basé sur Wayland.
• Travail sur la mise en œuvre de la prise en charge de Wayland dans Xfce.
• Prise en charge initiale de Wayland dans l'environnement de bureau Budgie.
• Prise en charge initiale de Wayland dans l'environnement de bureau Cinnamon.
• Le portage de l'environnement de bureau MATE pour Wayland est presque terminé.
• La distribution Lubuntu passe à l'utilisation de Qt 6 et de Wayland.
• Dans KDE 6, une session utilisant le protocole Wayland est proposée par défaut. Prise en charge des extensions Wayland pour la gestion des couleurs.
• Le mode de décoration des fenêtres pour Wayland est inclus dans la plateforme Electron.
• Mise à jour du serveur composite Wayfire, utilisant Wayland et permettant la création d'interfaces utilisateur avec des effets 3D dans le style des plugins 3D à Compiz.
• Prise en charge de Wayland dans les IDE IntelliJ et OpenJDK.
• Prise en charge de Wayland dans l'éditeur de texte GNU Emacs.
• Dans GNOME, une session basée sur Wayland dispose d'un support pour le commutateur KVM logiciel Input Leap, permettant d'utiliser un clavier et une souris pour contrôler plusieurs ordinateurs.
• La version de Fedora avec l'environnement de bureau KDE a cessé de supporter la session basée sur le protocole X11 dans la distribution de base.
• Amélioration de la prise en charge des environnements basés sur Wayland dans les pilotes propriétaires NVIDIA.
• Un pilote a été mis en œuvre, permettant d'utiliser Wine dans des environnements basés sur le protocole Wayland sans recourir à XWayland et aux composants X11.
• Une version du serveur composite Weston 13.0 a été formée.
• Pour tester le fonctionnement de KDE, GNOME, Enlightenment, Wayfire, Mir, Xfce et Sway sur Wayland, un Live CD spécial appelé Rebecca Black Linux est publié.
• Dans les versions Linux de Firefox, l'utilisation du serveur composite Wayland est activée par défaut au lieu de XWayland. Il est désormais possible de créer des versions qui ne supportent que Wayland.

Rappelons que Wayland est un protocole d'interaction entre un serveur de composition et les applications qui lui sont associées. Les clients réalisent eux-mêmes le rendu de leurs fenêtres dans un tampon séparé, transmettant des informations sur les mises à jour au serveur de composition, qui combine le contenu des tampons des différentes applications pour former la sortie finale, en tenant compte des subtilités possibles, telles que le chevauchement des fenêtres et la transparence. En d'autres termes, le serveur de composition ne fournit pas d'API pour le rendu d'éléments individuels, mais opère uniquement sur des fenêtres déjà formées, ce qui permet d'éviter le double buffering lors de l'utilisation de bibliothèques de haut niveau telles que GTK et Qt, qui prennent en charge la composition du contenu des fenêtres.

Wayland résout de nombreux problèmes de sécurité d'X11, car contrairement à ce dernier, il isole l'entrée et la sortie pour chaque fenêtre, empêchant un client d'accéder au contenu des fenêtres d'autres clients, et ne permet pas l'interception des événements d'entrée liés à d'autres fenêtres. Actuellement, le support d'un fonctionnement direct avec Wayland est déjà mis en œuvre pour les bibliothèques GTK, Qt, SDL (à partir de la version 2.0.2), Clutter et EFL (Enlightenment Foundation Library). À partir de Qt 5.4, un module nommé QtWayland a été inclus pour permettre le fonctionnement des applications Qt dans l'environnement du serveur composite Weston, développé par le projet Wayland.

L'interaction avec le matériel dans Wayland/Weston, par exemple, l'initialisation, le changement de modes vidéo (drm modesetting) et la gestion de la mémoire (GEM pour i915 et TTM pour radeon et nouveau) des cartes graphiques, peut être effectuée directement via un module fonctionnant au niveau du noyau, permettant d'éviter les privilèges d'utilisateur super. Le serveur composite Weston peut fonctionner non seulement en utilisant le module DRM du noyau Linux, mais aussi au-dessus de X11, d'un autre serveur composite Wayland, d'un framebuffer et du RDP. De plus, des projets sont en cours pour permettre le fonctionnement au-dessus de la pile graphique de la plateforme Android.

Dans le cadre du projet Weston, se développe l'une des réalisations d'un serveur composite. Tout autre produit prenant en charge le protocole Wayland peut également agir en tant que serveur composite. Par exemple, des travaux sont actuellement en cours pour assurer la prise en charge de Wayland dans KWin. Dans sa forme actuelle, Weston a déjà dépassé le cadre d'un ensemble d'exemples pour tester le protocole Wayland et peut s'enrichir de fonctionnalités via des plugins et des extensions. Les environnements utilisateurs et les fonctionnalités avancées de gestion des fenêtres sont proposés à être réalisés sous forme de backends externes pour Weston. Pour exécuter des applications X11 classiques dans un environnement basé sur Wayland, le composant DDX XWayland (Device-Dependent X) est utilisé, organisé de manière similaire à Xwin et Xquartz pour les plateformes Win32 et macOS.

Source : opennet.ru