samedi 11 octobre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Interface graphique fonctionnelle : encore un effort pour l'open source

Posté par didier granjon. Modéré le 07 juillet 2008.
0
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 couleurs 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.

> Lire la suite (145 commentaires, moyenne: 3,2).   [dépêche : 12560 caractères]

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, xedit, 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 bazar. 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 bazar 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 bazar est Linux.

Un autre avantage de la modularisation de Xorg était la sortie des pilotes qui pouvait se faire de manière complètement décorrélée de la sortie du serveur X. Xorg apportant ainsi plus de souplesse aux équipes en charge du développement des pilotes 3D et autres utilitaires de gestion des fontes 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) est toujours en travaux. La version 7.4 devrait améliorer les choses au travers du support de EXA.

À 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 GNU/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 GNU/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 :
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 :

Enfin notons que ces pilotes 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 noyau pour des raisons pragmatique. L'interdiction impliquerait l'absence de solution - Linus Torvalds a plusieurs fois exprimé sont opinion à ce sujet - Ce logiciel existe en dehors de Linux. Le pilote a d'ailleurs été porté à partir des pilotes 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 pilotes opensource fonctionnels[4]. Du côté de Nvidia, un groupe très organisé de hackers a également commencé un travail de rétro-ingénierie 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 noyau 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 artefacts graphiques. Ceci est dû à la sauvegarde / réinitialisation de la carte graphique entre les deux modes de fonctionnement (noyau 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 noyau 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] :
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 pilote binaire, gestion trop complexe des accès concurrents aux GPU et CPU - et plus grave, les projets opensource des pilotes 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 pilotes 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.

Références
Didier Granjon, co-fondateur de simia.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

intéressant, une question ...

Posté par or zax () le 07/07/2008 à 22:37. (lien). Évalué à 5.

Très jolie résumé de l'évolution et de l'état de l'art. Très intéressant.

Par contre, pourquoi cet article est dans les dépèches ?

modèle de développement

Posté par Aris Adamantiadis (page perso, ) le 07/07/2008 à 23:04. (lien). Évalué à 4.

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.

J'ai l'impression que tu confonds le modèle marketing avec le modèle de développement. Tous les développement propriétaires ne se font pas en "Cathédrale" - Dans ce cas-ci tu parles en fait du modèle de développement "Waterfall" qui est en effet le modèle de développement classique des logiciels propriétaires et des Cathédrales.
Il existe d'autres méthodologies de développement (je pense à extreme programming et aux autres techniques de développement agile) qui n'ont pas ces restrictions (impossibilité de visualiser le projet avant la fin de gros changements, impossibilité de recevoir des patches) - parce que le but même des ces méthodologies est d'avoir en permanence quelque chose de fonctionnel. Ce qui ne leur empêche évidement pas d'avoir une vue à long terme, même si l'analyse complète de la solution ne se fait qu'au fur et à mesure.

The Linux developers are selfish dickheads

Posté par Mathieu Stumpf (Jabber id, page perso, ) le 07/07/2008 à 23:16. (lien). Évalué à 2.

Bon j'en remet un couche (voir : https://linuxfr.org/~patrick_g/26876.html ) !

Sérieusement, à lire l'article on croirait qu'il n'existe que linux! Et les *BSD alors? Et le hurd?

Bon finalement j'hésite entre Syllable et isaac ( http://isaacproject.u-strasbg.fr/li.html ).

--
Le wiki de l'association culture libre : venez participer !

PPC _not_ pwned

Posté par benoar (Jabber id, ) le 08/07/2008 à 01:33. (lien). Évalué à 9.

Si en plus de ça vous utilisez un PowerPC, vous risquez de vous retrouver bien seul face à vos problèmes.
Ceux qui veulent faire un tour du coté du projet nouveau [http://nouveau.freedesktop.org/wiki/] trouveront plein de gens qui ont des PPC et du Nvidia \o/
Et en ce qui concerne les arguments pour avoir des drivers libres, j'utiliserais les même que pour tous les autres logiciels libres : la liberté !

Voilà, sinon nouveau c'est sympa, mais n'achetez pas de Nvidia (enfin, pas du neuf) c'est un peu contre-productif : http://lwn.net/Articles/269562/ . Ce n'est pas contre le projet nouveau, qui est très bien pour faire sortir les gens qui ont _déjà_ une Nvidia de la merde, mais ça favorise une entreprise qui ne fait rien pour le libre.

32 bits

Posté par Spack () le 08/07/2008 à 08:47. (lien). Évalué à 2.

Une petite question... Pourquoi Xorg ne supporte pas le 32 bits alors qu'il l'est sous Windows et qu'il y a même écrit "true color" à côté... Cela voudrait-il dire que les couleurs en 24 bits que je vois avec Xorg ne seraient pas vraies ???

je suis trop vieux ?

Posté par left () le 08/07/2008 à 09:05. (lien). Évalué à 9.

[...] le serveur X venait accompagné d'utilitaires d'un autre temps dont la plupart des distributions modernes n'avait plus besoin : des xterm [...]

Et dire que je travaille avec des xterm à longeur de journée. Je n'ai jamais compris l'interêt des konsole ou gnome-terminal, c'est plus lent, les raccourcis 'classiques' ne fonctionnent plus ... xterm est rapide et ne dépend d'aucun wm ... en fait, xterm c'est indispensable.