Wayland et Weston 1.5

62
29
mai
2014
Serveurs d'affichage

Wayland et son implémentation de référence Weston sont sortis en version 1.5 le mardi 20 mai 2014. Au programme, pas de révolution, mais beaucoup de bogues corrigés.

Sous GNU/Linux et BSD (entre autres), lorsqu’une application veut afficher quelque chose à l’écran, elle doit utiliser le protocole X11 pour communiquer avec X.Org. Mais X.Org est vieux, pas adapté au matériel moderne et pas sécurisé.

Wayland

Wayland est le nom du protocole d’affichage local conçu pour remplacer le protocole X11, d’une bibliothèque qui l’implémente (et du projet en général). Une partie du travail qui était fait par X.Org devra désormais être faite par le compositeur, dans la plupart des cas le gestionnaire de fenêtres. Weston est une implémentation de référence d’un compositeur pour démontrer les capacités des protocoles (Wayland, xdg-shell…) et des bibliothèques utilisées (libxkbcommon, libinput…).

Wayland est déjà pris en charge par Qt 5, GTK 3, Clutter, SDL et EFL. KDE et GNOME le prennent en charge partiellement via leurs gestionnaires de fenêtres, respectivement KWin et Mutter. D’autres projets naissent sur Wayland comme Hawai.

Pour l’occasion, la catégorie « X » de LinuxFr.org devient « Serveurs d’affichage » (pour englober X.Org, Wayland, Mir et tout ce qui s’y rapporte) et change de logo !

N.D.L.R. : merci à JPEC pour son journal : Wayland & Weston 1.5.0 sont publiés.

Wayland et Weston ont désormais des makefiles non récursifs. Ce qui améliore les temps de compilation, surtout en cas de petite modification.

Le développement a été plutôt calme, un grand nombre de bogues ont été corrigés, et le nombre de bogues ouverts est même descendu jusqu’à 14 pendant un moment !

Wayland

Rien de particulier pour l’utilisateur lambda, Wayland étant assez mature, il évolue peu.

Côté technique, le traitement des évènements a été amélioré en gérant certains évènements (delete_id et erreurs) dans une file interne séparée, pour pouvoir les traiter immédiatement.

Weston

Encore du travail sur xdg-shell (une interface de programmation en cours de création pour standardiser le comportement de différents environnements de bureau sous Wayland), qui n’est pas encore fini. Nous avons cependant ajouté la fonctionnalité de minimisation de fenêtre qui a longuement manqué. Nous pensons finaliser l’interface xdg-shell pour la 1.6, à temps pour son utilisation par GNOME Shell 3.14.

La pile pour gérer les périphériques d’entrée de Weston a été refactorisée dans une nouvelle bibliothèque libinput. Pour le moment Weston doit être configuré pour l’utiliser, car il utilise toujours l’ancien code. Au fur et à mesure que l’interface de programmation (API) de libinput se stabilisera, l’ancien sera supprimé, rendant libinput indispensable.

Weston utilise maintenant le nouveau serveur Xwayland. Le code de Xwayland a été réusiné pour être son propre serveur X dans le dépôt de X.org, et fonctionne comme Xwin, Xquartz et Xnest. Une grande partie de la complexité et des bidouillages dans le vieux Xwayland fondé sur X.org venait du fait qu’il fallait combattre X.org qui essayait d’être un serveur graphique natif, découvrant les périphériques d’entrée et pilotant les sorties vidéos. Le but était de pouvoir réutiliser le code pour l’accélération 2D des divers pilotes DDX de X.org. Glamor devenant une architecture d’accélération crédible, nous n’avons plus besoin de contorsionner le code et la nouvelle base de code est bien plus simple et propre au final. Xwayland est désormais disponible en amont et sera distribué avec X.org 1.16.

Animation de la fermeture des fenêtres : une fonctionnalité mineure, mais cela valide le mécanisme de conservation d’une surface après que le client qui l’a créée ait disparu.

Il y a maintenant un mode plein écran, utile pour une utilisation en kiosque ou d’autres appareils de ce type.

Enfin, Weston gère désormais des profondeurs de couleurs différentes pour différentes sorties vidéo.

La suite

Comme mentionné dans les notes de la RC2, nous avons gardé des choses pour la versio-n 1.5.1 et nous essaierons de la sortir dans quelques semaines. Pour la 1.6, nous essaierons de la faire en 4 mois, donc quelque chose comme :

  • mi-août : version alpha, toutes les grosses fonctionnalités intégrées, ensuite uniquement des fonctionnalités mineures et indépendantes ;
  • début septembre : RC1, après cela, que des corrections de bogues ;
  • une semaine plus tard : RC2, ensuite seulement des corrections de bogues critiques ;
  • mi-septembre : version 1.6, qui idéalement devrait être la RC2.

Pour le futur, je souhaiterais changer la façon de travailler sur la branche de développement principale. Le plus grand problème dans notre façon de travailler actuellement est que pour l’intégration des correctifs, je suis au mieux un goulot d’étranglement, au pire j’en oublie. Je veux donc étendre la liste de ceux qui peuvent modifier directement cette branche. Soit pour ceux qui ont leur partie de Weston qu’ils maintiennent (par exemple, Pekka, pour le moteur Raspberry Pi, ou Hardening, pour le moteur RDP), soit pour des contributeurs qui font partie du projet depuis un moment et qui comprennent bien le code — ou les deux.

Pouvoir relire un correctif et intégrer ce correctif devrait, je l’espère, augmenter la motivation à relire les correctifs, et je ne veux plus être obligé d’être là tout le temps pour faire avancer les choses. Je pense que tout le monde a assez de bon sens pour décider quand quelque chose est un petit correctif qui doit être intégré immédiatement et quand quelque chose nécessite une discussion plus large et un consensus avant intégration. Pour tout ce qui touche le cœur de Weston et, en particulier, tout ce qui touche au protocole, nous devons toujours avoir des correctifs, des relectures et une discussion dans la liste de diffusion avant intégration.

Kristian Høgsberg

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.