KOLKHOZE.com

En ces périodes d'annonces de bureau 3D virevoltant ^[1] au grand plaisir de l'utilisateur, je me suis penché sur le cas du pingouin. En effet, celui-ci peut être qualifié de mauvais élève au vu de ses petits camarades. La dernière innovation intéressante date de la sortie de Xfree86 4.0 ... il y a maintenant 6 ans ...

Et depuis ? Rien ... Ou pas grand chose si ce n'est de grandes annonces pas très claires avec des gens qui se bouffent le nez pour dire que ce qu'a fait l'autre c'est rien que du caca. Le résultat de tout ça ? Ce qu'on appelle communément un "fork" du projet (fourche en français, dérivé d'un appel de fonction en C qui a pour but de créer un processus fils. petite voix : C'est quoi un processus fils ? moi : Euh ... Google ?) et la création du projet Xorg.

XFree86

Pour ceux qui ne sauraient pas ce qu'est un serveur X, je vous conseille de vous reporter à cette excellente définition.

Le projet XFree86 a eu plein de mérite : il a apporté une gestion efficace de tout une pelleté de cartes graphiques avec des performances tout à fait correctes pour l'époque.

Mais on retrouvait également la crème des crèmes de ce qui se fait en connard du libre avec une conception tout à fait particulière du développement "ouvert". Pour contribuer au sein du projet, il fallait faire partie du noyau des développeurs (la core team). Donc, toutes les contributions externes (venant de projets comme cygwin ^[2] ou encore de gens comme Keith Packard ^[3]) se retrouvaient passées à la loupe et souvent, les contributions se retrouvaient dans la corbeille, d'où une difficulté importante pour faire avancer le projet.

Ce qui devait arriver arriva, le projet a stagné (pensant que de toutes façons, plus rien de "mieux" ne pouvait arriver et qu'après eux, le déluge) et XFree86 s'est fait gentiment dépassé par les événements :

• sortie de MacOSX avec son support révolutionnaire des fenêtres qui se déforment etc.
• sortie de Windows 2000 avec support hardware des fenêtres, gestion de la transparence etc.
• et malheureusement, à part un XAA poussif qui n'a jamais été activé par défaut sur les distributions (pour des raisons de bugs récurrents), rien à signaler sous Linux.

D'autant que pour arranger tout ça, Windows Vista se pointe à grands pas, et là, autant vous dire qu'il y aura une grosse claque au niveau du visuel (sinon, je vous rassure, ce sera toujours un produit Microsoft, donc par définition, de la m.... ;).

Bien sûr, certains projets avaient commencé à faire leur apparition comme par exemple DirectFB ^[4], un fork de XFree (Xouvert ^[5]) ou encore du projet y-windows ^[6]. Mais comme la communauté n'était pas très intéressée par ces changements, tous ces projets sont restés très peu utilisés et avançant tant bien que mal.

Le successeur : Xorg

Ce changement de serveur n'est donc pas arrivé sans crier gare mais n'a pas été de l'initiative de la communauté. La question était de savoir quel événement allait faire changer les choses ...

Et bien, c'est con mais ceux qui sont à l'origine de la fin de XFree86 sont tout simplement les gars de la core team du dit projet ! En effet, ces petits rigolos se disaient qu'ils allaient changer la licence du projet XFree86. Malheureusement pour eux, ils n'avaient pas prévu que ces changements allaient entrainer l'incompatibilité avec les licences libres (selon la définition de la FSF).

Du coup, les gars de l'équipe Xorg (avec en tête des gars comme Keith Packard) ont annoncé un fork de XFree86 version 4.4 RC2 (dernière version encore sous l'ancienne licence) qui a amené à la création de Xorg 6.7.0.

Conséquence du fork : explosion du développement et arrivée de l'extension composite et d'EXA

Très rapidement, cette sortie initiale s'est accompagnée de grandes modifications pour l'intégration de l'extension composite ^[7] ainsi que l'arrivée du successeur de XAA : l'extension EXA ^[8]. La différence entre ces deux extensions est que EXA est nettement plus simple à mettre en place. Elle remplacera à très brève échéance XAA.

A propos de ces extensions, leur rôle consite à déléguer l'affichage des fenêtres au GPU (la carte graphique) en lieu et place du CPU (le processeur dans votre PC). L'avantage de cette méthode est que vous déchargez le processeur des opérations d'affichage et que vous le faîtes faire par un périphérique qui est fait pour ça (Pour comparaison, une carte graphique récente posséde entre 200 et 400 millions de transistors alors que le processeur "principal" en posséde entre 50 et 100 millions).

L'avantage immédiat : une meilleure réactivité, de la mémoire système libérée, remplacée par celle de la carte graphique et enfin une meilleure répartition du travail sur l'architecture de nos chers PC. Que du bonheur je vous dis !!!

Un dernier mot à propos des dernières versions de Xorg (6.9.0 et 7.0.0) : ces deux versions sont identiques. Le seul point qui les différencie sont les outils de développement utilisés : pour la version 6.9.0, le système de construction du projet est hérité de l'ancien mode de fonctionnement (utilisation d'un projet monolithique) tandis que sur la version 7.0.0, on passe à un mode de développement beaucoup plus moderne avec l'utilisation des outils automake ^[9] et autoconf ^[10].

Bon, je sais, ça change pas grand chose pour vous, mais l'avantage de cette démarche va permettre de simplifier et modulariser le développement. Tout ceci afin de sortir le projet de son aspect monolithique.

Ce qui va arriver très rapidement : Xgl ^[11]

