Pourquoi Canonical a-t-il choisi Mir plutôt que Wayland comme serveur d'affichage?

J'aime savoir quels sont les avantages de Mir.

Pourquoi pas Wayland / Weston?

Une clarification évidente d'abord: Wayland est une définition de protocole qui définit comment une application cliente doit parler à un composant compositeur. Il touche des domaines tels que la création / destruction de surfaces, l'allocation / la gestion de tampons graphiques, la gestion des événements d'entrée et un prototype approximatif pour l'intégration des composants de la coque. Cependant, notre évaluation de la définition du protocole a révélé que le protocole Wayland ne répond pas à nos exigences. Premièrement, nous visons une gestion des événements d'entrée plus extensible qui prend en compte les développements futurs tels que les périphériques d'entrée 3D (par exemple Leap Motion). Veuillez noter cependant que la gestion des événements d'entrée de Wayland ne souffre pas des problèmes de sécurité introduits par la sémantique de gestion des événements d'entrée de X (merci à Daniel Stone et Kristian Høgsberg de l'avoir signalé). En ce qui concerne les cas d'utilisation mobiles, nous pensons que la gestion des méthodes d'entrée devrait également se refléter dans le protocole du serveur d'affichage. Comme autre exemple, nous considérons les parties d'intégration de shell du protocole comme privilégiées et nous préférons éviter d'avoir une sorte de comportement de shell défini dans le protocole face au client.

Cependant, nous pensons toujours que la tentative de Wayland de standardiser la communication entre les clients et le composant serveur d'affichage est très raisonnable et utile, mais en raison de nos différentes exigences, nous avons décidé d'opter pour l'architecture suivante par rapport à l'intégration de protocole:

Un noyau interne indépendant du protocole qui est extrêmement bien défini, bien testé et portable. Un shell externe avec un pare-feu frontal qui nous permet de porter notre serveur d'affichage sur des piles graphiques arbitraires et de le lier à plusieurs protocoles.

En résumé, nous n'avons pas choisi Wayland / Weston comme base pour offrir une expérience utilisateur de nouvelle génération car elle ne répond pas complètement à nos exigences. De plus, avec notre approche indépendante du protocole et de la plate-forme, nous pouvons nous assurer que nous atteignons notre objectif d'une expérience utilisateur cohérente et belle sur toutes les plates-formes et les facteurs de forme des appareils. Cependant, la prise en charge de Wayland pourrait être ajoutée soit en fournissant une implémentation frontend spécifique à Wayland pour notre serveur d'affichage, soit en fournissant une implémentation côté client de libwayland qui parle finalement à Mir.

Il y a une discussion plus détaillée ici: https://wiki.ubuntu.com/Mir/Spec?action=show&redirect=MirSpec

Et de l'architecte technique Mir:

http://samohtv.wordpress.com/2013/03/04/mir-an-outpost-envisioned-as-a-new-home/

Plus d'information:

• http://blog.cooperteam.net/2013/03/artistic-differences.html
• http://blog.cooperteam.net/2013/03/mir-and-you.html
• http://blog.cooperteam.net/2013/03/for-posterity.html

Jono Bacon sur ses questions et réponses a répondu à plusieurs reprises. Sa dernière réponse est ici:

http://www.youtube.com/watch?v=6Oa2psAewtg&feature=share&t=56m36s

D'après ce que j'ai recueilli auprès de personnes comme les questions-réponses de Jono et les commentaires de Popey sur Linux Unplugged, les points peuvent être résumés comme suit:

1. Wayland en fait trop. Avoir des fonctionnalités perpétuellement inutilisées dans votre pile logicielle est une mauvaise conception logicielle.
2. L'équipe de Wayland ne serait pas assez flexible pour offrir une version éviscérée de Wayland pour s'adapter de manière adéquate et respectueuse.
3. Mir est à Wayland, ce que LightDM est à GDM / KDM.
4. Ubuntu a des délais très serrés dont ils ont besoin pour rencontrer les fabricants de téléphones et autres. La maîtrise d'un projet facilite l'infusion de ressources supplémentaires pour garantir le respect de ces délais.
5. Bien que je ne pense pas que cette raison soit venue officiellement du canonique, et n'est donc que de la spéculation de ma part, au moment où la décision a été prise, Wayland ne semblait pas se déplacer assez rapidement sur le marché, et la technologie Android existante semblait comme une base plus appropriée pour lancer leur produit.