URL: https://linuxfr.org/news/wayland-et-weston-1-4 Title: Wayland et Weston 1.4 Authors: ariasuni Davy Defaud, antistress, palm123, EdB, jcr83, Jiehong, reno, Nÿco, Johann Ollivier-Lapeyre, Melkor73, Goth, Nils Ratusznik et Xavier Teyssier Date: 2014年01月24日T22:51:35+01:00 License: CC By-SA Tags: wayland, weston, x11 et lwn Score: 103 Wayland et Weston sont sortis en version 1.4 le jeudi 24 janvier. Sous GNU/Linux et BSD (et d’autres...), lorsqu’une application veut afficher quelque chose à l’écran, elle doit utiliser le protocole X11 pour communiquer avec X.Org, qui se charge de faire l’affichage. Or, ces derniers sont très vieux et ne sont pas adaptés au matériel moderne. X.Org a été conçu à une époque où l’on utilisait peu la carte graphique. Aujourd’hui, nos navigateurs Web (rendu HTML, CSS, JavaScript...) et nos interfaces graphiques (Qt, Cairo...) ont de nombreuses occasions de solliciter celle‐ci, sans compter que l’arrivée de Steam a permis l’arrivée de nombreux titres pour notre système d’exploitation favori. Côté sécurité, X.Org est une vraie passoire : écrire un enregistreur de clavier est un jeu d’enfant... Wayland devrait changer ça, mais cela ne signifie pas la fin des failles. Par exemple, l’arrivée de WebGL (et bientôt de WebGL 2 ! _cf._ [_ici_](https://hacks.mozilla.org/2014/01/webgl-deferred-shading/) et [_là_](https://wiki.mozilla.org/Platform/GFX/WebGL2)) dans nos navigateurs Web ouvre potentiellement de nouvelles failles dans nos systèmes, d’autant plus que les pilotes graphiques eux‐mêmes n’ont souvent pas été conçus dans une optique principale de sécurité, mais c’est un autre problème. Mais alors, que sont Wayland et Weston ? ---- [Articles sur LinuxFr.org en rapport avec Wayland](http://linuxfr.org/tags/wayland/public) [Page Wikipédia sur Wayland](http://fr.wikipedia.org/wiki/Wayland) [X.Org est mort, vive Wayland !](http://linuxfr.org/news/x-org-est-mort-vive-wayland) [X.Org est mort, vive Wayland ! (2)](http://linuxfr.org/news/x-org-est-mort-vive-wayland-2) [X.Org est mort, vive Wayland ! (3)](http://linuxfr.org/news/x-org-est-mort-vive-wayland-3) [Site de Wayland (sur freedesktop.org)](http://wayland.freedesktop.org/) [Vidéo d’Intel faisant la promotion de Wayland](https://www.youtube.com/watch?v=vPl2fPRhhkU) [Page Wikipédia sur la pile graphique de Linux](https://fr.wikipedia.org/wiki/Pile_graphique_Linux) ---- # Rappels sur Wayland et Weston Wayland est un protocole de serveur d’affichage destiné à remplacer X11 (sans ses défauts). Il a le soutien officiel des développeurs X11/X.Org. Weston est une implémentation de référence de Wayland (pour la démonstration, mais il se pourrait qu’on le retrouve utilisé tel quel, notamment dans l’embarqué). Côté développeur, seules quelques briques logicielles devront être adaptées (toutes les bibliothèques d’interfaces graphiques et certaines applications utilisant des fonctions graphiques de bas niveau). Une particularité de Wayland est que le protocole doit être implémenté dans le compositeur (qui est souvent également le gestionnaire de fenêtres : [[Kwin]], [Mutter](http://fr.wikipedia.org/wiki/Mutter_%28gestionnaire_de_fen%C3%AAtres%29), etc.), ce qui permet d’éviter les coûteuses communications entre le serveur X et le compositeur pour le rendu. Le protocole est également plus simple. Les développeurs de Wayland et Weston sont majoritairement des développeurs de X.Org. Ils sont donc tout à fait au courant des failles de X.Org, et ne veulent pas les corriger car cela impliquerait un travail titanesque, et un changement d’API considérable qui obligerait beaucoup de développeurs à récrire leurs bibliothèques et applications pour prendre en compte les modifications. En repartant de zéro, il est possible de construire un modèle de sécurité solide. [[_Source_](http://lwn.net/Articles/517375/)] Enfin, il sera toujours possible d’utiliser les applications qui n’auront pas migré grâce à XWayland (qui permet de faire tourner X.Org à l’intérieur de Wayland). Malgré l’utilisation d’une couche supplémentaire (Wayland + XWayland au lieu de X.Org tout seul), on attend des performances similaires voire meilleures (car on profite des améliorations de Wayland). Pour mieux comprendre ce que sont Wayland et Weston, vous pouvez lire la série de dépêches intitulée _X.Org est mort, vive Wayland !_, dont les liens sont disponibles en première partie de dépêche. ## OpenGL Les bibliothèques et pilotes OpenGL sous GNU/Linux dépendent de X.Org, c’est pourquoi Wayland n’utilise pas OpenGL mais OpenGL ES (plus souvent implémenté pour l’instant dans les pilotes graphiques des puces pour _smartphones_ et tablettes. Toutefois, les puces Intel, par exemple, bénéficient de la prise en charge d’OpenGL ES à partir des processeurs graphiques de génération [[Sandy Bridge]], c’est‐à‐dire à partir des puces graphiques [_Gen6_](http://fr.wikipedia.org/wiki/Intel_HD_Graphics#Puces_de_sixi.C3.A8me_g.C3.A9n.C3.A9ration_.E2.80.94_dites_Gen6), dans la nomenclature du fondeur). À long terme, on pourra utiliser de l’OpenGL « classique » sous Wayland. ## Linux Pour afficher des messages à l’écran, le noyau était déjà obligé de s’occuper de la gestion du mode d’affichage (résolution, fréquence de rafraîchissement, profondeur de couleur), qui était alors réinitialisé lors du chargement du pilote pour X.Org. Au final, il y avait des problèmes de lenteur lors du changement entre session graphique et terminaux virtuels, et de mauvaises résolutions dans ces derniers. [KMS](http://fr.wikipedia.org/wiki/Kernel-based_mode-setting) a alors été intégré au noyau pour gérer cela bien avant le lancement de la session graphique, ce qui est non seulement plus efficace, mais évite en plus les clignotements lors du chargement du pilote. Il y a donc une partie du pilote pour le noyau (pilotes [nom_du_pilote]-dri) et la partie X.Org (xf86-video-[nom_du_pilote_]). Avec Wayland, les pilotes X.Org ne seront plus nécessaires, réduisant la quantité de code à maintenir. ## Démonstration Il y a plein de vidéos de démonstration disponibles, mais il y en a une en particulier que je tiens à vous montrer, car elle est vraiment originale. En effet, c’est [la vidéo d’un compositeur Wayland un peu spécial](http://www.youtube.com/watch?v=_FjuPn7MXMs)... Bref, on peut faire des trucs vraiment sympathiques avec Wayland. ;) # Prise en charge de Wayland ## Boîtes à outils Wayland est déjà pris en charge par Qt depuis la version 5, GTK depuis la version 3, Clutter, la SDL, et les EFL. Il faut cependant garder à l’esprit que Wayland est toujours en développement et que la gestion de Wayland n’a pas été testée à grande échelle. Il ne faut donc pas attendre la même stabilité que des systèmes qui sont basés sur un protocole inchangé depuis plusieurs dizaines d’années, mais ça fonctionne et le plus gros du travail a été fait. ## Environnements de bureau La gestion de Wayland dans KDE est prévue pour l’été 2014, à partir de la sortie de KDE Frameworks 5. KDE Frameworks 5 est la nouvelle génération de _kdelibs_ (migration vers Qt5, nettoyage de code, modularisation), commencée au printemps 2011. Toute application KDE utilisant les nouvelles bibliothèques ne nécessitera que peu de changements pour fonctionner, à l’exception notable de Kwin qui utilise de nombreuses fonctions de bas niveau. GNOME Shell, [l’environnement de bureau des canards](http://linuxfr.org/users/jehane/journaux/ras-le-bol-des-images-hors-sujet#comment-1379616), gère Wayland depuis [GNOME 3.10](https://help.gnome.org/misc/release-notes/3.10/), mais on attend une bien meilleure prise en charge pour GNOME 3.12. Canonical n’a pas l’intention d’ajouter la prise en charge de Wayland à Unity. En effet, les gens de Canonical développent leur propre solution pour remplacer X.Org : Mir. Enlightenment prend partiellement en charge Wayland depuis la version 0.18, la prise en charge complète arrivera avec la version 0.19. Hawaii est un nouvel environnement de bureau, [parce que les goûts et les couleurs](http://www.maui-project.org/about/faq/#why_are_you_making_a_new_desktop_environment)... Il fait partie d’un projet de nouveau système d’exploitation, [Maui](http://www.maui-project.org/), conçu à l’image d’[elementary OS](http://elementaryos.org/) et Pantheon (et Ubuntu/Unity ?) pour réaliser un système cohérent et sans problèmes. Il est conçu sur des technologies modernes telles que _systemd_, Wayland et Qt5 (là où elementary OS a fait le choix de technologies GNOME, comme GTK). Une très bonne nouvelle pour les utilisateurs de gestionnaires de fenêtres légers, il sera possible de migrer vers Wayland sans écrire un compositeur complet grâce à [SWC](https://github.com/michaelforney/swc), une bibliothèque qui fait moins de 6 000 lignes de code et qui « a pour but d’embarquer le strict minimum pour afficher des fenêtres sur l’écran. » # Nouveautés Voici une liste des nouveautés introduites au sein de Wayland et Weston, traduction de l’[annonce](http://lists.freedesktop.org/archives/wayland-devel/2014-January/012903.html) sur la liste de diffusion du projet. ## Wayland * Protection des tampons SHM contre le signal SIGBUS. Des fonctions utilitaires ont été ajoutées par Neil Roberts pour aider les compositeurs à se protéger contre des clients dysfonctionnels ou malveillants qui tronqueraient le fichier sous‐jacent aux tampons SHM et déclencheraient un signal SIGBUS. * Le protocole Subsurfaces a intégré le dépôt Wayland et fait donc partie officiellement du protocole Wayland (Pekka Paalanen). Une description est disponible ici : . * `wl_proxy_set_queue()` accepte une file d’attente (_queue_, en anglais) NULL pour se réinitialiser sur celle par défaut. (Neil Roberts). * Quelques corrections de bogues, notamment une situation de concurrence entre `wl_proxy_create()` et `wl_proxy_marshal()`. * Quelques améliorations sur les messages d’erreur liés au scanneur et des ajustements de la documentation. ## Weston * Des boutons dans les fenêtres XWayland et des décorations correctes pour le compositeur imbriqué (moteur Wayland). (Jason Ekstrand) * Conversion de _gl-render_ en module chargeable et ajout de la possibilité de passer de _pixman_ à _gl-render_ durant l’exécution. Cela permet un chargement du compositeur plus rapide, puisque _gl-render_ et EGL + GLES 2 peuvent être chargés et initialisés plus tard lors de la phase de démarrage (Ander Conselvan de Oliveira). * Utilisation de _logind_ pour l’accès privilégié (accès à la carte graphique — via le composant [DRM](http://en.wikipedia.org/wiki/Direct_Rendering_Manager) du noyau — et aux périphériques d’entrée). Weston peut donc utiliser [KMS](http://fr.wikipedia.org/wiki/Kernel-based_mode-setting) sans bidouillage. (David Herrmann) * Meilleure gestion du débranchement de sortie. En effet, cela vautrait Weston car le débranchement de sortie (moniteur) n’était simplement pas pris en charge. Nous nettoyons désormais les choses de façon appropriée et nous faisons revenir les fenêtres dans la région visible quand leur sortie est débranchée. (Ander Conselvan de Oliveira et Xiong Zhang) * Animation du focus du clavier et _exposay_ (aperçu de fenêtres de type exposé) contribué par Collabora. * Meilleure prise en charge des écrans tactiles, incluant le toucher‐déplacer et le toucher-activer pour les surfaces, et le glisser‐déposer. (Xiong Zhang) * Début du travail sur le protocole _xdg-shell_. C’est une tentative plus formelle de développer un protocole pour l’interaction entre les applications et un environnement de bureau. Le protocole _wl_shell_ actuellement présent dans Wayland a toujours été un développement temporaire pour aider au démarrage de la prise en charge par les bibliothèques d’interfaces graphiques. Maintenant que GNOME Shell migre sur Wayland, nous avons un environnement de bureau complet pour orienter le travail et nous pouvons commencer les choses sérieuses. (Jasper St. Pierre, Rafael Antognolli) * Passage de tampon à travers un compositeur imbriqué. Nous avons spécifié une nouvelle extension EGL qui permet de faire passer des tampons à travers un compositeur imbriqué. Ceci permet au compositeur imbriqué de ne pas faire le rendu et à la place de présenter le contenu au compositeur sous‐jacent, en utilisant une _subsurface_ ou autre (Neil Roberts). * Protocole de rognage et de mise à l’échelle. Ce protocole, que nous avions initialement mis en place dans Weston, permet à un client de spécifier que seul un sous‐rectangle de sa surface doit être présenté, et potentiellement agrandi. (Jonny Lamb et Pekka Paalanen) * Dans _weston-terminal_, on peut utiliser Ctrl + Maj + ↑/↓ pour défiler et voir l’historique de la sortie du terminal. Ajout d’un menu contextuel pour un accès simple au copier, coller et nouveau terminal (qui ont toujours été accessibles via Ctrl-Maj-C/V/N). (Kristian Høgsberg). Prise en charge de la sélection avec un écran tactile. (Xiong Zhang) # La suite [DRI3](http://fr.wikipedia.org/wiki/Direct_Rendering_Infrastructure), qui vient d’intégrer la version 1.15 du serveur X.Org, ne figure pas encore dans cette livraison, et nous attendons symétriquement l’intégration de XWayland dans le serveur X qui, comme nous l’avons vu, permettra à Wayland de faire tourner les applications X11 classiques qui n’auront pas été adaptées.

AltStyle によって変換されたページ (->オリジナル) /