URL: https://linuxfr.org/news/x-org-est-mort-vive-wayland-3 Title: X.Org est mort, vive Wayland ! (3) Authors: Johann Ollivier-Lapeyre Davy Defaud, Jiehong, Nÿco, palm123, Jarvis, Benoît Sibaud, Ontologia, Pierre Jarillon, Benoît, bayo, marsup, NeoX, PierreLM et claudex Date: 2013年07月13日T12:16:52+02:00 License: CC By-SA Tags: wayland, xorg, weston, linux_mint et ubuntu Score: 77 Le système graphique [Wayland](http://fr.wikipedia.org/wiki/Wayland) vient de passer une nouvelle étape. En effet, le rythme de développement de Wayland et Weston s’est accéléré depuis le passage à un cycle de publication trimestriel. Cette version est importante, car elle met en place une gestion de version dans l’API qui permettra de passer en douceur les futures évolutions. Par ailleurs, les manœuvres sont en cours au niveau des bibliothèques graphiques (*toolkits*), environnements de bureau et distributions. Pour rappel, Wayland est un protocole alternatif à X, repensé pour les usages modernes, et Weston le compositeur référence utilisant Wayland. ![Wayland](http://wayland.freedesktop.org/wayland.png) Il reste néanmoins encore du chemin pour une bonne maturité du produit, alors que la concurrence devient forte surtout dans le domaine de l’embarqué avec Ubuntu Touch et Mir qui pointent à l’horizon, et, bien sûr, [SurfaceFlinger](http://developer.android.com/guide/topics/graphics/index.html) utilisé dans Android. _NdM : merci à mpurple pour avoir également proposé une dépêche sur le sujet. Ces deux dépêches ont été fusionnées._ ---- [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) [Pourquoi Wayland veut remplacer X ?](https://linuxfr.org/news/pourquoi-wayland-veut-remplacer-x) [Annonce de la version 1.2](http://lists.freedesktop.org/archives/wayland-devel/2013-July/010278.html) [Dépôt Git de Wayland](http://cgit.freedesktop.org/wayland/wayland/) [Dépôt Git de Weston](http://cgit.freedesktop.org/wayland/weston/) ---- # Avancement # ##Versionnage de l’API Lorsque la 1.0 est sortie, il n’y avait pas d’API stable pour `libwayland-server.so`. Cela signifie que pour chaque version majeure de Wayland, les compositeurs pouvaient être cassés en ne parlant pas le même langage. Juste au niveau de Weston, ce n’était pas bien grave, mais les compositeurs externes pour Wayland apparaissant, cette instabilité de l’interface devait changer, avec une gestion de version de l’API. Une grande partie de ce travail a été réalisée par Jason Ekstrand. ##Gestion des couleurs Richard Hughes a travaillé sur la gestion des couleurs dans Wayland et a implémenté deux thèmes dans Weston : un simple greffon qui lit des profils CMS, et un greffon plus avancé qui intègre _colord_ (un service permettant de gérer des profils de couleurs). Ceci n’est valable qu’avec le compositeur DRM. On peut voir une [capture d’écran](https://plus.google.com/107928060492923463788/posts/X62VdJxB2UK) montrant l’intégration au _Centre de contrôle_ de GNOME. ##Postes de travail multiples et gestion des entrées La gestion des entrées est maintenant complète. Celle‐ci permet d’avoir plusieurs périphériques (claviers, souris ou écrans) sur une même unité centrale, avec un utilisateur devant chaque écran. La gestion des systèmes d’entrée est différenciée et permet de créer de nouvelles entrées à chaud. Comme le montre la [vidéo] (http://www.youtube.com/watch?v=WO2L_ihO_rI), cela nous permet de configurer de multiples sièges à Weston, à l’instar du multi‐pointeur de X, où chaque personne dispose de son propre pointeur et sa propre cible de saisie clavier (_focus_). Il permet aussi de fixer un système d’entrée à une sortie vidéo. ##Subsurface API par Pekka Paalanen Cette extension nous permet de construire des fenêtres d’application à partir de multiples surfaces Wayland, combinant potentiellement différents espaces colorimétriques ou types de tampons. Les lecteurs vidéo combinant interface graphique, vidéo et fenêtres utilisent typiquement ce genre de fonctionnalités. ##Redimensionnement de la sortie Le redimensionnement de la sortie est désormais possible, notamment pour les affichages à haute densité (Hi-DPI). Une [explication complète](http://blogs.gnome.org/alexl/2013/06/28/hidpi-support-in-gnome) est donnée par Alex Larsson sur son blogue. Cela implique la prise en charge de fenêtres redimensionnées à divers facteurs d’échelle sur les différentes sorties, ainsi que le redimensionnement global. ##backend et moteur de rendu pour le Rasperry Pi par Collabora. Si [cette impressionnante vidéo de comparaison Xorg/Wayland sur le Rasperry](http://www.collabora.com/videos/rpi-wayland-demo-720p.webm) vous a donné envie d’en savoir plus, voilà quelques articles qui valent d’être lus : * http://ppaalanen.blogspot.com/2013/05/weston-on-raspberry-pi-accelerated.html * http://fooishbar.org/tell-me-about/wayland-on-raspberry-pi/ * http://www.collabora.com/services/case-studies/raspberrypi * http://www.linux.com/news/embedded-mobile/mobile-linux/721510-raspberry-pi-gains-graphics-speed-as-wayland-replaces-x ##Multi‐tâche La version précédente était plus qu’instable. En effet, il était impossible de dessiner un tampon dans un fil d’exécution et demander à un autre de gérer les événements. Il fallait passer par un autre mécanisme pour synchroniser les deux fils d’exécution. Une des limites de la bibliothèque du côté client est que Wayland supposait, de manière « optimiste », que les bibliothèques graphiques (*toolkits*) ou les applications fourniraient un « fil d’exécution principal ». Désormais, une tâche principale transmet les événements aux autres qui peuvent gérer l’affichage ou les événements d’entrée. ##Un nouveau client d’exemple Pour illustrer une application qui compose des tampons avant d’obtenir un rendu final, un nouveau client d’exemple a fait son apparition. ##Désactivation de libxkbcommon L’utilisation de _libxkbcommon_ n’est plus obligatoire lorsqu’un clavier complet n’est pas utile, ce qui est surtout valable pour les systèmes embarqués (le tableau de bord d’une voiture, par exemple). # Applications et environnements de bureau # ## Bibliothèques et logiciels ## Plusieurs bibliothèques graphiques et environnements sont maintenant compatibles avec Wayland : * Clutter ; * EFL ; * Qt 5 ; * GTK+ 3.8 ; * SDL. Une application se basant sur une de ces cinq technologies et ne faisant pas d’appels directs à Xlib devrait, en théorie, être compatible nativement avec Wayland. Dans la pratique, la prise en charge des applications est encore incomplète, mais en progression, comme on peut le voir sur [une liste d’applications GNOME en test](https://wiki.gnome.org/Wayland/Applications). Les problèmes viennent parfois des dépendances, comme WebKitGTK+, qui vient d’être corrigé. Les applications qui n’auront pas migré seront néanmoins pleinement utilisables dans un environnement Wayland, grâce à la couche de compatibilité XWayland (et parfois seront même plus performantes qu’avec un serveur X). ## Environnements de bureau Comme l’évoque Martin Gräßlin (développeur de Kwin), si se baser sur une des bibliothèques prenant en charge Wayland comme Qt 5 résout 99 % des soucis, les environnements de bureau sont clairement impactés par le pourcent restant, car les gestionnaires de fenêtres (au sens large) et autres gadgets de bureau ont été pensés pour X. Le travail est donc plus lourd à ce niveau. Par ordre de maturité vis‐à‐vis de Wayland, et de sortie probable : ### Enlightenment ### Enlightenment semble très avancé concernant une prise en charge à 100 % de Wayland avec le développement d’un [compositeur correspondant](https://www.youtube.com/watch?v=dfnvYAKKPZI). ### GNOME ### Pour GNOME 3.10 (septembre 2013), X restera par défaut. Néanmoins, en mode Wayland, GNOME Shell agira en compositeur Wayland, le serveur GTK+ sera utilisable et les applications non migrées utiliseront la compatibilité X (XWayland) de manière transparente. Pour GNOME 3.12 (mars 2014), le portage sera normalement fini (bureau et applications). Les applications éventuellement non migrées fonctionneront toujours grâce à XWayland, en attendant leur tour. Il n’est en revanche pas garanti que le bureau GNOME 3.12 puisse continuer à fonctionner avec X.Org seul, à cause d’incompatibilités envisagées par les développeurs. ### KDE ### La communauté KDE, grâce au passage à Qt 5, cherche à éviter un _big bang_ comme celui qui eut lieu entre KDE 3 et KDE 4, ou celui entre GNOME 2 et GNOME 3. Les bibliothèques, le bureau et les applications suivent des cycles séparés et il n’y aura donc pas de KDE 5 à une date fixée qui prendra en charge Wayland. L’adoption sera progressive, avec un stade où il sera pris en charge par le bureau, puis par les applications au moment de leur passage individuel à Qt 5. Pour KDE SC 4.11 (août 2013) : * les bibliothèques (KDE Frameworks) sont maintenant engagées sur Qt 5 ; * le bureau finira bientôt sa migration vers QML ; * un prototype Wayland sera livré en option, permettant une exécution non optimale. Pour la suite : * un compositeur compatible Wayland et X va enrichir KWin. Martin Graeßlin a entamé le travail, et il a d’ailleurs indiqué que Wayland apporte de nouvelles possibilités dans ce domaine : un plantage de Wayland à cause d’un mauvais pilote graphique pourrait être détecté et récupéré, sans impact sur les applications lancées. Peut‐être une option possible dès KDE SC 4.12 ; * le développement de Plasma s’arrête avec la 4.11, et plasma 2 sera développé avec KDE Frameworks 5. ## Distributions ### Rebecca Black OS ### Cette distribution, qui n’est pas forcément connue de tous, est un disque amorçable de démonstration de Wayland. À noter que si vous utilisez GRUB 2, vous pouvez lancer directement l’image ISO à partir de GRUB et de votre disque dur, pour de meilleures performances. Rebecca Black OS, qui vient d’être mis à jour en version 1.2, est maintenu par un passionné, sur une base de Kubuntu. Il ne faut donc pas s’attendre à un niveau de finition exemplaire, mais plutôt à une bonne opportunité de tester la prise en charge des bibliothèques graphiques (EFL, GTK+, Qt) en mode Wayland « pur » ou avec une couche de compatibilité X, ou encore d’être impressionné(e) par les performances de redimensionnement de fenêtres. → __ ### Kubuntu ### Kubuntu, ainsi que les autres distributions basées sur Ubuntu, subissent la décision de Canonical d’avoir un serveur d’affichage, Mir, conçu pour ne fonctionner correctement qu’avec Unity ou un mode de compatibilité X. Devant l’impossibilité de trouver une solution satisfaisante pour les développeurs Kubuntu, Jonathan Riddell a annoncé que l’avenir de Kubuntu passera par Wayland, avec les 13.10 et 14.04 LTS qui resteront basées sur X par défaut. → __ Une solution de mise en commun de l’empaquetage graphique est à envisager avec les autres distributions qui se retrouvent dans la même situation, comme Ubuntu GNOME ou Linux Mint.

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