Le développement d’un compositeur Wayland est une aventure passionnante qui permet de créer des interfaces graphiques performantes et modernes.
Wayland, en tant que protocole entre application (client) et compositeur (serveur d’affichage), promet de surmonter les limitations de son prédécesseur, X11.
Qt, de son côté, se distingue comme un framework puissant pour créer des environnements utilisateurs riches et interactifs, offrant une intégration fluide avec Wayland.
Pour tirer pleinement parti de ces technologies, il est utile de connaître les concepts clés, les bases du protocole Wayland, xdg et IVI, et de comprendre leurs différences. Rappelons un peu...
Le protocole Wayland :
Wayland est un protocole destiné à gérer l’affichage graphique. Il permet aux applications de communiquer avec un serveur d’affichage afin de se rendre visibles à l’écran.
Dans ce contexte :
le serveur d’affichage est appelé un compositeur
les applications qui utilisent ce protocole sont les clients Wayland.
Le compositeur reçoit les instructions des applications, comme les demandes pour dessiner des fenêtres ou afficher du contenu, et se charge de composer ces éléments graphiques.
Il sert :
à créer les fenêtres des applications,
à les gérer,
à les organiser
et à les détruire lorsqu’elles ne sont plus nécessaires.
Dans Wayland, la communication entre le compositeur et les applications se fait par le biais de la communication inter-processus ( IPC ) en établissant une connexion via la socket Wayland qui est configurée par la variable d'environnement “WAYLAND_DISPLAY".
À la demande du client, le compositeur alloue une mémoire partagée pour créer et modifier les surfaces graphiques. Ces surfaces représentent les données graphiques du client, soit les éléments visuels que les applications souhaitent afficher à l’écran.
Une fois les modifications effectuées, le compositeur compose l’image finale à afficher à l’écran. Pour aller plus loin, je vous invite à lire l’article de blog vulgarisant les concepts de Wayland.
Pour compléter Wayland, des protocoles comme xdg-shell et IVI ajoutent des fonctionnalités spécifiques à la gestion de l’affichage graphique. Par exemple, ils permettent de contrôler le dimensionnement, le positionnement ou encore la fermeture des fenêtres.
Le client Wayland fournit des données graphiques via la mémoire partagée. En parallèle, il utilise les protocoles xdg-shell ou IVI pour indiquer au compositeur comment ces données doivent être présentées (état des fenêtres, taille, position, etc.). Le compositeur combine ensuite ces informations pour afficher le résultat final à l'écran.
Pourquoi utiliser Qt pour le développement d’un compositeur Wayland?
Qt intègre nativement le support Wayland et permet de créer des applications graphiques modernes s'exécutant de manière optimale sur cette architecture.
Il simplifie la gestion des événements grâce à ses mécanismes robustes et à sa documentation détaillée.
Qt offre une gamme complète de sous-protocoles pour la gestion des interfaces graphiques sous Wayland, facilitant ainsi la manipulation des surfaces graphiques et des interactions.
En développant un compositeur Wayland sous Qt, les développeurs peuvent profiter de la puissance de Qt pour créer des environnements graphiques performants, que ce soit pour des applications de bureau en utilisant le protocole XDG ou des systèmes embarqués grâce au protocole IVI.
Les protocoles XDG-shell et IVI :
Dans le monde des compositeurs, les protocoles xdg-shell et IVI jouent des rôles essentiels pour assurer une interaction fluide et cohérente entre les applications et les utilisateurs. Ils viennent en surcouche au protocole Wayland pour apporter des fonctionnalités plus spécifiques que la simple gestion des surfaces.
Le protocole Wayland définit des objets de base (wlsurface) qui regroupent, entre autre, la position, la taille et une référence à la mémoire partagée. Ici, les objets des protocoles xdg-shell et IVI viennent hériter de ces objets pour y ajouter des informations et des fonctionnalités.
IVI (In-vehicle infotainment) :
IVI est une extension du protocole Wayland qui permet de gérer simplement les interactions entre les applications et les systèmes embarqués.
Par exemple, dans des véhicules, le compositeur IVI laisse le champ libre à l'application d'interagir avec l'utilisateur en optimisant l'espace à l’écran. L’affichage des cartes de navigation, des médias, des notifications du véhicule, ou autres alertes sont à la charge de l'application.
Il offre des fonctionnalités minimales particulièrement adaptées aux systèmes d’info-divertissement embarqués et permet aux développeurs du compositeur de se focaliser sur l'aspect.
Gestion des surfaces IVI:
Les développeurs utilisent le protocole IVI pour créer, gérer et contrôler les surfaces spécifiques aux environnements IVI. Ces surfaces sont conçues pour répondre aux caractéristiques propres aux systèmes embarqués, comme la gestion simultanée de plusieurs zones d'affichage ou l'adaptation à des écrans de formes variées.
La classe Qt ‘QWaylandIviApplication’ fournit les outils nécessaires pour la création des surfaces IVI. Lorsqu’une surface est créée, elle est associée à un identifiant unique, permettant au compositeur de gérer ces surfaces efficacement. Cet identifiant est important pour distinguer les différentes surfaces dans un environnement où plusieurs applications peuvent interagir simultanément.
Création d’une surface IVI :
Gestion de la surface :
Positionnement et redimensionnement :
Le protocole permet de définir des propriétés telles que la position et la taille des surfaces IVI, c’est-à-dire la possibilité au développeur de placer des applications à des endroits spécifiques de l'écran et de les redimensionner à la taille souhaitée.
Par exemple, dans un tableau de bord de véhicule affichant plusieurs applications simultanément, lorsque le conducteur utilise l’application GPS, celle-ci est positionnée au centre de l'écran pour une visibilité optimale. En parallèle, les autres applications (musique, appels, etc.) sont déplacées vers un coin de l'écran. Cela permet au développeur du compositeur d’optimiser la disposition des informations.
Les surfaces IVI peuvent être redimensionnées en fonction de l'aspect voulu ou des besoins de l’application pour s’adapter parfaitement aux dimensions spécifiques des écrans. Par exemple, une application vidéo peut passer en mode plein écran lors de sa lecture.
La classe Qt utilisée pour redimensionner et positionner ces applications est appelée QWaylandIviSurface. Elle utilise la fonction sendConfigure() pour envoyer les paramètres de configuration nécessaires à la mise à jour des surfaces.
Par exemple, lorsque l’on souhaite modifier la taille d’une application, la fonction sendConfigure() est appelée en envoyant les nouvelles coordonnées de la surface via la socket Wayland. L’application reçoit un événement de configuration contenant la nouvelle position. Par la suite, un message est envoyé au compositeur pour signaler cette modification, permettant de mettre à jour la vue à afficher.
Intégration embarqué :
Le protocole IVI facilite l'intégration de différents systèmes de contrôle embarqués par sa simplicité. Il fournit des fonctions basiques, laissant le développeur libre pour développer l'interaction entre l'utilisateur et les applications. Il n'est cependant pas prévu pour interagir de façon riche à l'aide d'un clavier ou d'un dispositif de pointage, il prouve en revanche sa grande utilité accompagné d'un écran tactile ou de boutons.
Documentation de l'API : https://wayland.app/protocols/ivi-application
XDG-shell (Cross Desktop Group) :
XDG-shell est une extension du protocole Wayland, conçue pour enrichir significativement les interactions des applications graphiques et faciliter la gestion dynamique des fenêtres. Il offre des fonctionnalités qui sont particulièrement adaptées aux environnements de bureau, c’est-à-dire les interfaces graphiques que l’on retrouve dans les systèmes d’exploitation traditionnels, utilisant usuellement le clavier et la souris. Il est notamment implémenté dans les environnements modernes Linux (gnome, sway et consorts)
Pour créer et gérer des surfaces (fenêtres graphiques) avec le protocole XDG-shell, on utilise des objets spécifiques.
Les objets XDG :
Chaque objet XDG a un rôle bien défini. En voici quelques-uns :
xdg_surface : cet objet représente une première surcouche aux wlsurface du protocole de base, fournissant le cadre élargi sur lequel reposent des surfaces plus spécifiques, comme des xdg_toplevel et xdg_popup.
xdg_toplevel : cet objet hérite de xdg_surface et représente une surface de niveau supérieur, agissant comme la fenêtre principale d’une application.
xdg_popup : cet objet hérite également de xdg_surface et représente une surface temporaire comme un menu contextuel ou une boîte de dialogue qui apparaissent en réponse à une action de l’utilisateur, mais également dans des situations internes de l’application, comme l’affichage d’alerte dans une interface.
xdg_positioner : cet objet est utilisé pour spécifier la position des pop-ups par rapport à leur surface parent.
Ces surfaces proposent une notion de parenté, c'est à dire qu'une surface top_level peut avoir des sous surfaces pour s'organiser en applications.
Dans le cadre de l'intégration de Wayland, Qt propose des classes spécifiques permettant une interaction avec le protocole XDG-shell que vous pouvez retrouver ici.
Gestion des surfaces :
Le protocole XDG-shell fournit une API standardisée pour la création et la gestion efficace des fenêtres.
La classe Qt ‘QWaylandXdgShell’ offre l’infrastructure nécessaire pour gérer les surfaces XDG, en prenant en charge les événements qui leur sont liés.
Parmi les éléments essentiels de ce protocole, on trouve ‘xdg_surface’ qui joue un rôle important en servant de base pour les fenêtres des applications sur lesquelles sont construites les interactions graphiques.
Dans l’environnement Qt, la classe ‘QWaylandXdgSurface’ est utilisée pour représenter et gérer ces surfaces. Cela fonctionne en créant d’abord une surface Wayland de base, puis en l'associant à une ‘QWaylandXdgSurface’. Cette association permet de gérer et d'interagir de manière conforme avec le protocole XDG-shell.
Afin de créer une fenêtre principale (i.e. une application standard), on utilise l’objet ‘xdg_toplevel’. Dans Qt, cet objet est représenté par la classe ‘QWaylandXdgToplevel’. Cette classe permet de créer efficacement ces surfaces et de gérer les propriétés ainsi que les événements spécifiques à une surface de niveau supérieur.
Positionnement et redimensionnement :
Le protocole XDG-shell dans Wayland permet le positionnement et le redimensionnement des surfaces via l’extension ‘xdg_toplevel’.
Lors de la création d’une surface, on peut définir initialement une taille spécifique. Cette surface est transformée en ‘xdg_toplevel’, et peut ensuite être redimensionnée et positionnée en réponse aux actions effectuées dans l’application.
Les ajustements de taille sont réalisés à l'aide de la fonction setSize(), qui permet de gérer les changements en temps réel.
Par exemple, lorsque l'on redimensionne la fenêtre en tirant ses bords, la classe ‘QWaylandXdgToplevel’ reçoit une demande de redimensionnement. Cette demande est transmise au compositeur via la méthode ‘xdg_toplevel_set_size()’, qui envoie les nouveaux paramètres de configuration à travers la socket Wayland.
Le compositeur traite ces informations, ajuste la surface, et les modifications de taille sont ensuite affichées en temps réel.
‘xdg_toplevel’ offre également d'autres opérations telles que la maximisation, où la fenêtre occupe l'intégralité de l'écran pour une visibilité optimale, et la minimisation, où la fenêtre est réduite à une icône pour libérer de l'espace sur l'écran.
Ces éléments offrent une gestion efficace des fenêtres et contribuent à une expérience fluide pour les interactions visuelles.
Gestion des pop-ups :
Dans l’environnement Wayland, le protocole XDG-shell inclut des mécanismes spécifiques pour la gestion des surfaces temporaires telles que les menus déroulants, les boîtes de dialogue et les infobulles à travers l’objet ‘xdg_popup’.
‘xdg_popup’ est utilisé pour afficher ces surfaces éphémères qui sont généralement créées en réponse à une action utilisateur.
Dans Qt , la gestion des pop-ups est assurée par la classe ‘QWaylandXdgPopup’, qui encapsule les fonctionnalités de l’objet ‘xdg_popup’.
Par exemple, lorsqu'on clique sur un bouton pour afficher un menu contextuel, une instance ‘QWaylandXdgPopup’ est créée et positionnée par rapport à la surface parent. Ces surfaces temporaires sont essentielles pour un contrôle et une gestion efficaces, permettant d’afficher des options supplémentaires sans perturber l’application principale.
L’objet ‘xdg_positioner’ quant à lui, permet de déterminer la position et les contraintes géométriques des surfaces temporaires.
Dans Qt, la gestion de ces aspects est assurée par la classe ‘QWaylandXdgPositioner’, qui encapsule les fonctionnalités de l'objet ‘xdg_positioner’ et qui permet de spécifier où le pop-up doit apparaître par rapport à la surface parent.
Lorsque l’on souhaite afficher un menu contextuel, la classe ‘QWaylandXdgPositioner’ est utilisée pour configurer les coordonnées du pop-up et enverra ces informations au compositeur, permettant au menu de s’afficher au bon endroit.
Intégration bureautique :
Le protocole XDG-shell propose plus de variétés de types que IVI, pour la raison qu'il ne cible pas les mêmes usages. Il est prévu pour être multi-tâches et permet un hiérarchisation des fenêtres par application. Son intégration au développement d'un compositeur est plus fastidieuse, mais sera plus confortable à l'usage sur un ordinateur.
Documentation de l'API : https://wayland.app/protocols/xdg-shell
Différences entre les protocoles IVI et xdg-shell :
IVI :
- Adapté aux systèmes d’info-divertissement embarqués
- Intégration avec les systèmes embarqués
- Léger et flexible pour répondre à des exigences spécifiques des développeurs
- Interactions utilisateur rapides à développer et minimales
XDG :
- Adapté aux environnements de bureau
- Gestion des pop-ups
- Spécification stricte et standardisée
- Interactions utilisateur riches et complexes
Conclusion :
Les protocoles IVI et XDG jouent des rôles cruciaux mais distincts dans l'environnement Wayland.
Chacun offre des fonctionnalités adaptées à son domaine, permettant la gestion et le contrôle des interfaces utilisateurs.
Comprendre ces différences est essentiel pour démarrer le développement d'un compositeur Wayland efficace, qu’il s’agisse de systèmes embarqués ou d’environnements de bureau.
En fonction de vos besoins en matière de développement, j'espère que cet article vous aura aidé à déterminer le protocole le plus adapté à vos exigences.