Retrouvez cet article dans : Linux Magazine 90

Non, ne vous inquiétez pas, le titre est racoleur, mais cela ne signifie pas pour autant que notre chère distribution va irrémédiablement se transformer en sapin de noël ou un déluge d’ombres portées en tous sens. Mais si c’est ce que vous souhaitez, c’est possible.

Le 25 octobre dernier la nouvelle est passée : " xorg 1:7.1.0-5 MIGRATED to testing ". Depuis, 7.1.0-6 et 7.1.0-7 ont suivi en novembre. " Et alors ? ", me direz-vous. La réponse est dans les logs du serveur X :

(II) Module glx: vendor="X.Org Foundation"
        compiled for 7.1.1, module version = 1.0.0
        ABI class: X.Org Server Extension, version 0.3
(==) AIGLX enabled
[...]
(II) AIGLX: Loaded and initialized /usr/lib/dri/radeon_dri.so
(II) GLX: Initialized DRI GL provider for screen 0

En réalité, et bien qu’il y ait beaucoup de bruit autour de tout cela, ce qu’implémente AIGLX (tout comme XGL) n’est pas si magique que cela. Petit retour sur l’histoire de l’accélération 3D sous X et démystification de la chose.
Au début était le pixel ou plus exactement l’affichage des pixels que l’application demandait au serveur X suivant un modèle client/serveur. Cela a grandement suffi pour un temps, puis sont arrivées les premières cartes dites " 3D ", à commencer par la fameuse Voodoo 3dfx. Depuis, le composant intelligent de l’adaptateur graphique, la GPU, s’est vu systématiquement équipé de fonctionnalités 3D. Pour accéder à ces fonctionnalités, une API nommée " OpenGL " a été créée et une manière d’accéder aux fonctionnalités 3D matérielles fut offerte : l’Indirect Rendering. Les directives OpenGL étaient transmises au serveur qui se chargeait d’utiliser l’adaptateur graphique.
Cependant, ce fut vite insuffisant. La communication complète via le serveur X était un goulot d’étranglement. Il fallait que l’application puisse dialoguer directement avec la GPU. Pour permettre cela, fut créé le Direct Rendering Infrastructure (DRI). Pour conserver le fonctionnement en couche, l’application n’utilise pas directement la GPU, mais un module noyau, le Direct Rendering Manager (DRM). Il faut donc que la carte soit supportée et qu’une version particulière de la libGL (l’implémentation OpenGL) utilise le mécanisme. De plus, l’aspect client/serveur n’était plus entièrement respecté.
La solution consiste donc à utiliser de l’Accelerated Indirect Rendering. Ceci supprime la double communication de l’application à la fois avec le serveur X et le DRM, ce qui signifie également que la 3D peut sortir des fenêtres. Il devient possible de mélanger pixels issus de l’affichage Xlib et de la GPU 3D en ne manipulant plus les pixels à l’écran, mais en mémoire. L’opération est effectuée par l’extension X appelée " composite ". Voilà donc ce qui provoque toute l’effervescence actuelle autour d’AIGLX et XGL, un rendu accéléré indirect, rien de plus.

Et Debian dans tout ça ?

L’introduction de X.Org 7.1 marque l’arrivée de l’Accelerated Indirect Rendering dans la distribution Testing qui, je vous le rappelle, est en soft freeze au moment où ces lignes sont écrites. Ceci signifie, dans le cas où vous posséderiez une carte NVIDIA, ATI ou Intel i810, que le support AIGLX est directement utilisable. Il vous faudra simplement installer le paquet libxcomposite1.
Ensuite, vous pourrez configurer le X.org en ajoutant dans votre /etc/X11/xorg.conf :

Section "Extensions"
  Option "Composite" "Enable"
EndSection

et, dans la section Device :

        Option    "XAANoOffscreenPixmaps"

Bien entendu, l’implémentation AIGLX ne sert pas à grand-chose seule. Il vous faut ajouter à votre système un Composite Manager et un gestionnaire de fenêtres (Windows Manager) utilisant les nouvelles fonctionnalités. Pour l’heure, deux projets se disputent la vedette : Compiz et Beryl. Tous deux remplissent les deux rôles. Je ne traiterai pas ici de Compiz tant pour des raisons techniques que philosophiques. Compiz est initialement créé pour XGL dont le développement a été fait de manière fermée avant que le code ne soit ouvert et libéré par Novell. De plus, je pense que l’architecture d’XGL elle-même tient davantage du hack temporaire en attendant Xegl que d’un plan à long terme. C’est par ailleurs l’une des raisons qui ont poussé à la création d’AIGLX et de Beryl. Le fait qu’AIGLX soit intégré, de base, dans Testing est également, bien entendu, un argument de poids dans les choix rédactionnels pour cet article.
Il n’existe pas, à ma connaissance, de paquets Debian permettant l’installation de Beryl. Cependant, des paquets Ubuntu sont disponibles sur http://beryl.lupine.me.uk/dists/dapper/all/. Dans la liste, choisissez, téléchargez et installez (via dpkg -i par exemple) :

