URL: https://linuxfr.org/news/le-combat-x-contre-wayland-les-faits-vus-par-eric-griffith Title: Le combat X contre Wayland : les faits vus par Eric Griffith Authors: claudex Davy Defaud, NeoX, GSurrel, ariasuni, jcr83, come, Sylvhem, Anonyme, Nÿco, ZeroHeure, Benoît, ElChinese, Thomas Debesse, Benoît Sibaud, Anthony Jaguenaud, Pierre Jarillon et Akiel Date: 2013年06月09日T15:53:18+02:00 License: CC By-SA Tags: wayland et xorg Score: 110 Voici la traduction (avec quelques libertés) d’un article paru sur _Phoronix_ sous licence [CC-By-3.0](http://creativecommons.org/licenses/by/3.0/deed.fr). ## Introduction Un aperçu des problèmes, corrections et fonctionnalités liés à X et Wayland. Écrit par Eric Griffith, avec l’aide de Daniel Stone (développeur X.Org et Wayland). Corrigé et validé par Daniel Stone. Cet article a été rédigé par un contributeur volontaire de _Phoronix_ en se basant sur des présentations de Keith Packard, David Airlie, Daniel Stone, Kristian Høgsberg ; ainsi que les wikis de X11, X12, Wayland et Freedesktop.org, et des questions‐réponses directes avec les développeurs. Depuis sa première annonce, il y a plusieurs années, il y a eu beaucoup d’informations, de désinformation, de fausses idées, et du pur [FUD](http://fr.wikipedia.org/wiki/FUD "Définition Wikipédia") à propos de Wayland, le remplaçant de nouvelle génération du système de fenêtrage X. Cette présentation a pour but de clarifier la situation de Wayland. L’article est très inspiré par la récente conférence technique donnée par Daniel Stone à la conférence Linux australienne [_linux.conf.au_](http://linux.conf.au/) de 2013, à laquelle il constitue une excellente introduction. L’anglais de Daniel Stone est facilement accessible, sa conférence complète excellemment l’article, et ses diapos sont un modèle d’humour. Allez la voir, c’est hilarant, très instructif et puis il est une des rares personnes qui connaît vraiment le sujet. Elle est disponible [au format Ogg vidéo](http://mirror.linux.org.au/linux.conf.au/2013/ogv/The_real_story_behind_Wayland_and_X.ogv) ou sur [un site de partage de vidéos bien connu](https://www.youtube.com/watch?v=RIctzAQOe44). ---- [L’article original sur Phoronix : Facts About X vs. Wayland](http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1) [Pourquoi Wayland veut remplacer X](http://linuxfr.org/news/pourquoi-wayland-veut-remplacer-x) [X.Org est mort, vive Wayland !](http://linuxfr.org/news/x-org-est-mort-vive-wayland) [X.Org est mort, vive Wayland ! (2)](https://linuxfr.org/news/x-org-est-mort-vive-wayland-2) ---- # Les lacunes de X Personnellement, je pense que les bénéfices et le but de Wayland sont mieux compris quand ils sont comparés aux erreurs et lacunes de X. Donc, commençons... ## Les premières années Nous avons passé les 10 dernières années ou presque à « corriger » le serveur X en empilant de plus en plus d’extensions et de greffons. Le problème est que X n’a qu’un système de gestion de versions très limité pour ses extensions. 1. La gestion de versions est gérée par client, et non par lien. Donc, si votre application prend en charge une version d’une extension donnée, mais que votre bibliothèque graphique en gère une autre, vous ne pouvez pas prévoir quelle version de l’extension vous allez obtenir. 2. Un exemple théorique : Rekonq gère XInput 2.2, KDELibs prend en charge XInput 2.0 et le greffon Flash ne gère que X11 Core... Tous ceux‐là vont se battre pour décider quelle version du système d’entrée Rekonq prend en charge et à la fin, vous aurez une version qui s’occupera de tout le monde... Qui ne sera peut‐être pas la version que tout le monde prend en charge. 3. Si vous avez de la chance, vous recevrez la plus basse version prise en charge et tout fonctionnera correctement. Si vous n’avez pas de chance, vous recevrez la plus haute version prise en charge et vous échangerez des données inutiles qui conduiront potentiellement à des erreurs entre le client et le serveur X. ## Les 4 mousquetaires des entrées X a quatre sous‐systèmes d’entrée : Core X11, XInput 1.0, XInput 2.0 et XInput 2.2. XInput 1.0 a été éliminé, mais les trois restants sont plus inter‐dépendants qu’indépendants. Comme Daniel Stone l’a dit : « Il y a à peu près 3 personnes qui comprennent VRAIMENT comment les sous‐systèmes d’entrée tiennent ensemble... Et j’aurais vraiment souhaité ne pas être l’un d’eux. » ## La politique ? Il y a de nombreuses années, quelqu’un a eu une idée : « technique, et non pas politique ». Qu’est‐ce que ça veut dire ? Cela veut dire que X a sa propre API de dessin, il est sa propre bibliothèque graphique, comme GTK+ ou Qt. Il définit les éléments de bas niveau, tels que les lignes, les lignes larges, les arcs, les cercles, les polices rudimentaires, et autres « blocs de construction » qui sont complètement inutiles pris séparément. Note de Daniel : « Histoire drôle : les lignes larges doivent respecter au pixel près la spécification, mais cette dernière les définit moches. » ## Bibendum Le serveur X est énorme et stupide. Avant que nous (la communauté) commencions à lui retirer des morceaux et travailler dessus, c’était presque un système d’exploitation complet. 1. Vous ne me croyez pas ? X avait son propre serveur d’impression. Il a été supprimé après que quelqu’un a [ajouté la prise en charge de Xprint à _glxgears_](http://bugs.freedesktop.org/show_bug.cgi?id=558). 2. C’était un interpréteur binaire pour ELF, COFF et a.out. ## La composition et la cohérence des fenêtres Composition et cohérence des fenêtres. Les développeurs ont appris à X la composition à travers l’extension Composite. Pour les choses simples, comme le bureau, la composition OpenGL est utilisable. Si vous voulez une couche utilisant l’accélération matérielle (comme la vidéo), cela devient un désastre complet. Cohérence des médias. Qu’est‐ce que c’est ? En termes simples... Votre fenêtre de navigateur ? C’est une fenêtre. Votre lecteur Flash sur YouTube ? Le lecteur Flash lui‐même, affichant la vidéo, est une sous‐fenêtre. Qu’est‐ce qui garde ces deux fenêtres synchronisées ? Absolument rien. Les événements sont gérés séparément et actuellement vous priez pour qu’ils ne soient pas traités à des moments trop éloignés. Ce qui explique pourquoi quand vous faites défiler une page _YouTube_, ou un autre site où une vidéo est jouée, parfois tout se sépare en morceaux. ## Les polices de caractères Les développeurs ont essayé d’apprendre au serveur X à utiliser les polices grâce à l’extension STSF. L’idée était de stocker les polices du côté du serveur, et de donner aux clients suffisamment d’informations pour qu’ils puissent générer l’agencement de la police tout seuls. Les informations nécessaires pour ça se sont révélées plus importantes que la taille de la police. Il a donc été décidé d’envoyer la police directement au client et de laisser ce dernier se débrouiller avec. ## La gestion des états (ou plutôt son absence) Absence d’états... En d’autres mots : X ne se souvient de rien ! 1. « Génère‐moi un fichier de configuration... En fait, utilise celui‐ci. » Pourquoi ? Finalement corrigé en faisant en sorte que le serveur X n’utilise qu’un seul fichier de configuration pour les exceptions, et qu’il connaisse et intègre des options par défaut sensées, ainsi que de l’auto‐détection. 2. Qui n’a jamais eu de problèmes avec le multi‐écran sous Linux ? Ou alors, qui n’a jamais vu la configuration de tous ses moniteurs disparaître après un redémarrage ? C’est de la faute de X, sauf si vous sauvegardez votre configuration dans `/etc/X11/xorg.conf.d/50-monitors.conf`, et *alors* il s’en souvient... Mais vous avez probablement dû écrire ça à la main. 3. Avec un peu d’optimisme, cela sera corrigé par la création de `libkscreen`, un « enrobage logiciel » *— wrapper —* pour `xrandr` se souvenant de l’emplacement de chaque écran grâce à son [EDID](http://en.wikipedia.org/wiki/EDID "Définition Wikipédia") qui est unique. 4. Depuis longtemps, et c’est peut‐être encore le cas, quand vous branchez un moniteur supplémentaire alors que l’écran primaire a une composition, il se peut qu’elle n’apparaisse pas sur celui nouvellement ajouté. Cela peut avoir été corrigé par RandR 1.4, mais l’auteur ne peut clairement affirmer si ce problème est résolu. ## L’arborescence des fenêtres L’arbre des fenêtres est un bazar complet. Avec X, tous les champs de saisie et boîtes de texte sont une fenêtre ayant comme parent la fenêtre contenante. C’est pourquoi personne ne comprend la fonction qui valide l’arbre des fenêtres. Les **vraies** (par exemple, pas Core X11) boîtes à outils graphiques *— toolkits —* ont jeté ce fonctionnement par la fenêtre depuis longtemps. Sans jeu de mots. ## Le compteur de pixels C’est un détail, mais aussi un reproche recevable... Avec X11, le compteur total de pixels est de 15 bits. En conséquence, le nombre maximal de pixels autorisé, tous affichages confondus, est de 32 768. À 100 ppp, cela fait un affichage de 8,3 mètres. Super... En comparaison, en revanche, Windows XP a 96 ppp. Mon téléphone a 320 ppp. Ajoutez de plus grandes définitions **et** des moniteurs multiples, et les choses deviennent vite hasardeuses. ## Tout est fenêtre Tout est *fenêtre* dans X. Il n’y a pas de différents types de fenêtre, juste « une fenêtre ». 1. Votre économiseur d’écran ? C’est une fenêtre qui a dit à X : 1. mets‐moi au-dessus de toutes les autres fenêtres, tout le temps ; 2. mets‐moi en plein écran ; 3. donne‐moi toutes les entrées utilisateur _— focus_. 2. Une fenêtre surgissante *— popup —* ? C’est une fenêtre qui a dit à X : 1. Mets‐moi **ici** ; 2. Donne‐moi toutes les entrées utilisateur _— focus_. 3. Problème ? Pour commencer : les fenêtres se contredisent. L’économiseur d’écran ne s’activera pas tant qu’il y aura une fenêtre surgissante à l’écran, car elles entrent en conflit. 4. Votre économiseur‐verrouilleur d’écran n’a probablement pas fait les liens avec toutes les bibliothèques pour gérer les touches multimédia... Le problème vient de la situation suivante : vous êtes en train de travailler chez vous, avec de la musique. Vous fermez le capot de votre portable pour le mettre en veille. Après cette opération, l’écran de verrouillage est la fenêtre active. Quand l’ordinateur est réactivé, la musique reprend aussitôt sur les haut‐parleurs, et il est plus facile pour vous de refermer le capot que de taper le mot de passe, ouvrir le lecteur multimédia pour le mettre en pause ou mettre l’ordinateur en muet. 5. Les développeurs ont essayé de corriger ce problème. Ils ont défini une extension, avec une théorie toute prête, mais quand est venu le moment de l’implémenter, ils ont constaté qu’elle briserait le fondement du modèle de X. C’est un problème depuis 26 ans, et ça le restera. Appréciez. ## Alors pourquoi pas X12, comme suite au vénérable X11 ? « Mais, Eric, si X11 est si mauvais, pourquoi ne pas faire X12, plutôt que de définir un nouveau protocole ? » Ils l’ont fait, techniquement, du moins : . Un des principaux problèmes rencontrés en conservant l’appellation _X_ est que quiconque s’occupant de X va vouloir avoir son mot à dire sur la version suivante. En l’appelant _Wayland_, ils (les développeurs) évitent ce problème. Personne ne s’en préoccupe. Cela peut être un projet différent, ils peuvent faire ce qu’ils veulent avec leur futur serveur d’affichage, les gens se souciant de X peuvent faire X12 de leur côté. # Les corrections de Wayland _Les corrections sont traitées dans l’ordre des « problèmes » de X11 listés ci‐dessus._ ## Tout le protocole est versionné Tout le protocole est versionné. Chaque auditeur *— listener —* reçoit exactement la version qu’il prend en charge, pas plus. Plus d’aléatoire. ## La gestion des entrées Le système d’entrées de Wayland ressemble beaucoup à XInput 2.2, moins toutes les cochonneries d’héritage et moins la relation maître‐esclave entre les entrées. Tout le monde reçoit un clavier virtuel, une souris virtuelle et une interface de tablette non virtuelle. Le cauchemar appelé *multitouch* (multi‐tactile) sera enfin réglé. Note de Daniel : « En tant qu’un des auteurs du _multitouch_, je me sens bien qualifié pour dire que c’est de la merde. » ## Absence d’API de « dessin » Wayland n’a aucune API de dessin, évitant ainsi de s’emmêler les pinceaux. Wayland veut recevoir des tampons remplis de pixels de la part des clients et, à part les vérifications de sécurité pour éviter qu’un client n’agisse sur la mémoire tampon *— buffer —* d’un autre, il se contrefiche de savoir comment les pixels sont arrivés là. Les clients contrôlent quels pixels sont dans quelles mémoires tampon, et ainsi ce qui sera affiché sera exactement ce que le client voulait. ## Minimalisme Wayland est minimal. Il n’y a pas de pseudo système d’exploitation surchargé contrôlant la carte graphique. Il n’y a pas une API vieille de 26 ans qui empêche les évolutions. Les clients se chargent du travail, ce qui est une bonne chose parce que les clients n’ont pas à maintenir une rétro‐compatibilité extrême. Qt5 a laissé tomber les classes de compatibilité avec Qt3, X doit toujours maintenir des choses écrites il y a 26 ans. Et les choses d’il y a 26 ans se mettent en travers du chemin des corrections de problèmes actuels. Note de Daniel : « Wayland est aussi non bloquant, ce qui fait que votre bureau entier n’arrêtera pas son rendu uniquement parce qu’un client est en train de faire une opération longue. Seul ce client arrêtera son rendu. » ## Composition La composition est requise sous Wayland. Ça ne veut pas dire que tout a besoin d’effets 3D ou de fenêtres molles. La composition veut dire que tout se fait sans scintillement, sans mise en pièce. La devise de Wayland est « chaque image est parfaite ». Chaque pixel est exactement ce qu’il doit être où il doit être, et là quand il doit y être — tel que demandé par le client. ## Les polices de caractères Les logiciels clients s’occupent des polices de caractères, comme ils le font déjà, en fait. ## Gestion du multi‐écran Le multi‐écran est un problème du client. Même chose en ce qui concerne les cartes graphiques multiples (Optimus). Wayland désire uniquement des mémoires tampons remplies avec des pixels, et qu’on lui dise où les afficher. Il ne se tracasse pas de comment ils sont apparus là. ## Plusieurs types de fenêtres À l’inverse de X, dans lequel tout était fenêtre, Wayland gère deux types de fenêtres différents. Les fenêtres de niveau supérieur, qui sont essentiellement des conteneurs de multiples tampons, et les fenêtres de sous‐niveau, principalement pour les lecteurs vidéo. Néanmoins, tout cela est maintenu cohérent, à l’opposé de X, en évitant les défauts de couleur et autres artefacts générés lorsque vous descendez sur les commentaires d’une vidéo YouTube pendant que celle‐ci est en cours de visionnage. ## Un autre système de positionnement de pixel Wayland ne gère pas les coordonnées globales, du moins, pas publiquement. Il gère des coordonnées relatives pour les surfaces. Le compteur de coordonnées de Wayland fait une taille de 31 bits, cela veut dire que chaque surface (c.‐à‐d. fenêtre) peut avoir une taille de 2 147 483 648 pixels. ## Une précaution de sécurité Pour des raisons de sécurité, votre écran de veille et de verrouillage fait partie du compositeur. Cela a pour effet bénéfique que votre compositeur (par exemple, KWin) comprend les touches multimédia, donc, vous pouvez mettre votre ordinateur en sourdine, même quand votre écran est verrouillé. # Quelques idées reçues sur X et Wayland ## X respecte la philosophie UNIX La philosophie Unix dit qu’il faut faire une seule chose et la faire bien. X gérait l’impression, les mémoires tampon et les polices, il avait sa propre bibliothèque graphique, il était un interpréteur binaire, parmi bien d’autres choses. Quelle est cette chose unique que X faisait et qu’il faisait bien ? ## X supporte la transparence réseau Faux. Ce n’est pas le cas. Core X et DRI-1 supportaient la transparence réseau. Plus personne ne les utilise. La mémoire partagée, DRI-2 et DRI-3000 ne supportent **pas** la transparence réseau, ils ne fonctionnent **pas** sur le réseau. De nos jours, X se résume à être un VNC synchrone et appauvri. S’il avait été fait différemment, c’est‐à‐dire asynchrone, alors nous pourrions peut‐être le faire fonctionner. Mais ça n’est pas le cas. Xlib est synchrone (et le mouvement vers XCB est lent), ce qui fait du réseautage un **cauchemar**. ## Les développeurs de Wayland recréent X11 car ils ne l’ont pas compris Faux. La plupart des développeurs de Wayland **sont** des ex‐développeurs de X11. Ils savent à quel point il est horrible. Ils savent où sont ses faiblesses. Ils veulent faire mieux que X11. ## Wayland nécessite la 3D Faux. Il nécessite la composition, mais ça n’est pas forcément de la 3D. Rien dans Wayland ne nécessite la 3D, il y a même un rendu logiciel utilisant la bibliothèque de manipulation d’images [*Pixman*](http://pixman.org/). ## Wayland ne fait pas de session à distance Faux. Wayland devrait être **meilleur** que X pour l’affichage à distance, cela étant en partie dû à sa nature asynchrone par conception. L’affichage distant de Wayland ressemblera probablement à une version plus performante de VNC. Un prototype existe déjà, et cela sans réfléchir sérieusement à la manière de l’améliorer. Nous pourrions sûrement faire mieux si nous avions essayé. ## Wayland casse la gestion des bureaux de tout le monde Toujours faux. Une fois que XWayland sera terminé et intégré, nous devrions avoir plus ou moins une compatibilité ascendante parfaite, parce que chaque application X reçoit son propre mini‐serveur X avec lequel elle peut dialoguer. Il y a un problème connu qui est lié aux transformations de fenêtres, parce que chaque application pense qu’elle est dans le coin supérieur droit de l’écran (youpi les coordonnées globales) et que chaque mini‐serveur X est verrouillé à la taille de la fenêtre de son client. # Quelques avantages génériques de Wayland ## Chaque image est parfaite Le but principal de Wayland est que quelle que soit la charge du système, quoi qu’il se passe, il ne doit pas y avoir de scintillements, de déchirures ou de flashs. Chaque image est présentée dans l’ordre correct et approprié (sauter des images est accepté, mais vous n’aurez pas l’image 199, suivie de la 205, suivie de la 200, parce qu’elles ont toutes été envoyées à peu près au même moment et que le serveur les a prises au hasard). Wayland sait dans quel ordre elles viennent, dans quel ordre il faut les afficher, et **quand** elles ont été affichées, car **tout** est associé à un horodatage. ## Wayland est minimal Nous avons appris à la dure ce qui arrive quand vous avez quelque chose qui fait beaucoup de choses et qui doit aussi maintenir la compatibilité ascendante —— nous nous mordons toujours les doigts pour des erreurs commises il y a 26 ans dans X. Laissons les clients gérer les choses, ils peuvent changer, ils peuvent casser autant de choses qu’ils veulent parce que ce sont eux qui doivent gérer les retombées de la casse. Nous aidons à rendre Wayland résistant au futur en réduisant la surface d’attaque des erreurs. ## Des _back‐ends_ spécifiques pour chaque matériel Je suis sûr que certains ont vu que le Raspberry Pi a reçu un _back‐end_ spécifique pour Wayland, et comme cela a permis de mieux tirer parti du matériel. Ce ne sera pas nécessaire à chaque fois, la plupart des matériels ne nécessiteront pas un _back‐end_ spécifique... Mais il est sûr que c’est sympa que ce soit disponible. Cela veut dire qu’on a la liberté, on a le choix de faire des adaptations spécifiques si on le désire. Ou, si on réalise en cours de route que le _back‐end_ principal a des défauts de conception, on peut le changer par un autre qui n’en a pas. ~Fin~

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