L’organisation de Sailfish OS
Maintenant que Jolla a annoncé que Sailfish OS allait utiliser Wayland, il est intéressant de regarder pourquoi ce choix technique a été fait.
Un monde de robots
Il ne faut pas se voiler la face, Android domine actuellement le marché du mobile, et il est devenu une norme pour ce marché. La plupart des développements, tant matériels que logiciels, gravitent autour de cet OS. Même si les créateurs d’applications hésitent parfois à cibler cette plateforme, les constructeurs de matériel ont très souvent tendance à ne supporter qu’Android, un peu comme avec Windows dans le monde des PC.
Mais à la différence de l’OS aux fenêtres multicolores, Android est Open-source, ce qui a permis la création d’une grande communauté. Cette dernière, faite d’entreprises, mais aussi de développeurs enthousiastes a certainement contribué à l’évolution et à l’adoption de l’OS. Mais elle permet aussi d’en faire profiter le monde Linux.
Car Android, en plus d’avoir la bonne idée d’être Open-Source, partage aussi certains composants avec Linux, comme le noyau, ou encore le compilateur. Cependant, il est tout de même assez éloigné, et il est difficile de faire cohabiter les deux mondes. C’est pourtant ce qu’à fait le désormais célèbre Carsten Munk, qui a créé une couche d’adaptation, permettant de relier les drivers écrits pour Android à un système Linux classique comme Mer. Cette libhybris aura ensuite été reprise et améliorée par Canonical, et est maintenant aussi utilisée par OpenWebOS.
Un lourd passé
Jolla a d’abord commencé par travailler avec une base X et Qt 4, comme celle dans le N9. X est un logiciel bien connu du monde de Linux, car utilisé par toutes les distributions, et souvent source de bugs.
Il faut dire que X a une longue histoire. Développé lorsque la plupart des ordinateurs étaient des mainframes Unix, et les écrans composés que de quelques milliers de pixels, X ensuite été adapté et étendu pour s’adapter à l’informatique moderne. Typiquement, une extension largement utilisée est la capacité à dessiner des fenêtres directement avec OpenGL. Cette capacité n’a pas pu être réalisée directement, mais uniquement sur l’aspect rendu.
X conserve donc toutes les informations sur la position et la taille des fenêtres en mémoire, non visible, pour uniquement gérer les interactions avec la souris par exemple, et dessine via OpenGL les fenêtres via le GPU. Ce qui fait que la représentation des fenêtres est dédoublée. Il est alors impossible d’effectuer des rotations aux fenêtres, car seul la surface OpenGL peut tourner, et la représentation interne ne peut pas. Si l’on faisait tourner la surface uniquement, les coordonnées ne vont plus correspondre avec la représentation interne, et l’interaction avec la fenêtre, impossible.
La complexité que X a reçu au fil des ans en fait aussi un dinosaure buggué, bourré de lignes de codes qui sont probablement obsolètes, et de bugs. De plus, cette complexité fait qu’il est assez difficile d’obtenir des performances correctes sur du matériel mobile par exemple.
C’est pourquoi Wayland a été créé. Pour offrir une solution simple et extensible pour l’affichage. Cette simplicité permettrait d’avoir de meilleures performances sur un matériel limité, et l’extensibilité permettrait une certaine liberté dans les implémentations.
Et c’est bien ces deux aspects qui ont séduit le développeur de libhybris, qui s’est contenté de traduire les fonctions utilisés par Android pour partager des surfaces OpenGL en une extension Wayland.
Voici une vidéo étrange, où on voit des fenêtres wayland dans un environnement de type Quake.
S’adapter, vite !
Le support de Wayland par libhybris, et Qt5 n’étaient qu’un projet de recherche, et la base Qt4 + X11 devait être la base prévue pour le lancement, mais depuis le lancement de Jolla, de nombreuses choses se sont passées.
Premièrement, Wayland a été publié en version stable après plusieurs années de travail, et Qt 5 a aussi été publié en version stable, un peu avant cette année. Le support de Wayland par Qt est aussi considéré stable avec la sortie de Qt 5.1. Avec l’apport de Canonical, la libhybris s’est aussi améliorée. Des catastrophes se sont aussi passés, comme la fermeture de STE.
Alors, il n’y a pas beaucoup eu de choix pour Jolla: s’adapter, et vite ! Rapidement, la solution X11 et Qt4, qui semblait robuste au début, commença a perdre tous ses avantages, et la solution Qt 5 et Wayland s’imposa d’elle même.
Alors ils ont décidé de migrer toute leur architecture vers Qt 5, comme ce qui a été vu durant le travail effectué sur Nemo, afin qu’elle soit plus parée pour le futur, plus «futureproof».
Cette migration semble bien être la norme maintenant, car Canonical essaie aussi de se débarrasser de X dans Ubuntu, en utilisant leur propre solution Mir (qui est très proche de Wayland), et Samsung et Intel considèrent aussi l’adoption de Wayland dans Tizen.
PS: Je n’ai volontairement pas parlé de X11, de Xorg, de XFree86, ou encore des protocoles. L’histoire aurait été bien plus longue, et il est possible que j’ai fait des imprécisions, juste pour la simplifier un peu.
PPS: Une super vidéo technique comme je les aime: pourquoi Wayland (conférence)