beryl_0.1.1-0ubuntu1_i386.deb
beryl-core_0.1.1-0ubuntu1_i386.deb
beryl-manager_0.1.1-0ubuntu2_i386.deb
beryl-plugins_0.1.1-0ubuntu1_i386.deb
beryl-plugins-data_0.1.1-0ubuntu1_all.deb
beryl-settings_0.1.1-0ubuntu1_i386.deb
emerald_0.1.1-0ubuntu1_i386.deb
emerald-themes_0.1.1-0ubuntu1_i386.deb

Installez les dépendances avec (apt-get install -f est votre ami, au cas où) :

        % apt-get install libxdamage1 \
  libxcomposite1 librsvg2-2 libwnck18

Une fois tout ceci installé, vous disposerez de trois outils importants :

• beryl : c’est le gestionnaire de fenêtres à proprement parler et le Composite Manager.
• beryl-manager : un frontend de gestion permettant le lancement d’un gestionnaire de fenêtres différent, la configuration du gestionnaire de thème Emerald, etc.
• beryl-settings : l’outil de configuration de Beryl (raccourcis clavier et souris, configuration des effets, etc.).

A ce stade, vous pouvez déjà faire quelques essais, comme par exemple, lancer une session X avec startx et un ~/.xinitrc contenant simplement exec xterm. Lancez votre session et, dans la fenêtre (qui n’en est pas une faute de WM) Xterm, lancez beryl-manager. Automatiquement, le gestionnaire de fenêtres Beryl est lancé. Comme beryl-manager vous rend la main, testez vos applications.
Pour une intégration plus poussée, il convient de coupler Beryl avec un gestionnaire de bureau comme XFCE4. Beryl se limite à la gestion des fenêtres. Vous n’avez donc pas de barre de menu/état, launcher ou autre. Choses que propose justement XFCE4. De plus, le gestionnaire Beryl s’intègre parfaitement dans XFCE4. Que demander de plus ?
Première étape, configurez le gestionnaire de sessions GDM en ajoutant le fichier/usr/share/xsessions/beryl.desktop contenant :

[Desktop Entry]
Encoding=UTF-8
Name=Beryl choupi-desktop
Comment=This session logs you into Beryl/XFCE4
Exec=/usr/local/bin/beberyl
# no icon yet, only the top three are currently used
Icon=
Type=Application

Il faut ensuite se pencher sur le script shell /usr/local/bin/beberyl qui permettra le lancement de différents éléments, comme :

emerald --replace & \
beryl --replace dbus settings & \
wmsetbg display /home/denis/bg/debian-6.png & \
xfce4-panel

J’utilise ici wmsetbg provenant de WindowMaker, mais xsetroot ferait également l’affaire. Après quelques tentatives, il semblerait que la gestion du fond via XFCE4 refuse de fonctionner pour une raison inexpliquée faute de temps. Lancez GDM, sélectionnez " Beryl choupi-desktop " et appréciez le résultat.
A présent, il vous revient de décider ou non de poursuivre dans ce sens et d’intégrer davantage Beryl dans votre système. Si tel est le cas, je vous recommande fortement de recompiler et reconstruire les paquets afin d’éviter le mélange Debian/Ubuntu. Une procédure est donnée sur le wiki de Beryl, même si la manipulation est des plus classiques. Une solution plus propre que l’ajout de fichier GDM et de scripts à la main est également à prendre en compte (via vos nouveaux paquets Debian de Beryl par exemple).
Enfin, si, comme moi, la fatigue visuelle provoquée par des fenêtres molles et des animations en tous sens vous est trop pénible, gardez simplement tout cela sous la main pour les démonstrations aux collègues médusés et habitués à vous voir travailler avec quelque chose de plus spartiate, mais tellement plus rapide.
Pour ma part, je pense qu’une utilisation raisonnable des effets, se limitant par exemple aux switchers d’applications ou aux fonctionnalités proches de l’Exposé d’Apple peuvent être intéressantes. Cependant, la richesse de Beryl ou Compiz est, pour l’heure, principalement motivée par, passez-moi l’expression, " l’envie d’en mettre plein les mirettes ". Il faudra attendre un peu, le temps que les développeurs de différents gestionnaires de fenêtres " classiques " intègrent cela. Pour l’heure, Beryl comme Compiz, remplissent leur office : montrer aux utilisateur que les systèmes GNU/Linux peuvent rivaliser avec le Quartz Extrem d’Apple ou l’Aero du furur Vista de Microsoft.

Liens:

• Wiki Beryl,

  http://wiki.beryl-project.org/index.php?title=Install/Debian

• Paquets Beryl pour Ubuntu Dapper,

  http://beryl.lupine.me.uk/dists/dapper/all/

• XGL pour Debian,

  http://www.beerorkid.com/compiz/

• Le projet Beryl,

  http://www.beryl-project.org/

• La page Compiz chez OpenSUSE,

  http://en.opensuse.org/Compiz

Retrouvez cet article dans : Linux Magazine 90