# Mir (serveur d'affichage)

Mir est un serveur d'affichage pour GNU/Linux développé par la société Canonical Ltd.. Il a été créé afin de remplacer X Window System (ou X11) pour la distribution Ubuntu$^,$$^,$. Son développement est arrêté en 2017.

## Histoire

En novembre 2010, Mark Shuttleworth a écrit sur son blog que l'avenir de Unity reposerait sur le serveur d'affichage (et protocole) Wayland et que celui-ci serait également en principe utilisé dans les versions mobiles d'Ubuntu. Pendant les 2 ans qui suivirent, Canonical rappela son intention d'intégrer Wayland pour gérer les aspects graphiques, mais sans concrétisation.
Le 21 février 2013, Canonical annonce le projet Ubuntu Touch, version d'Ubuntu destinée aux appareils mobiles et tactiles. La première version de Ubuntu Touch utilise SurfaceFlinger, qui est le serveur d'affichage d'Android. Il en résulte un nouveau projet nommé Mir, annoncé par Canonical le 4 mars 2013 après son développement en interne depuis juin 2012. Ce projet remplacerait à la fois SurfaceFlinger dans Ubuntu Touch et X dans la version bureau d'Ubuntu. Mir a été développé afin de permettre le développement de Unity 8, prochaine génération de l'interface utilisateur (ou shell) Unity.

## Développement

Les étapes publiques du développement de Mir :
* Ubuntu 13.10 : Mir est le nouveau serveur d'affichage par défaut sous Ubuntu Touch (pour smartphones uniquement) et permet d'afficher le nouveau shell Unity 8. La version bureau d'Ubuntu continue d'utiliser X.org (Implémentation libre du protocole X11).
* Ubuntu 14.04 LTS : Mir est utilisé par défaut sur Ubuntu Touch (pour les smartphones et les tablettes) et permet de faire fonctionner Unity 8. La version bureau d'Ubuntu continuera d'utiliser X.org.
* Ubuntu 14.10 : Unity 8 et Mir ne sont pas disponibles par défaut mais dans une version à part d'Ubuntu.
* Ubuntu 15.04 : Cette version conserve Unity 7 par défaut.
* Ubuntu 16.10 et 17.04 : Ces versions sont les premières à proposer le nouveau serveur d'affichage avec Unity 8, en option cependant, puisque Unity 7, au code plus éprouvé, restera installée dans cette distribution.
* Ubuntu 17.10 : Cette version utilise désormais Wayland par défaut.
Le 5 avril 2017, Mark Shuttleworth annonce que le développement de l'interface utilisateur Mir est arrêté. Néanmoins, le développement de Mir n'est pas abandonné, Canonical se recentrant sur ses activités cloud et Internet of Things (IoT).

## Buts à terme

En général, les développeurs ont les attributs suivants à l'esprit lors de l'élaboration du système :

### Fonctionnalité bien définie

Le système est développé en se basant sur des exigences et des cas d'utilisation. Les développeurs désirent éviter une situation de ballonnement de fonctionnalités inutiles avec le système qui évolue dans le temps sans un réel besoin pour ces fonctionnalités.

### Efficace

Le système doit satisfaire toutes les exigences de manière aussi efficace que possible, en mettant l'accent sur les cycles CPU, les cycles GPU, la mémoire et la consommation d'énergie. Les développeurs veulent établir un ensemble de critères qui font en sorte que le système soit à la hauteur de cet attribut.

### Testé

Le système doit être testé autant que possible. Les développeurs prennent en compte les 3 niveaux de tests détaillés (tests unitaire, tests d'intégration et tests d'acceptation) afin d'assurer une haute qualité et un système fonctionnel. De plus, tout développement ne devra commencer uniquement lorsqu'un test d'acceptation bien défini est disponible. Toute fonctionnalité qui ne peut pas être testée, ne peut être mise en œuvre avec un haut niveau de qualité.

### Polyvalent & Flexible

Le système doit être facilement adaptable et portable vers différentes plateformes et différents cas d'utilisation (dans le cas de fonctionnalités bien définies, comme cité précédemment). Le système fonctionnant sur un appareil mobile exposant uniquement une fonctionnalité limitée comme un compositeur au niveau du système ne doit pas être un cas particulier, mais une exigence facilement remplie par le système.

### Sécurisé

Les développeurs veulent éviter l'exposition de toute sorte de protocole privilégié aux applications clientes. Notamment, ils veulent empêcher les applications (malicieuses) clientes d'usurpation (spoofing) sur le flux d’événement d'entrée ou la capture du contenu de l'écran sans au moins une étape d'authentification/autorisation au préalable. À cette fin, l'ensemble des opérations non-privilégiées est limité.

### Intégration de Toolkit & Support d'application X héritée

La bibliothèque cliente de Mir devra être facile à intégrer avec les toolkits existants. Les auteurs d'application qui s'appuient sur Qt/Qml, GTK+3, XUL, SDL, etc. ne doivent pas être tenus d'effectuer le portage supplémentaire tandis que les développeurs de Mir travailleront sur la fourniture d'une intégration de Mir pour les toolkits les plus importants. Cependant, certaines applications héritées ne seront pas en mesure de faire entièrement la transition de X à Mir, c'est pour cela qu'un serveur X "déraciné" de la session sera intégré à Mir. Cela agit, à la demande, comme une couche de compatibilité entre les applications X héritées et l'instance Unity/Mir au niveau de la session.

