Wayland et Qt
Wayland a été développé comme une alternative à X11 sur Linux. Son objectif principal est de gérer la façon dont le contenu des applications est affiché ensemble sur un écran partagé, et la façon dont un utilisateur peut interagir avec plusieurs applications partageant les mêmes périphériques d'entrée.
Ce rôle dans un système d'exploitation est souvent appelé serveur d'affichage. Le serveur d'affichage Wayland peut également être appelé compositeur et gestionnaire de fenêtres, en référence à des tâches spécifiques qu'il effectue dans le cadre de ses fonctions.
Dans ce qui suit, nous allons donner une brève introduction à Wayland et à son rôle dans Qt. Pour plus de détails et d'informations sur Wayland lui-même, reportez-vous à la documentation officielle.
Qu'est-ce qu'un serveur d'affichage ?
Le serveur d'affichage est la partie du système d'exploitation qui gère l'écran et les autres ressources partagées. Sur un système de bureau classique, vous pouvez avoir de nombreuses applications indépendantes qui tournent en même temps, chacune s'attendant à pouvoir afficher des graphiques à l'écran et à recevoir des données.
Le serveur d'affichage est un lien entre l'application et les ressources partagées telles que l'écran et les périphériques d'entrée. Un serveur d'affichage typique sur un système de bureau place le contenu de l'application dans des "fenêtres" rectangulaires distinctes, qui peuvent être déplacées et redimensionnées par l'utilisateur. Le serveur d'affichage s'assure que le contenu de l'application est affiché à la bonne position sur l'écran, que la fenêtre active reçoit les entrées du clavier, que les fenêtres qui se chevauchent sont dessinées dans le bon ordre, etc.
Sur d'autres types de systèmes, le serveur d'affichage peut être plus restrictif. Si l'écran est le tableau de bord d'une voiture ou le panneau de commande d'un chariot élévateur, par exemple, il n'est pas souhaitable de déplacer et de redimensionner les fenêtres. Au lieu de cela, chaque application peut être enfermée dans une zone prédéfinie de l'écran et recevoir des données provenant de dispositifs prédéfinis.
Quoi qu'il en soit, tant qu'il y a plusieurs processus isolés en concurrence pour les mêmes ressources, un serveur d'affichage est utile.
Le rôle de Wayland
Le nom Wayland peut faire référence à plusieurs éléments connexes :
- Un ensemble de protocoles de communication entre un serveur d'affichage et ses clients.
- Une bibliothèque écrite en C avec des fonctions pour la communication inter-processus, servant de base à la mise en œuvre de ces protocoles.
- Un langage basé sur XML pour étendre le protocole, ainsi qu'un outil pour générer du code de liaison en C à partir de ces extensions.
Qt fournit des implémentations pour le côté client et le côté serveur du protocole.
Les applications Qt normales peuvent être exécutées en tant que clients sur un serveur d'affichage Wayland en sélectionnant le plugin QPA "wayland" (c'est le plugin par défaut sur certains systèmes). Vous pouvez le faire en utilisant l'option -qpa wayland. En outre, le module Qt Wayland Compositor peut être utilisé pour développer le serveur d'affichage lui-même.
Qt dispose également d'une fonctionnalité de commodité permettant d'étendre facilement les protocoles Wayland avec de nouvelles interfaces.
Wayland et les autres technologies
Sur le bureau Linux, Wayland est une alternative à X11 et aux extensions associées. Il s'agit essentiellement d'un serveur d'affichage par composition, et le terme "compositeur" est souvent utilisé pour décrire le serveur Wayland. Cela signifie que les clients rendront le contenu dans un tampon hors écran, qui sera ensuite "composé" avec d'autres clients sur l'écran, permettant des effets de fenêtre tels que les ombres portées, la transparence, le flou de l'arrière-plan, et ainsi de suite.
Un principe de conception important des protocoles X11 d'origine est que le serveur d'affichage peut fonctionner sur un terminal léger doté uniquement d'un écran et de périphériques d'entrée. Ses clients s'exécutent alors sur des systèmes distants dotés d'une plus grande puissance de traitement et communiquent avec le serveur par le biais d'une connexion réseau.
En revanche, Wayland a été conçu en partant du constat que, dans les configurations modernes, le client et le serveur d'affichage fonctionnent généralement sur le même matériel. Les fonctions de calcul distribué, de stockage et de bureau à distance sont généralement gérées par d'autres mécanismes. L'intégration de ces fonctions dans le protocole permet de partager la mémoire graphique entre le client et le serveur : Lorsque le compositeur place le contenu du client à l'écran, il peut simplement le copier d'une partie de la mémoire graphique à une autre.
Pour que cela fonctionne de manière optimale, le pilote graphique doit prendre en charge Wayland. Cette prise en charge est assurée par une extension de EGL appelée EXT_platform_wayland.
Remarque : Qt Wayland prend également en charge le compositing sur les systèmes où EXT_platform_wayland n'est pas pris en charge, soit par le biais de XComposite, soit en copiant le contenu de l'application dans la mémoire partagée de l'unité centrale. Mais pour des performances optimales, nous recommandons des systèmes avec un support de pilote.
X11 a été étendu pour prendre en charge des fonctionnalités telles que la composition et le rendu direct, mais Wayland a été conçu dès le départ autour de ce cas d'utilisation. Il vise également à être petit et extensible, contrairement à la complexité qui s'est développée dans X11 au fil du temps.
Extensibilité et systèmes embarqués
Wayland ayant un noyau minimal et étant facilement extensible, c'est un outil idéal pour la construction de plates-formes Linux embarquées.
Les fonctionnalités du système de fenêtres de type bureau, par exemple, ne font pas partie du protocole de base. Au lieu de cela, Wayland dispose d'une catégorie spéciale d'extensions de protocole appelées "shells" qui permettent au client de gérer ses surfaces. Les fonctions de type bureau sont fournies par un shell appelé XDG Shell. Pour d'autres types de systèmes, un "shell" plus spécialisé (et peut-être plus restrictif) peut être utilisé. Par exemple, pour les systèmes In-Vehicle Infotainment, il est préférable d'utiliser IVI Shell.
Le serveur Wayland diffuse une liste de ses protocoles supportés (ou "interfaces") lorsqu'un client se connecte, et le client peut se lier à ceux qu'il souhaite utiliser. Il peut s'agir de n'importe quelle interface standard, mais il est également facile d'ajouter de nouvelles extensions. Wayland définit un format XML facilement compréhensible pour définir les protocoles et l'outil waylandscanner peut être utilisé pour générer du code C à partir de ceux-ci. (Dans Qt, nous avons également qtwaylandscanner qui génère un code de liaison C++ supplémentaire).
Une fois qu'un client s'est lié à une interface, il peut adresser des "demandes" au serveur et le serveur peut envoyer des "événements" au client. Les requêtes et les événements, ainsi que leurs arguments, sont définis dans le fichier XML décrivant le protocole.
Pour la création d'une plateforme à partir de zéro, lorsque vous contrôlez le code du serveur et des clients, l'ajout d'extensions est un moyen facile et contrôlé d'ajouter des fonctionnalités au système d'exploitation.
Multi-processus ou mono-processus
Lors de la construction d'une plateforme embarquée simple avec Qt, une option parfaitement viable consiste à faire fonctionner toutes les parties de l'interface utilisateur dans un seul processus. Cependant, lorsque le système devient plus complexe, vous pouvez envisager un système multi-processus. C'est là que Wayland entre en jeu. Avec Qt, à tout moment de votre processus de développement, vous pouvez choisir de basculer entre un processus unique et un processus multiple.
Avantages du multi-processus
Les diagrammes suivants illustrent la différence entre les systèmes multi-processus et les systèmes mono-processus.
Architecture client multi-processus
Architecture client à processus unique
Le module Qt Wayland Compositor est idéal pour créer le serveur d'affichage et le compositeur dans les systèmes multiprocessus sous Linux embarqué. L'utilisation du multi-processus présente les avantages suivants :
| Stabilité | |
|---|---|
| Reprise plus facile en cas de blocage ou de panne d'un client | Si vous avez une interface utilisateur complexe, le multiprocessus est utile car si une partie de l'interface tombe en panne, cela n'affecte pas l'ensemble du système. De même, l'affichage ne se fige pas, même si un client se bloque. Remarque : si votre client est tenu par la loi d'afficher des informations critiques pour la sécurité, envisagez d'utiliser Qt Safe Renderer Overview. |
| Protection contre d'éventuelles fuites de mémoire | Dans un système multiprocessus, si un client a une fuite de mémoire et consomme beaucoup de mémoire, cette mémoire est récupérée lorsque ce client quitte le système. Contrairement à ce qui se passe dans un système monoprocessus, la fuite de mémoire persiste jusqu'au redémarrage de l'ensemble du système. |
| Sécurité |
|---|
| Dans un système monoprocessus, tous les clients peuvent accéder à la mémoire des autres. Par exemple, il n'y a pas d'isolation pour le transfert de données sensibles ; chaque ligne de code doit être également digne de confiance. Cette isolation existe, par conception, dans les systèmes multiprocessus. |
| Performances |
|---|
| Si vous disposez d'une unité centrale dotée de plusieurs cœurs, un système multiprocessus peut vous aider à répartir la charge de manière égale entre les différents cœurs, ce qui vous permet d'utiliser votre unité centrale de manière plus efficace. |
| Interopérabilité |
|---|
| Vous pouvez vous interfacer avec des clients non-Qt dans un système multi-processus, tant que vos clients comprennent Wayland Client ou X11. Par exemple, si vous utilisez gstreamer pour la vidéo ou si vous voulez utiliser une application de navigation construite avec une autre boîte à outils d'interface utilisateur, vous pouvez exécuter ces clients en même temps que vos autres clients basés sur Qt. |
Compromis du multi-processus
Lorsque l'on passe d'un système mono-processus à un système multi-processus, il est important d'être conscient des compromis suivants :
- Augmentation de la consommation de mémoire vidéo
- Augmentation de la consommation de la mémoire principale
- Stockage répété des ressources graphiques
- Latence d'entrée
| Augmentation de la consommation de mémoire vidéo |
|---|
| Cela peut être une contrainte pour les appareils embarqués. En multiprocessus, chaque client doit disposer de sa propre mémoire tampon graphique, qu'il envoie au compositeur. Par conséquent, vous utilisez plus de mémoire vidéo que dans le cas d'un processus unique, où tout est dessiné en même temps et où il n'est pas nécessaire de stocker les différentes parties dans des tampons intermédiaires. |
| Consommation accrue de la mémoire principale |
|---|
| Outre quelques frais généraux supplémentaires au niveau du système d'exploitation, l'exécution de plusieurs clients peut également entraîner une augmentation de la consommation de mémoire principale, car certaines parties doivent être dupliquées une fois par client. Par exemple, si vous utilisez QML, chaque client a besoin d'un moteur QML distinct. Par conséquent, si vous exécutez un seul client qui utilise Qt Quick Controls, il n'est chargé qu'une seule fois. Si vous divisez ensuite ce client en plusieurs clients, vous chargez Qt Quick Controls plusieurs fois, ce qui entraîne un coût de démarrage plus élevé pour initialiser vos clients. |
| Stockage répété des ressources graphiques |
|---|
| Dans un système à processus unique, si vous utilisez les mêmes textures, arrière-plans ou icônes à plusieurs endroits, ces images ne sont stockées qu'une seule fois. En revanche, si vous utilisez ces images dans un système multiprocessus, vous devez les stocker plusieurs fois. Dans ce cas, une solution consiste à partager les ressources graphiques entre les clients. Qt permet déjà de partager des ressources d'images en mémoire principale entre processus sans impliquer Wayland. Le partage de textures GPU entre processus, en revanche, nécessite des solutions plus complexes. Avec Qt, de telles solutions peuvent être développées en tant que protocoles d'extension Wayland et avec QQuickImageProvider, par exemple. |
| Latence entre l'entrée et le photon |
|---|
| Sur un système monoprocessus, l'application accède directement à la mémoire tampon de la trame principale. Cela signifie que la latence entre les événements d'entrée et leur affichage à l'écran peut être minimisée dans une telle configuration. Sur un système multiprocessus, le contenu de l'application doit être mis en triple tampon pour s'assurer que le client ne dessine pas dans les tampons alors qu'ils sont simultanément lus par le serveur, ce qui provoquerait un déchirement. Cela signifie qu'il existe une latence implicite dans un système multiprocessus. |
Pourquoi utiliser Wayland plutôt que X11 ou des solutions personnalisées ?
Comme décrit précédemment, X11 n'est pas une solution optimale pour les systèmes typiques d'aujourd'hui. Il est assez volumineux et complexe, et manque de possibilités de personnalisation. En fait, il est difficile de faire fonctionner un client de manière fluide avec X11, et d'atteindre 60 fps sans déchirure. Wayland, en revanche, est plus facile à mettre en œuvre, offre de meilleures performances et contient tous les éléments nécessaires pour fonctionner efficacement sur du matériel graphique moderne. Pour les systèmes embarqués et multiprocessus sous Linux, Wayland est la norme.
Cependant, si vous travaillez avec du matériel ancien ou des applications anciennes, Wayland n'est peut-être pas une bonne option. Le protocole Wayland est conçu dans un souci de sécurité et d'isolation, et il est strict/conservateur quant aux informations et fonctionnalités mises à la disposition des clients. Bien que cela conduise à une interface plus propre et plus sûre, certaines fonctionnalités attendues par les applications anciennes peuvent ne plus être disponibles sur Wayland.
En particulier, il existe trois cas d'utilisation courants pour lesquels Wayland n'est peut-être pas la meilleure option :
- Le matériel ou la plateforme est ancien et ne supporte que X11 ; dans ce cas, vous n'avez pas le choix.
- Vous devez supporter des applications anciennes qui dépendent de fonctionnalités absentes du protocole Wayland pour des raisons de sécurité et de simplicité.
- Vous devez supporter des applications anciennes qui utilisent une boîte à outils d'interface utilisateur qui ne fonctionne pas du tout sur Wayland. Dans certains cas, vous pouvez contourner ce problème en exécutant ces applications sur XWayland à la place.
À l'époque où X11 était très populaire, les développeurs écrivaient leurs propres solutions personnalisées pour contourner les problèmes liés à X11. Les anciennes versions de Qt disposaient du système de fenêtrage Qt (QWS), qui n'est plus utilisé aujourd'hui. Aujourd'hui, la plupart de ces cas d'utilisation sont couverts par Wayland, et les solutions personnalisées sont de moins en moins courantes.
Ce que Qt Wayland offre
Pour les clients
Les clients Qt peuvent fonctionner sur n'importe quel compositeur Wayland, y compris Weston, le compositeur de référence développé dans le cadre du projet Wayland.
Tout programme Qt peut s'exécuter en tant que client Wayland (dans le cadre d'un système multi-processus) ou en tant que client autonome (mono-processus). Ceci est déterminé au démarrage, où vous pouvez choisir entre les différents backends. Au cours du processus de développement, vous pouvez d'abord développer le client sur le bureau, puis le tester plus tard sur le matériel cible. Vous n'avez pas besoin d'exécuter vos clients sur le matériel cible en permanence.
Développement de clients mono-processus
Si vous développez sur une machine Linux, vous pouvez également exécuter le compositeur dans une fenêtre sur votre machine de développement. Cela vous permet d'exécuter des clients dans un environnement très proche du matériel cible. Sans reconstruire le client, vous pouvez également l'exécuter avec -platform wayland pour l'exécuter à l'intérieur du compositeur. Si vous utilisez -platform xcb (pour X11), vous pouvez exécuter le client sur le bureau. En d'autres termes, vous pouvez commencer à développer vos clients avant que le compositeur ne soit prêt à être utilisé.
Pour les serveurs
Le serveur, ou compositeur, se connecte à l'écran et affiche le contenu de chaque client à l'écran. Le compositeur gère les entrées et envoie les événements d'entrée au client correspondant. À son tour, chaque client se connecte au compositeur et envoie le contenu de ses fenêtres. C'est au compositeur de décider :
- comment et où afficher le contenu
- Quel contenu afficher
- Que faire des différents tampons graphiques des clients ?
En d'autres termes, c'est au compositeur de décider ce qu'est un système multiprocessus. Par exemple, les clients peuvent faire partie d'une scène 3D avec des fenêtres sur les murs, sur un système VR, mappé sur une sphère, etc.
L'API Qt Wayland Compositor est une API pour construire votre propre compositeur. Elle vous donne toute liberté pour créer une interface utilisateur de compositeur personnalisée et gérer les fenêtres des différents clients. Vous pouvez combiner Qt Quick et QML avec Qt Wayland Compositor pour créer des interfaces impressionnantes et imaginatives. Pour plus d'informations, voir Qt Wayland Compositor.
Qt fournit également des API puissantes et conviviales pour mettre en œuvre les extensions Wayland et les utiliser à partir de QML ou de C++.
Contenu connexe
© 2026 The Qt Company Ltd. Documentation contributions included herein are the copyrights of their respective owners. The documentation provided herein is licensed under the terms of the GNU Free Documentation License version 1.3 as published by the Free Software Foundation. Qt and respective logos are trademarks of The Qt Company Ltd. in Finland and/or other countries worldwide. All other trademarks are property of their respective owners.
