Démarrer le serveur X et proposer une interface graphique fonctionnelle : encore un effort pour l’open source.
Mes premiers pas avec Linux remontent à ma période d’étudiant (sur une idée de mon copain Laurent) en 1998. Il s’agissait d’installer une Red Hat afin de faire du développement Web. Malheureusement pour nous, son vieux PC de l’époque (et surtout son lecteur de CD pas-standard-pas-IDE) n’avait jamais voulu reconnaître le CD qui était dans le lecteur. Nous nous étions donc résigné à nous tourner vers un IIS sous Windows 98.
C’est au cours de l’année que je réussis à démarrer une slackware 3.0 (fournie par mon copain Christophe, salut Christophe !) qui m’amenait à un shell en mode texte. Ici, pas de graphique, juste du texte.
Ce n’est que 6 mois plus tard que je fis connaissance de mon mentor Linuxien (salut Baptiste !). Non content d’installer mon Linux en dual-boot avec Windows - à l’époque, ça restait quand même indispensable pour mes études - je configurais également mon serveur X sur une RedHat 5.2. J’avais d’ailleurs tellement bien oeuvré pour faire fonctionner tout ceci que j’avais fait une démonstration dans un amphi lors d’une install party avec configuration d’une Matrox G200 en mode 2D 16 millions de couleur en lieu et place du mode 16 couleurs.
Avec le recul, on prend mieux la mesure des progrès qui ont été fait. Aujourd’hui, toute distribution est au moins en mesure de démarrer le serveur X et de proposer une interface graphique fonctionnelle.
Néanmoins, cette situation n’est pas encore parfaite et certains points sont toujours en cours d’amélioration.
__Xorg/XFree86__
Il est impossible de parler d’interface graphique sous Linux sans évoquer le serveur Xorg. Ce projet trouve son origine dans un conflit au sein des équipes de XFree86 pour un changement de licence. Changement qui fut également très mal accueilli par les différents acteurs du libre [1]. Il faut avouer que la situation était de toute façon bloquée : refus des contributions externes, conflits de personnes, manque de modularité du projet, etc. Ce fork a donc relancé une situation qui se dégradait et où l’effort d’intégration des distributions devenait de plus en plus important. En effet, auparavant, le projet était géré sous la forme d’un seul gros bloc : une simple mise à jour de pilote impliquait une attente de release complète, souvent de plusieurs mois. Autre inconvénient, le serveur X venait accompagné d’utilitaires d’un autre temps dont la plupart des distributions modernes n’avait plus besoin : des xterm, xeyes, xpdf, xcalc ou autre xclock.
La première version de ce fork fut donc Xorg X11R6.7.0 (une copie de XFree86 4.4 RC2 - dernière version utilisant l’ancienne licence [2] - suivie très rapidement de la version X11R6.8.0. Cette dernière apportait des fonctionnalités de gestion matériel de l’affichage 2D et notamment le support des transparences, ombrages etc.
Néanmoins, l’un des travaux les plus important de Xorg fut la modularisation du serveur X. Ce travail s’est fait au moment de la sortie simultanée des versions X11R6.9.0 et X11R7.0.0, le premier se basant toujours sur l’ancien système de packaging maison de XFree86, le second étant modularisé à l’aide des outils GNU/autotools.
Pourquoi ce changement fut-il important ? Tout d’abord pour moderniser le système de packaging du serveur X. Mais surtout, il fut le passage du système de développement cathédrale au système de développement du bazard. Le système de développement cathédrale est très long avec une vision du code une fois seulement les changements terminés et de grandes difficultés pour inclure des contributions externes. Tous les logiciels propriétaires fonctionnent sur ce principe et quelques logiciels libres procédant de la même manière comme GCC ou généralement les logiciels opensource portés par une société : Firefox, openoffice.org, MySQL etc. Le système de développement du bazard est très ouvert et très décentralisé avec une acceptation beaucoup plus large des contributions. Un exemple de développement célèbre en mode bazard est Linux.
Un autre avantage de la modularisation de Xorg était la sortie des drivers qui pouvait se faire de manière complètement décorrélé de la sortie du serveur X. Xorg apportant ainsi plus de souplesse aux équipes en charge du développement des drivers 3D et autres utilitaires de gestion des fonts du système.
Depuis, les versions se sont enchaînées : X11R7.1, 7.2 et 7.3 chacune avec son lot d’améliorations et de nouveautés : accélération de l’affichage 2D à base d’openGL pour la 7.1, branchement hotplug dans la 7.3. Paradoxalement, l’accélération 2D (sans effet 3D) et toujours en travaux. La version 7.4 devrait améliorer les choses au travers du support de EXA.
A remarquer que depuis la modularisation, la tendance est de parler directement des versions de Xserver, la version 1.5 correspondant par exemple à X11R7.4.
__Les problèmes dans le graphique sous Linux__
Globalement, la situation n’est pas parfaite mais - point important - ça marche ! Autre point important, les choses bougent beaucoup en ce moment ! Dans ce qui va suivre, je vais essayer de vous présenter les travaux en cours avec les différents axes d’amélioration.
_(presque) Pas de gestion 3D opensource (pour l’instant)_
Le support opensource est encore très limité pour la gestion des cartes graphiques sous Linux. En effet, il y a peu, les principaux acteurs du monde graphiques ne fournissaient qu’une implémentation des pilotes 2D (voir rien du tout) et des implémentations propriétaires de l’accélération 3D OpenGL. En effet :
- ATI fournit un driver propriétaire 3D mais pas de pilote 2D libre.
- Nvidia fournit un binaire fermé mais propose un driver 2D libre.
- VIA fournit des drivers opensource pour une partie de ses cartes mais avec un temps d’attente conséquent, voir aucun support.
Seul Intel jouait jusque là totalement la carte de l’ouverture en sponsorisant le fonctionnement de la fondation Xorg depuis plusieurs années et en employant certains contributeurs importants (notamment Keith Packard).
En quoi est-ce un problème dans la mesure où une solution (propriétaire) existe ? Je vais essayer d’y répondre en soulignant les points suivants :
- Incompatibilité entre les licences des drivers et les distributions linux.
- En cas de problème sur un pilote, vous êtes soumis au bon vouloir du constructeur (Nvidia ne corrige pas un bug de 2004 qui se révèle être une faille de sécurité en octobre 2006 [7]).
- Le support du matériel n’est pas garanti. Si en plus de ça vous utilisez un PowerPC, vous risquez de vous retrouver bien seul face à vos problèmes.
- Lorsqu’un driver propriétaire à des problèmes de sécurité, vous n’avez aucun moyen de corriger le problème.
Enfin notons que ces drivers sont dans un état très particulier vis à vis de la GPL : en effet, il est interdit par cette licence de lier un logiciel libre (Linux) avec un logiciel propriétaire (pilote 3D). Sachez toutefois qu’ils sont tolérés par les principaux contributeurs du kernel pour des raisons pragmatique. L’interdiction impliquerait l’absence de solution - Linus Torvald a plusieurs fois exprimé sont opinion à ce sujet - Ce logiciel existe en dehors de Linux. Le driver a d’ailleurs été porté à partir des drivers Windows avec lequel il partage une grosse partie du code.
MAIS - bonne nouvelle - tout ceci est train de changer ! Notamment depuis le rachat d’ATI par AMD. AMD a commencé à libérer les spécifications de leurs matériels il y a un peu plus d’un an. On commence donc à voir des drivers opensource fonctionnel [4]. Du côté de Nvidia, un groupe très organisé de hacker a également commencé un travail de reverse engeneering sur les spécifications des cartes Nvidia avec le début d’écriture d’un pilote (projet nouveau [5]). VIA, de son côté, a démarré un site qui devrait servir de portail pour proposer des pilotes libre pour son matériel [6].
Même si tout n’est pas terminé, les choses vont dans le bon sens. Le bon élève de la classe reste Intel qui apporte un support très complet de ses cartes graphiques et qui reste moteur sur les changements à venir.
_Améliorer la cohabitation de Linux et Xorg_
Comme nous l’avons vu, le support 3D n’est pas parfait mais on peut dire qu’actuellement la situation est globalement satisfaisante. En revanche, un gros problème persiste : le serveur X et le kernel Linux cherchent à dialoguer avec la carte graphique. Ce problème peut-être mis en évidence lors du démarrage de la machine. En effet, le passage de l’écran de démarrage au mode graphique de Xorg entraine un temps d’attente ainsi que des artéfacts graphiques. Ceci est dû à la sauvegarde / réinitialisation de la carte graphique entre les deux modes de fonctionnement (kernel vs Xserver).
J’ajouterais qu’en dehors de l’aspect purement esthétique, il faut savoir que le partage de la ressource graphique entre le noyau et le serveur X pose un problème de taille d’un point de vue sécurité et stabilité. Comme le serveur X initialise la carte graphique avec le même niveau de droit que le kernel Linux, il est en mesure de tout casser... Lorsqu’on sait que Xorg est constitué d’environ 2.5 millions de lignes de code, on imagine facilement que la situation peut très facilement déraper.
Des problèmes peuvent également apparaître lors de la mise en veille puisque le noyau est obligé de déléguer certaines opérations au serveur X. En cas de problème lors d’une sortie de veille, l’utilisateur peut obtenir une interface figée et n’aura aucune information.
Des travaux ont néanmoins déjà été menés. Fedora 9 offre par exemple ce support pour les cartes graphiques Intel. A terme, le noyau devrait intégrer les points suivants [3] :
- Gestion de la mise en veille. Le noyau s’occuperait complètement de la sortie de l’état de veille avant de rendre la main au serveur X.
- Message d’information en cas de crash. On peut se moquer de l’écran bleu de Windows, il a l’avantage d’informer de l’existence d’un problème...
- Utilisation d’une interface sans serveur X. Contrairement à ce qu’on pourrait croire, le serveur X n’est pas indispensable pour afficher du graphique sous Linux. Certains type d’applications pourraient très bien se passer de la couche de communication du serveur X (téléphonie, GPS, embarqué etc).
- Une gestion plus rapide lors d’un passage d’un terminal virtuel à un autre (même si ce n’est pas très parlant, il s’agit en réalité d’accélérer le démarrage du serveur X).
_Développements à venir_
La prochaine étape restera certainement l’inclusion d’un gestionnaire de mémoire pour les cartes graphiques dans le noyau Linux. Malheureusement, la situation est bloquée puisque le projet TTM (Translation Table Maps) n’a toujours pas été inclus dans la branche officielle. En effet, ce dernier est vu comme trop complexe et inclus trop d’éléments qui n’ont pas de place dans le noyau - du code n’est là que pour l’inclusion de driver binaire, gestion trop complexe des accès concurrents aux GPU et CPU - et plus grave, les projets opensource des drivers ATI et Nvidia n’ont toujours pas complètement adopté cette couche d’abstraction.
La question a donc été de savoir s’il n’existe pas un autre projet pouvant se substituer à TTM. Il se trouve qu’Intel avait commencé un projet (GEM pour Graphics Execution Manager [8]) qui devait justement remplir ce rôle. Plutôt que de vouloir trouver une solution unique trop complexe, le pari a été de faire fonctionner correctement un type de carte (Intel) puis d’adapter ce mécanisme aux autres type de carte (ATI et Nvidia).
L’approche a l’avantage de simplifier les choses au démarrage du projet pour son inclusion dans le noyau Linux (moins de code donc moins de remarque à prendre en compte). Mais elle a le désavantage de devoir introduire des changement importants à venir au niveau de l’API. De plus, certains tests préliminaires ont montrés que GEM devait encore s’améliorer pour arriver au niveau de performance de TTM [9].
__Pour conclure__
Globalement, comme nous avons pu le voir, tout n’est pas prêt et il reste un gros travail à fournir pour arriver à un niveau de finissions comparable à celui de Mac OS X ou au niveau des performances des drivers propriétaires. D’un autre côté, contrairement à un modèle de développement propriétaire, le monde opensource a le temps de faire ces changements et tout indique que les pièces du puzzle sont en train de se mettre en place tranquillement.
[1] X.Org sur wikipedia : http://fr.wikipedia.org/wiki/X.Org
[2] XFree86 Project License Modification : http://www.xfree86.org/xnews/#license
[3] (Jesse Barnes) enhancing the kernel’s graphics subsystem : http://lwn.net/Articles/235120/
[4] (Michael Larabel) Gaming With The Open-Source R500 Driver : http://www.phoronix.com/scan.php ?page=article&item=ati_r500_gaming&num=1
[5] (B. Rathmann) The state of Nouveau : http://lwn.net/Articles/270830/
[6] (Michael Larabel) VIA’s Open-Source Efforts A Bluff ? : http://www.phoronix.com/scan.php ?page=article&item=via_bluff&num=1
[7] (Jeremy Andrews) Linux : NVIDIA Binary Graphics Driver Exploit : http://kerneltrap.org/node/7228
[8] (Jonathan Corbet) GEM v. TTM http://lwn.net/Articles/283793/
[9] (Keith Whitwell) http://lwn.net/Articles/283823/
Didier Granjon, co-fondateur de simia.
