Mir (serveur d'affichage)

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher
Mir
Développeur Canonical Ltd.
Première version Février 2013
Dernière version 0.3.0 (18 juin 2014)
Version avancée 0.4.0
Écrit en C++
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 a é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 novembre 2010, Mark Shuttleworth a écrit sur son blog que l'avenir de Unity reposerait sur le serveur d'affichage (et protocole) Wayland[5]. Il était également prévu d'être utilisé dans les versions mobiles d'Ubuntu. Au cours des 2 années qui suivirent cette annonce, Canonical a exprimé son intention d'intégrer Wayland pour gérer les aspects graphiques, mais ces plans ne se sont jamais concrétisés. Le 21 février 2013, Canonical a annoncé le projet Ubuntu Touch, une version d'Ubuntu destinée aux appareils mobiles et tactiles. La première version de Ubuntu Touch utilise SurfaceFlinger, le serveur d'affichage d'Android. Finalement, cela aboutit à l'annonce d'un nouveau projet, Mir, qui a été annoncé par Canonical le 4 mars 2013 après avoir été développé en interne depuis juin 2012. Il remplacera SurfaceFlinger sur Ubuntu Touch et X sur la version bureau d'Ubuntu. Mir a été développé afin de permettre le développement de Unity 8, la 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 : La version bureau d'Ubuntu devrait voir Unity 8 fonctionner sur un serveur Mir natif qui inclut le support d'un serveur X déraciné pour les applications X héritées et ne pouvant fonctionner sous Mir.

Ubuntu 14.10 devrait être la première version à profiter pleinement de ce nouveau serveur d'affichage.

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.

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é.

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, SDLetc. ne doivent pas être tenu 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 tout-en-un : Mir est à la fois un protocole, un compositeur et un shell. Cependant, d'après les développeurs de Mir, Mir peut utiliser ce protocole et ainsi « parler » Wayland. Pour cela, il suffit juste d'implémenter la bibliothèque Wayland (libwayland-client et libwayland-server) dans Mir[7].

Schéma qui représente l'architecture du serveur d'affichage Mir.

Compositeur[modifier | modifier le code]

Le compositeur est chargé de présenter la « scène finale » composée de toutes les applications et les surfaces du shell (les fenêtres) sur l'écran. Il contient un moteur de rendu qui prend soin d'appliquer des effets (par exemple, les 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, le 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 (par exemple, le clavier et la 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 (en anglais, input stack) soit du côté serveur afin d'être flexible puisqu'elle devra supporter la lecture des périphériques de saisie arbitraire, en mettant l'accent sur le sous-système evdev du noyau Linux.

La pile d'entrée doit être aussi efficace que possible en ce qui concerne la consommation d'énergie. Plus important encore, il faut être en mesure de diminuer la bande passante de la propagation des événements aux applications clientes pour 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 inclue dans Android pour son efficacité, sa conception claire et sa flexibilité.

Ce schéma représente une pile d'affichage complète basée sur Mir.

Gestion des sorties[modifier | modifier le code]

Le système devra supporter le contrôle des dispositifs d'affichage physiques connectés, sans assumer un certain type de connecteur. En plus de cela, le système doit prévoir des moyens pour que les composants du shell réagissent à des changements dans la configuration des dispositifs d'affichage physiques pour supporter des cas d'utilisation multi-écrans et pour supporter une transition en douceur entre les différents facteurs de forme. (On parle de la convergence entre les terminaux)

Un autre aspect important de fonctionnalité est le support de plusieurs GPU avec des caractéristiques différentes dans le même système. Les 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 sur puce pour les scénarios de faible consommation d'énergie. Il faut donc être en mesure de 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 terme d'interfaces bien définies qui sont utilisées pour communiquer dans les 2 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 mars 2013, Mir a été choisi par Canonical Ltd. comme le remplacement de la technologie X dans la distribution Ubuntu. Précédemment, en 2010, il a été annoncé que Wayland serait utilisé[5]. Il y a eu des messages écrits pour s'y opposer ou pour clarifier les malentendus, par les personnes dirigeant d'autres projets similaires (Wayland) ou affectés par cette décision[8],[9],[10],[11],[12].

En septembre 2013, Intel a décidé de ne pas assurer le support d'XMir et de supprimer les fractions de code relatives à ce projet de ses pilotes graphiques officiels. L'équipe de gestion d'Intel a en effet décidé ni de supporter, ni de « tolérer » ((en) condone) les choix que Canonical a pris[13],[14].

Notes et références[modifier | modifier le code]

  1. « Documentation de Mir », unity.ubuntu.com (consulté le 2014-04-22)
  2. a et b « MirSpec – Ubuntu Wiki », Wiki.ubuntu.com (consulté le 2013-03-06)
  3. « Canonical reveals plans to launch Mir display server – Update – The H Open: News and Features », H-online.com,‎ 2013-02-24 (consulté le 2013-03-06)
  4. Jon Brodkin, « Ubuntu dumps X window system, creates replacement for PC and mobile », Ars Technica,‎ 2012-05-17 (consulté le 2013-03-06)
  5. a et b Mark Shuttleworth, « Unity on Wayland »,‎ 2010-11-04 : « The next major transition for Unity will be to deliver it on Wayland.... »
  6. « Ubuntu graphic stack roadmap update », Lists.ubuntu.com,‎ 2013-06-26 (consulté le 2013-07-17)
  7. Robert Ancell, « Mir Specifications »,‎ 2013-03-04 : « We are developing a next generation display server known as Mir. »
  8. Michael Larabel, « Upstream X/Wayland Developers Bash Canonical, Mir »,‎ 2013-03-04 : « '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…' »
  9. Michael Larabel, « A Note To Canonical: "Don't Piss On Wayland" »,‎ 2013-03-05
  10. Martin Gräßlin, maintainer of KWin, the KDE window manager, « War is Peace »,‎ 2013-03-08 : « Will KWin support Mir? No! »
  11. David Edmundson, author of KDE greeter library used by LightDM used by Ubuntu, « KDE, LightDM and the Mir Kerfuffle »,‎ 2013-03-12 : « 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. »
  12. Michael Larabel, « GNOME Will Move Full-Speed With Wayland Support »,‎ 2013-03-13 : « What's GNOME doing about Mir? They're laying out plans right now to move hard and fast with Wayland support! »
  13. (en) Intel, « xf86-video-intel 2.99.902 snapshot », Chris Wilson,‎ 2013-09-07 (consulté le 2013-09-08)
  14. (en) Phoronix, « Intel Reverts Plans, Will Not Support Ubuntu's XMir », Michael Larabel,‎ 2013-09-07 (consulté le 2013-09-08)

Voir aussi[modifier | modifier le code]

Articles connexes[modifier | modifier le code]

Liens externes[modifier | modifier le code]