Réponses:
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:
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: