Publication de Wayland-Protocols 1.38

La version 1.38 du paquet wayland-protocols a été publiée, contenant un ensemble de protocoles et d'extensions qui complètent le protocole de base Wayland et fournissent les fonctionnalités nécessaires à la création de serveurs composites et d'environnements utilisateur.

Tous les protocoles passent par trois phases successives : développement, test et stabilisation. Après la phase de développement (catégorie « unstable »), le protocole est placé dans la branche « staging » et est officiellement inclus dans l'ensemble des wayland-protocols. Une fois les tests terminés, il est déplacé dans la catégorie stable. Les protocoles de la catégorie « staging » peuvent déjà être utilisés dans des serveurs composites et des clients où les fonctionnalités associées sont nécessaires. Contrairement à la catégorie « unstable », des modifications qui compromettent la compatibilité sont interdites dans « staging », mais en cas de problèmes et de lacunes identifiés lors des tests, un remplacement par une nouvelle version significative du protocole ou une autre extension Wayland n'est pas exclu.

Dans la nouvelle version, les protocoles suivants ont été ajoutés à la catégorie «staging» :

• xdg-system-bell — permet de générer un signal système qui peut être utilisé, par exemple, comme alerte dans les émulateurs de terminal. La forme de sortie du signal est laissée à la discrétion du gestionnaire de composition, cela peut être non seulement un son, mais aussi une réponse visuelle.
• fifo — met en œuvre un mécanisme FIFO (premier arrivé, premier parti) pour le traitement de la file d'attente de mise à jour du contenu de la surface affichée. D'un point de vue pratique, le protocole permet d'utiliser l'attente de la fin du décalage vertical (vblank) au lieu d'appels de rappel à chaque fois qu'il est prêt à afficher un nouveau cadre, ce qui résout le problème d'une charge GPU élevée en utilisant VSync.
• commit-timing — permet d'associer une limite de temps au contenu d'une surface (le serveur composite doit afficher la modification du contenu dans la mesure du possible après le temps indiqué, mais pas avant).

Actuellement, l'ensemble des wayland-protocols comprend les protocoles stables suivants, garantissant la rétrocompatibilité :

• « viewporter » — permet au client d'effectuer des actions de mise à l'échelle et de rognage des bords de la surface côté serveur.
• « presentation-time » — assure l'affichage de la vidéo.
• « xdg-shell » — interface de création et d'interaction avec les surfaces en tant que fenêtres, permettant de les déplacer à l'écran, de les minimiser, de les agrandir, de redimensionner, etc.
• « linux-dmabuf » — permet le partage de plusieurs cartes graphiques grâce à la technologie DMA-BUF (permet de créer un wl_buffer basé sur DMA-BUF).
• «tablet» – organisation de l'entrée à partir de tablettes graphiques.

Protocoles testés dans la branche « staging » :

