Mir (serveur d'affichage)
Pour les articles homonymes, voir Mir.
Cet article est une ébauche concernant un logiciel libre.
Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.
Le fond de cet article sur l'informatique est à vérifier ().
Améliorez-le ou discutez des points à vérifier. Si vous venez d’apposer le bandeau, merci d’indiquer ici les points à vérifier.
| Créateur | Canonical Ltd. |
|---|---|
| Développé par | Canonical Ltd. |
| Première version | |
| Dernière version | 0.18.0 () |
| Version avancée | 0.19.0 |
| Dépôt | github.com/MirServer/mir |
| Écrit en | C++ |
| Système d'exploitation | Linux |
| Environnement | Linux |
| Type | Système de fenêtrage |
| Licence | GNU/GPL v3 (serveur)[1], GNU/LGPLv3 (client) |
| Site web | wiki.ubuntu.com/Mir unity.ubuntu.com/Mir launchpad.net/mir |
Mir est un serveur d'affichage pour GNU/Linux développé par la société Canonical Ltd. Il avait été créé afin de remplacer l'actuel X Window System (ou X11) pour la distribution Ubuntu[2],[3],[4].
Histoire[modifier | modifier le code]
En , Mark Shuttleworth a écrit sur son blog que l'avenir de Unity reposerait sur le serveur d'affichage (et protocole) Wayland[5] 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 , 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 après son développement en interne depuis . 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[2].
Développement[modifier | modifier le code]
Les étapes publiques du développement de Mir[6] :
- 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[7].
- Ubuntu 17.10 : Cette version utilise désormais Wayland par défaut[8].
Le , 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)[9].
Buts à terme[modifier | modifier le code]
En général, les développeurs ont les attributs suivants à l'esprit lors de l'élaboration du système :
Fonctionnalité bien définie[modifier | modifier le code]
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[Lesquelles ?].
Efficace[modifier | modifier le code]
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é[modifier | modifier le code]
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é[pas clair].
Polyvalent & Flexible[modifier | modifier le code]
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é[modifier | modifier le code]
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[modifier | modifier le code]
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[modifier | modifier le code]
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[10].
Compositeur[modifier | modifier le code]
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[modifier | modifier le code]
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[Quoi ?].
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[modifier | modifier le code]
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[modifier | modifier le code]
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[modifier | modifier le code]
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[modifier | modifier le code]
En , 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é[5]. 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[11],[12],[13],[14],[15].
En , 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[16],[17].
Notes et références[modifier | modifier le code]
- « Documentation de Mir », unity.ubuntu.com (consulté le )
- « MirSpec – Ubuntu Wiki », Wiki.ubuntu.com (consulté le )
- « Canonical reveals plans to launch Mir display server – Update – The H Open: News and Features », H-online.com, (consulté le )
- Jon Brodkin, « Ubuntu dumps X window system, creates replacement for PC and mobile », Ars Technica, (consulté le )
- Mark Shuttleworth, « Unity on Wayland », : « The next major transition for Unity will be to deliver it on Wayland… »
- « Ubuntu graphic stack roadmap update », Lists.ubuntu.com, (consulté le )
- « Ubuntu 16.04 supportera le système de fichiers ZFS et l'API Vulkan », sur www.nextinpact.com (consulté le )
- « Ubuntu 17.10 Release Notes »
- Canonical, « Growing Ubuntu for cloud and IoT, rather than phone and convergence », sur Ubuntu Insights (consulté le )
- Robert Ancell, « Mir Specifications », : « We are developing a next generation display server known as Mir. »
- Michael Larabel, « Upstream X/Wayland Developers Bash Canonical, Mir », : « 'I'm just irritated that this means more work for us, more work for upstream developers, more work for toolkits, more work for hardware vendors…' »
- Michael Larabel, « A Note To Canonical: "Don't Piss On Wayland" »,
- Martin Gräßlin, maintainer of KWin, the KDE window manager, « War is Peace », : « Will KWin support Mir? No! »
- David Edmundson, author of KDE greeter library used by LightDM used by Ubuntu, « KDE, LightDM and the Mir Kerfuffle », : « If you know for 6 months that you're not going to do something you said you would it's rude not to tell people. »
- Michael Larabel, « GNOME Will Move Full-Speed With Wayland Support », : « What's GNOME doing about Mir? They're laying out plans right now to move hard and fast with Wayland support! »
- (en) Intel, « xf86-video-intel 2.99.902 snapshot », Chris Wilson, (consulté le )
- (en) Phoronix, « Intel Reverts Plans, Will Not Support Ubuntu's XMir », Michael Larabel, (consulté le )