## Architecture

Mir et Wayland sont très différents. Certes, la démonstration de Mir utilise, comme celle de Wayland, les technologies récentes du noyau Linux comme le DRM, KMS et GEM, dans le but de fournir un serveur d'affichage minimal, léger et performant. Wayland n'est qu'un protocole alors que Mir se veut à la fois protocole, compositeur et shell. Cependant, d'après les développeurs de Mir, Mir pourrait émuler Wayland avec la bibliothèque Wayland (libwayland-client et libwayland-server) dans Mir.

### Compositeur

Le compositeur sert à présenter la « scène finale » composée de toutes les applications et les surfaces du shell (les fenêtres) sur l'écran ou les écrans. Il contient un moteur de rendu appliquant les effets visuels souhaités (par exemple ombres portées) pour les surfaces individuelles. Le compositeur est synchronisé à vblank (la synchronisation verticale) afin d'éviter des déchirures dans l'image (en anglais tearing) et de gaspiller des cycles.

### Gestion des entrées

Le système devra supporter les mesures de lecture (les coordonnées, les clés, les valeurs d'accélération) à partir de périphériques d'entrée arbitraires (comme clavier et souris), le pré-traitement du flux d'évènement, la présentation à une chaîne de filtre côté serveur (par exemple, pour supporter la reconnaissance gestuelle ou l’interaction du clavier au niveau du shell) et enfin les livrer aux applications clientes. Les développeurs veulent que la pile d'entrée (input stack) soit du côté serveur afin de supporter la lecture de périphériques de saisie arbitraires, en mettant l'accent sur le sous-système evdev du noyau Linux.
La pile d'entrée vise une consommation faible d'énergie. Plus important encore, elle doit réduire la bande passante utilisée pour transmettre les événements aux applications clientes afin de correspondre à vblank et tenir compte de la perte de l'échantillonnage au moyen de prédire les événements futurs de mouvement.
Les développeurs de Mir ont choisi celle intégrée dans Android pour son efficacité, sa conception claire et sa flexibilité.

### Gestion des sorties

Le système doit le contrôle des dispositifs d'affichage physiques connectés, sans hypothèse sur le type de connecteur. Il doit aussi permettre composants du shell de réagir aux changements dans les dispositifs d'affichage physiques, entre autres pour gérer le multi-écrans et les rotations d'un ou plusieurs d'entre eux, et pour s'adapter à tous les facteurs de forme (convergence de gestion entre les terminaux).
Le support de plusieurs GPU de caractéristiques différentes dans le même système fait partie du cahier des charges, ce qui idéalement permettrait d'amorcer (booter) un même Linux externe (sur SSD en USB, par exemple) sur des machines munies de cartes graphiques d'architecture différentes, le système détectant au boot celle(s) utilisée(s) et chargeant au vol les pilotes appropriés.
Plusieurs ordinateurs portables haut de gamme ayant une carte graphique dédiée alimentant les jeux ou des applications 3D intensives disposent aussi d'une solution graphique embarquée plus économe en énergie pour les activités de bureautique (voir Optimus). Il faut donc pouvoir basculer facilement entre les 2 GPU et bouger les applications et leurs contextes EGL respectifs d'un GPU à un autre.

### Gestion des applications

Les applications doivent être considérées comme des « citoyens de première classe » dans ce serveur d'affichage. Une application est nommée et se compose d'un nombre arbitraire de surfaces. Les composants du shell peuvent accéder à l'ensemble des applications en cours d'utilisation et opérer sur le dessus de la collection pour fournir le shell. (par exemple la fonctionnalité Alt-Tab)
Le shell ou l'interface utilisateur au niveau du système, sera un « citoyen de première classe » du serveur d'affichage, au moins en termes d'interfaces bien définies qui sont utilisées pour communiquer dans les deux sens entre le shell et les autres composants du serveur d'affichage.

### Échange de données inter-applications

L'échange de données entre les applications en cours d'exécution est très limité avec X. À l'heure actuelle, il y a un support basique des opérations de « copier-coller » et de « glisser-déposer » mais l'expérience est très limitée et peu fonctionnelle. Pour cette raison, les développeurs de Mir désirent que le serveur d'affichage fournisse une méthode avancée pour que les applications puissent échanger des données arbitraires, avec une expérience utilisateur transparente lors de l'initiation et la mise en œuvre de l'échange de données réelles.

## Controverse

En mars 2013, Mir fut choisi par Canonical Ltd. pour remplacer la technologie X dans la distribution Ubuntu. Précédemment, en 2010, il avait été annoncé que Wayland serait utilisé. Il y eut dès lors des échanges par écrit, pour s'y opposer ou pour dissiper des malentendus, de la part de personnes impliquées dans des projets similaires (Wayland, notamment) ou affectées par cette décision$^,$$^,$$^,$$^,$.
En septembre 2013, Intel décidait de ne pas assurer le support d'XMir et de supprimer de ses pilotes graphiques officiels les fractions de code relatives à ce projet: l'équipe de gestion d'Intel avait décidé de ne pas supporter ni de cautionner ((en) condone) le choix opéré par Canonical$^,$.