Bon, vous vous dites que c'est cool, maintenant j'ai des beaux effets de transparence mais j'ai toujours pas les effets 3D de MacOSX ... Mais je vais vous répondre qu'il existe déjà un projet (qui devait être temporaire mais qui va apparemment être un peu plus temporaire que prévu) qui remplit ce rôle : Xgl.

Le rôle de ce dernier est d'offrir un serveur X construit sur un driver OpenGL ^[12]. Son seul soucis c'est que pour faire fonctionner ce serveur X, on s'appuie sur un premier serveur X (xorg 7.0.0) qui va offrir cette fameuse accélération OpenGL. On se retrouve donc à faire tourner en même temps deux serveurs X ... Bon, c'est vrai que ça fait toujours un intermédiare de plus. Mais quand on voit les couches d'abstractions qu'on traverse pour accèder aux matériels ... on est plus à une couche près.

Le résultat est quand même tout à fait bluffant. Je dirais malheureusement que ce projet a eu une période de développement derrière des portes fermées (de novembre 2005 à février 2006) chez Novell ^[13]

Le résultat de tout ça ? Quelques grincements de dents et des gens qui parlent d'un autre projet plus simple qui aurait très bien pu faire aussi bien que Xgl ... j'ai nommé AIGLX (à vos souhaits !).

Un petit mot sur AIGLX ^[14]

Bon, comme d'hab, ça se bouffe le nez et tout le monde est en train de critiquer le boulot de l'autre. Mais bon, faut pas s'affoler, c'est souvent le cas dans le monde OpenSource (cf ci-dessus Xorg). Faut dire que certains acteurs du monde graphique sous Linux (Red Hat ainsi que nVidia pour ne pas les citer) auraient aimé avoir une petite concertation avant de voir arriver cette solution (voir les documents de présentation de nVidia à ce propos qui ne sont pas des plus tendres avec les travaux qui ont été réalisés).

Donc, situation intéressante où nous avons d'un côté les développeurs de solutions propriétaires (qui seront donc pour la solution AIGLX) et d'un autre côté des gens qui veulent faire avancer les choses (Jon Smirl ^[15] ou David Reveman ^[16]).

Autant vous dire qu'il s'agit surtout pour moi d'une guéguerre de chapelle puisque Red Hat fait la tronche que Novell ait sorti avant eux une solution vraiment présentable de super Desktop et que d'un autre côté, nVidia n'est pas franchement emballé de devoir reprendre le développement d'un nouveau driver from scratch (en réalité, je pense que leur travail n'est pas non plus insurmontable. Et après tout, ils ont qu'à libérer les spécifs de leurs matos !) ...

La seule certitude sur ce projet serait qu'il pourrait se faire sans modifications importantes dans la structure du serveur X et qu'il ne demanderait que l'ajout d'une extension OpenGL ^[17] dans les implémentations existantes sans création d'un nouveau driver. nVidia a par ailleurs indiqué qu'il implémenterait très rapidement cette extension dans leurs prochains drivers...

Suite à ça, David Reveman (développeur de Xgl chez Novell) s'est fendu d'une petite réaction que je vous laisse découvrir ici ...

Xegl, le successeur de Xgl et Xorg

Nous l'avons vu, le problème de Xgl est de dépendre de l'accélération OpenGL d'un serveur X (on parle ici de OpenGL GLX ^[18]). L'idée pour Xegl serait de se passer de cette couche intermédiaire inutile et de passer directement à un driver OpenGL (on parle maintenant de OpenGL ES ou GLE ^[19]). Même si la différence peut paraître anodine, elle implique une réécriture presque complète du driver, ce qui ne plait pas du tout aux développeurs de drivers propriétaires ^[20].

Mais ce que n'ont pas dit les détracteurs de cette solution, c'est qu'il ne faut pas forcément une implémentation complète de OpenGL et que le serveur pourrait très bien fonctionner avec un ensemble très restreint de OpenGL ^[21] (OpenGL est une librairie capable de faire de la 2D en plus de la 3D et existe avec plusieurs degrès d'implémentation. Le serveur serait capable de gérer ces différences directement au sein du serveur X ...).

L'un des autres gros avantages de cette démarche serait une amélioration de la sécurité du système. En effet, le driver se trouverait seulement au niveau du noyau Linux. Ainsi le serveur X n'aurait aucun privilège et empêcherait de nuire certains types de programmes malveillants. Autre conséquence, la gestion de la carte se ferait au niveau du noyau et non pas au niveau du serveur X (comme c'est fait actuellement et qui peut poser problème dans la mesure où ces deux là se marchent parfois sur les pieds et font du coup la même chose à deux endroits différents).

Le seul vrai problème est qu'actuellement, en dehors des ATI radeons 8500 à 9200 (qui commencent à se faire vieilles), aucun driver GLE n'existe et comme on peut s'en douter, le développement des drivers binaires d'ATI et nVidia ne devrait pas arriver tout de suite ... Mais comme nous l'avons vu, une implémentation minimum permettrait d'obtenir un résultat équivalent à maintenant.

Pour conclure

Pour conclure, il faut surtout retenir qu'il aurait été préférable que les grandes sociétés autour du bureau Linux se soient concertées pour fusionner leurs efforts (mais tout n'est pas perdu !). Pour moi, il semble évident que la solution de Novell est quand même très élégante même si elle entraine une quantité de travail non négligeable (surtout en vu de la création du successeur de XGL : Xegl).

Rappelons que sous Linux, il n'existe pas un seul Desktop (guéguerre entre KDE et Gnome) et il est très rassurant de voir qu'il existe plusieurs solutions pour amener ces effets graphiques !

Quelques Liens supplémentaires

Vidéo de présentation de Xgl

Homepage de Xgl chez Novell

Vidéo des premières présentations au Solutions Linux début février