• drm-lease — fournit les ressources nécessaires pour créer une image stéréo avec des tampons différents pour l'œil gauche et l'œil droit lors de l'affichage sur des casques de réalité virtuelle.
• «ext-session-lock» — définit les moyens de verrouillage de session, par exemple, lors de l'utilisation d'un économiseur d'écran ou lors de l'affichage d'une boîte de dialogue d'authentification.
• «single-pixel-buffer» — permet de créer des tampons de un pixel comprenant quatre valeurs 32 bits RGBA.
• «xdg-activation» — permet de transférer le focus entre différentes surfaces de niveau supérieur (par exemple, avec xdg-activation, une application peut déplacer le focus sur une autre).
• content-type — permet aux clients de transmettre des informations sur le contenu affiché, qui peuvent être utilisées pour optimiser le comportement en fonction du contenu, par exemple, pour définir des propriétés DRM spécifiques telles que «content type». Les types de contenu suivants sont pris en charge : none (aucune information sur le type de données), photo (affichage de photos numériques nécessitant un minimum de traitement), video (vidéo ou animation nécessitant une synchronisation plus précise pour éviter les saccades) et game (exécution de jeux nécessitant un affichage avec un retard minimal). serveur ext-idle-notify — permet aux serveurs de composition de transmettre aux clients des notifications d'inactivité de l'utilisateur, ce qui peut être utilisé pour activer des modes d'économie d'énergie supplémentaires après une certaine période d'inactivité.
• tearing-control — permet de désactiver la synchronisation verticale (VSync) dans les applications en plein écran avec une impulsion de suppression de frame, utilisée pour éviter les déchirements lors de l'affichage. Dans les applications multimédias, l'apparition d'artefacts causés par le tearing est un effet indésirable, mais dans les programmes de jeux, la présence d'artefacts peut être tolérée si la lutte contre ceux-ci entraîne des retards supplémentaires.
• ext-foreign-toplevel-list — obtention d'informations sur les surfaces placées au niveau supérieur, permettant d'organiser le maintien des fenêtres au-dessus d'un autre contenu, par exemple pour connecter des panneaux et des commutateurs propres.
• ext-foreign-toplevel-list — obtention d'informations sur les surfaces placées au niveau supérieur, permettant d'organiser le maintien des fenêtres au-dessus d'un autre contenu, par exemple pour connecter des panneaux et des commutateurs propres.
• security-context — permet d'identifier les clients utilisant l'isolation sandbox. Le client peut enregistrer une nouvelle connexion au serveur composite basé sur Wayland et y attacher un contexte de sécurité, après quoi, conformément au contexte de sécurité spécifié, le gestionnaire de composition restreindra les capacités disponibles pour la connexion établie.
• cursor-shape — une méthode alternative de configuration de l'apparence du curseur, basée sur la transmission d'une série d'images de curseur au lieu d'une liaison à la surface (wl_surface).
• «ext-transient-seat» – conçu pour créer des sessions temporaires indépendantes (seat), destinées à être utilisées avec des dispositifs d'entrée virtuels. Par exemple, lors de la mise en œuvre de la possibilité de connexion à un bureau distant le protocole permet de créer une session distincte pour chaque utilisateur avec un clavier et une souris virtuels.
• «xdg-toplevel-drag» – étend le mécanisme «glisser-déposer» avec la possibilité d'attacher des fenêtres de niveau supérieur à une opération de déplacement, ce qui peut être utilisé, par exemple, pour organiser le glissement de panneaux d'outils ou d'onglets de navigateur. Le nouveau protocole permet de créer des parties détachables de la fenêtre, qui, lorsqu'elles sont glissées hors de cette fenêtre, deviennent de nouvelles fenêtres et peuvent être déplacées au-dessus d'une fenêtre existante avant d'être reconnectées.
• «xdg-dialog» – permet d'attribuer des caractéristiques spécifiques aux fenêtres de niveau supérieur, par exemple, il est possible de créer des dialogues modaux qui bloquent l'interaction de l'utilisateur avec le reste de l'interface.
• « linux-drm-syncobj » — fournit des outils pour la synchronisation explicite des buffers à l'aide d'objets de synchronisation DRM (Direct Rendering Manager). Il est supposé que dans le contexte de la synchronisation lors du rendu dans le buffer, le protocole proposé permettra d'améliorer le fonctionnement avec les pilotes basés sur les APIs graphiques Vulkan et OpenGL (la réalisation est basée sur des gestionnaires dans les pilotes). Le nouveau protocole permet de s'assurer que l'opération de rendu dans le buffer est terminée avant que le gestionnaire composite n'affiche ce buffer.
• alpha-modifier, permettant aux clients de modifier le niveau de transparence de la surface et de déplacer les opérations de gestion de la transparence vers le serveur composite, qui peut ensuite rediriger ces opérations vers KMS.
• xdg-toplevel-icon — liaison d'une icône à une fenêtre de niveau supérieur.
• ext-image-capture-source et ext-image-copy-capture — organisation de la capture de contenu affiché à l'écran.

Protocoles en cours de développement dans la branche «unstable»:

• «fullscreen-shell» — gestion du mode plein écran.
• «input-method» — traitement des méthodes d'entrée.
• «idle-inhibit» — désactivation du lancement de l'économiseur d'écran.
• «input-timestamps» — horodatages pour les événements d'entrée.
• «keyboard-shortcuts-inhibit» — gestion de l'attachement des combinaisons de touches et des raccourcis clavier.
• «linux-explicit-synchronization» — mécanisme de synchronisation des tampons spécifique à Linux lié à la surface.
• «pointer-gestures» — contrôle des gestes des écrans tactiles.
• «pointer constraints» — contraintes des pointeurs (blocage).
• «primary-selection» — de manière similaire à X11, fournit un fonctionnement du tampon de sélection primaire, dont l'insertion d'informations se fait généralement par le bouton central de la souris.
• «relative pointer events» — événements de pointeur relatifs.
• «text-input» — gestion de l'entrée de texte.
• «xdg-foreign» — interface d'interaction avec les surfaces du client «voisin».
• «xdg-decoration» — rendu des décorations des fenêtres côté serveur.
• «xdg-output» — informations supplémentaires sur la sortie vidéo (utilisée pour le zoom fractionné).
• «xwayland-keyboard-grab» — capture de l'entrée dans les applications XWayland.

On peut également noter la proposition d'un employé de Valve d'ajouter une nouvelle phase pour la promotion des nouveaux protocoles Wayland — «experimental», qui permettra d'abaisser le seuil d'inclusion des protocoles dans l'ensemble wayland-protocols et d'accélérer leur adoption. Actuellement, pour qu'un protocole passe en phase staging, il faut former une équipe de soutien et obtenir un certain nombre de confirmations (ACK) de la part des participants à l'examen. Dans la phase «experimental», il est proposé d'accepter un protocole, non pas par confirmation, mais sur la base de l'absence d'objections (NACK) pendant une période d'examen de deux semaines. Les participants peuvent également prolonger la discussion de deux semaines supplémentaires, en indiquant le statut «WAIT».

Dans la phase «experimental», il est également proposé de permettre les modifications qui compromettent la compatibilité et l'ajout de protocoles «bruts», qui pourront être progressivement développés. Ainsi, la phase «experimental» permettra d'acheminer rapidement aux développeurs de nouveaux prototypes de protocoles, de stimuler leur mise en œuvre dans des projets existants et d'obtenir des retours d'expérience des utilisateurs. Le processus proposé devrait libérer les développeurs de protocoles des longues discussions et des tracas avant leur inclusion dans wayland-protocols. Par exemple, les protocoles xdg-system-bell, fifo et commit-timing, acceptés dans cette version actuelle, ont été discutés pendant plus d'un an.

Source : opennet.ru