Wayland et Qt
Wayland a été développé comme alternative à X11 sous Linux. Son objectif principal est de gérer l'affichage conjoint du contenu des applications sur un écran partagé, ainsi que la manière dont un utilisateur peut interagir avec plusieurs applications partageant les mêmes périphériques d'entrée.
Ce rôle au sein d'un système d'exploitation est souvent appelé « serveur d'affichage ». Le serveur d'affichage Wayland peut également parfois être qualifié de « compositeur » ou de « gestionnaire de fenêtres », en référence aux tâches spécifiques qu'il effectue dans le cadre de ses fonctions.
Dans ce qui suit, nous présenterons brièvement Wayland et son rôle dans Qt. Pour plus de détails et d'informations générales sur Wayland, veuillez vous reporter à 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'espace d'affichage et les autres ressources partagées. Sur un système de bureau classique, de nombreuses applications indépendantes peuvent s'exécuter simultanément, chacune devant pouvoir afficher des éléments graphiques à l'écran et recevoir des entrées.
Le serveur d'affichage fait le lien entre les applications et les ressources partagées, telles que l'écran et les périphériques d'entrée. Sur un système de bureau classique, un serveur d'affichage place le contenu des applications dans des « fenêtres » rectangulaires distinctes, que l'utilisateur peut déplacer et redimensionner. Le serveur d'affichage veille à ce que le contenu des applications s'affiche à la bonne position à l'écran, à ce que la fenêtre active reçoive les entrées du clavier, à ce que les fenêtres qui se chevauchent s'affichent dans le bon ordre, etc.
Sur d’autres types de systèmes, le serveur d’affichage peut être plus restrictif. Si l’écran est, par exemple, un tableau de bord dans une voiture ou le panneau de commande d’un chariot élévateur, le déplacement et le redimensionnement des fenêtres peuvent ne pas être souhaitables. Au lieu de cela, chaque application peut être verrouillée dans une zone prédéfinie de l’écran et recevoir les entrées provenant de périphériques pré-attribués.
Quoi qu’il en soit, tant qu’il existe plusieurs processus isolés en concurrence pour les mêmes ressources, un serveur d’affichage s’avère utile.
Le rôle de Wayland
Le nom « Wayland » peut désigner plusieurs éléments liés :
- Un ensemble de protocoles permettant la communication entre un serveur d'affichage et ses clients.
- Une bibliothèque écrite en C contenant des fonctions de communication interprocessus, qui sert de base à la mise en œuvre desdits protocoles.
- Un langage basé sur XML permettant d'étendre le protocole, ainsi qu'un outil permettant de générer du code de liaison en C à partir de ces extensions.
Qt fournit des implémentations tant pour le côté client que pour le côté serveur du protocole.
Les applications Qt classiques 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 choix par défaut sur certains systèmes). Pour ce faire, utilisez l'option -qpa wayland. De plus, le Qt Wayland Compositor module peut être utilisé pour développer le serveur d’affichage lui-même.
Qt propose également des fonctionnalités pratiques permettant d’étendre facilement les protocoles Wayland avec de nouvelles interfaces.
Wayland et autres technologies
Sur le bureau Linux, Wayland constitue une alternative à X11 et à ses extensions. Il s’agit essentiellement d’un serveur d’affichage de type « compositeur », et le terme « compositeur » est souvent utilisé pour décrire le serveur Wayland. Cela signifie que les clients effectuent le rendu du contenu dans un tampon hors écran, qui sera ensuite « composité » avec celui des autres clients à l'écran, ce qui permet d'obtenir des effets de fenêtre tels que les ombres portées, la transparence, le flou d'arrière-plan, etc.
L'un des principes de conception importants des protocoles X11 d'origine est que le serveur d'affichage peut fonctionner sur un terminal léger ne disposant que d'un écran et de périphériques d'entrée. Ses clients s'exécuteraient alors sur des systèmes distants dotés d'une plus grande puissance de calcul, communiquant avec le serveur via une connexion réseau.
À l’inverse, Wayland est conçu en partant du constat que, dans les configurations modernes, le client et le serveur d’affichage s’exécutent généralement sur le même matériel. Le calcul distribué, le stockage à distance et les fonctionnalités de bureau à distance sont généralement gérés par d’autres mécanismes. Intégrer cette conception dans le protocole permet le partage de la mémoire graphique entre le client et le serveur : lorsque le compositeur affiche 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 l’interface « EGL », appelée « EXT_platform_wayland ».
Remarque : Qt Wayland prend également en charge la composition sur les systèmes où l'EXT_platform_wayland n'est pas pris en charge, soit via XComposite, soit en copiant le contenu de l'application dans la mémoire partagée du processeur. Toutefois, pour des performances optimales, nous recommandons d'utiliser des systèmes disposant d'un pilote compatible.
X11 a été étendu pour prendre en charge des fonctionnalités telles que la composition et le rendu direct, mais Wayland est conçu dès le départ pour ce cas d’utilisation. Il vise également à être léger et extensible, contrairement à la complexité qui s’est développée au fil du temps dans X11.
Extensibilité et systèmes embarqués
Comme Wayland dispose d'un noyau minimal et est facilement extensible, il constitue un outil idéal pour le développement de plateformes Linux embarquées.
Les fonctionnalités propres aux systèmes de fenêtrage de type bureau, par exemple, ne font pas partie du protocole de base. À la place, Wayland dispose d’une catégorie spécifique d’extensions de protocole appelées « shells », qui permettent au client de gérer ses surfaces. Les fonctionnalités 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, lors de la création de systèmes de type « In-Vehicle Infotainment », le IVI Shell pourrait être préférable.
Le serveur Wayland diffuse une liste des protocoles (ou « interfaces ») qu’il prend en charge 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 facile à comprendre pour la définition des protocoles, et l’outil waylandscanner permet de générer du code C à partir de ceux-ci. (Dans Qt, nous disposons également d’ qtwaylandscanner, qui génère du code de liaison C++ supplémentaire.)
Une fois qu’un client s’est lié à une interface, il peut envoyer des « requêtes » au serveur et ce dernier 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 créer une plateforme à partir de zéro, lorsque vous maîtrisez le code du serveur et des clients, l’ajout d’extensions constitue un moyen simple et maîtrisé d’intégrer des fonctionnalités au système d’exploitation.
Multiprocessus ou monoprocessus
Lors de la création d’une plateforme embarquée simple avec Qt, une option tout à fait viable consiste à faire fonctionner toutes les parties de l’interface utilisateur dans un seul processus. Cependant, à mesure que le système gagne en complexité, vous pouvez envisager de passer à un système multiprocessus. C’est là que Wayland entre en jeu. Avec Qt, à n’importe quel stade de votre processus de développement, vous pouvez choisir de basculer d’un mode mono-processus à un mode multi-processus.
Avantages du mode multiprocessus
Les schémas suivants illustrent la différence entre les systèmes multiprocessus et les systèmes à processus unique.
Architecture client multiprocessus
Architecture client à processus unique
Le Qt Wayland Compositor module est idéal pour créer le serveur d'affichage et le compositeur dans des systèmes multiprocessus sous Linux embarqué. L'utilisation d'une architecture multiprocessus présente les avantages suivants :
| Stabilité | |
|---|---|
| Récupération plus facile en cas de blocage ou de plantage des clients | Si votre interface utilisateur est complexe, l'architecture multiprocessus s'avère utile, car si une partie de l'interface plante, cela n'affecte pas l'ensemble du système. De même, l'affichage ne se fige pas, même lorsqu'un client se bloque. Remarque : si votre client est légalement tenu d’afficher des informations critiques pour la sécurité, envisagez d’utiliser Qt Safe Renderer. |
| Protection contre d’éventuelles fuites de mémoire | Dans un système multiprocessus, si un client présente une fuite de mémoire et consomme beaucoup de mémoire, celle-ci est récupérée lorsque ce client se ferme. Contrairement à un système monoprocessus, la fuite de mémoire persiste jusqu’au redémarrage complet du système. |
| Sécurité |
|---|
| Dans un système à processus unique, 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 tout aussi fiable. Cette isolation est intégrée, de par la conception même, dans les systèmes multiprocessus. |
| Performances |
|---|
| Si vous disposez d'un processeur à plusieurs cœurs, un système multiprocessus peut aider à répartir la charge de manière homogène entre les différents cœurs, ce qui permet une utilisation plus efficace de votre processeur. |
| Interopérabilité |
|---|
| Vous pouvez interagir avec des clients non Qt dans un système multiprocessus, à condition que vos clients prennent en charge Wayland ou X11. Par exemple, si vous utilisez GStreamer pour la vidéo ou si vous souhaitez utiliser une application de navigation développée avec une autre boîte à outils d'interface utilisateur, vous pouvez exécuter ces clients parallèlement à vos autres clients basés sur Qt. |
Compromis liés à l'architecture multiprocessus
Lors du passage d'un système à processus unique à un système multiprocessus, il est important de garder à l'esprit les compromis suivants :
- Augmentation de la consommation de mémoire vidéo
- Augmentation de la consommation de 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 constituer une contrainte pour les appareils embarqués. En mode multiprocessus, chaque client doit disposer de son propre tampon graphique, qu’il envoie au compositeur. Par conséquent, vous utilisez davantage de mémoire vidéo qu’en mode monoprocessus : dans ce dernier cas, tout est dessiné en une seule fois et il n’est pas nécessaire de stocker les différentes parties dans des tampons intermédiaires. |
| Consommation accrue de mémoire principale |
|---|
| Outre une surcharge supplémentaire au niveau du système d’exploitation, l’exécution de plusieurs clients peut également nécessiter davantage de mémoire principale, car certaines parties doivent être dupliquées une fois par client. Par exemple, si vous exécutez QML, chaque client nécessite un moteur QML distinct. Par conséquent, si vous exécutez un seul client utilisant Qt Quick Controls, celui-ci 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 les processus sans faire appel à Wayland. Le partage de textures GPU entre les processus nécessite en revanche des solutions plus complexes. Avec Qt, de telles solutions peuvent être développées sous forme de protocoles d’extension Wayland et à l’aide d’ QQuickImageProvider, par exemple. |
| Latence entre l’entrée et le photon |
|---|
| Sur un système à processus unique, l’application accède directement au tampon de trame principal. 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 faire l’objet d’un triple tampon afin de garantir que le client ne dessine pas dans les tampons alors que ceux-ci sont simultanément lus par le serveur, ce qui provoquerait un déchirement de l’image. Il en résulte donc 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 la solution optimale pour les configurations système courantes d’aujourd’hui. Il est assez volumineux et complexe, et manque de possibilités de personnalisation. En effet, il est difficile de faire fonctionner un client de manière fluide avec X11 et d’atteindre 60 images par seconde sans déchirement d’image. 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 le matériel graphique moderne. Pour les systèmes embarqués multiprocessus sous Linux, Wayland est la norme.
Cependant, si vous travaillez avec du matériel ancien ou des applications héritées, Wayland n’est peut-être pas la meilleure option. Le protocole Wayland est conçu dans un souci de sécurité et d’isolation, et se montre strict et conservateur quant aux informations et fonctionnalités mises à la disposition des clients. Bien que cela se traduise par une interface plus épurée et plus sécurisée, certaines fonctionnalités attendues par les applications héritées peuvent ne plus être disponibles sous Wayland.
Il existe notamment trois cas d’utilisation courants dans lesquels Wayland n’est peut-être pas la meilleure option :
- Le matériel ou la plateforme est ancien(ne) et ne prend en charge que X11 ; dans ce cas, vous n'avez pas le choix.
- Vous devez prendre en charge des applications héritées qui dépendent de fonctionnalités absentes du protocole Wayland pour des raisons de sécurité et de simplicité.
- Vous devez prendre en charge des applications héritées qui utilisent une boîte à outils d'interface utilisateur ne fonctionnant absolument pas sous 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 Qt Windowing System (QWS), qui n’est plus pris en charge aujourd’hui. Aujourd’hui, la plupart de ces cas d’utilisation sont pris en charge par Wayland, et les solutions personnalisées sont de moins en moins courantes.
Ce qu’offre Qt Wayland
Pour les clients
Les clients Qt peuvent s'exécuter 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 multiprocessus) ou en tant que client autonome (monoprocessus). Ce choix 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 votre bureau, puis le tester ultérieurement sur le matériel cible. Il n’est pas nécessaire d’exécuter vos clients en permanence sur le matériel cible réel.
Développement de clients à processus unique
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 les clients dans un environnement très proche de celui du périphérique cible. Sans avoir à recompiler le client, vous pouvez également l’exécuter avec l’option ` -platform wayland ` pour le faire fonctionner au sein 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 même que le compositeur ne soit prêt à l'emploi.
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 lui 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
Cela signifie que c'est au compositeur de décider ce qu'est un système multiprocessus. Par exemple, les clients pourraient faire partie d'une scène 3D avec des fenêtres sur les murs, sur un système de réalité virtuelle, mappés sur une sphère, etc.
L' Qt Wayland Compositor existe une API permettant de créer votre propre compositeur. Elle vous offre une liberté totale pour développer une interface utilisateur personnalisée et gérer les fenêtres des différents clients. Vous pouvez combiner à la fois Qt Quick et QML avec l’ Qt Wayland Compositor pour créer des interfaces utilisateur impressionnantes et imaginatives. Pour plus d’informations, consultez Qt Wayland Compositor.
Qt fournit également des API puissantes et conviviales pour implémenter des extensions Wayland et les utiliser depuis QML ou C++.
Contenu associé
© 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.
