Emile “iMil” Heitor ‘s home

J’vous vois v’nir hein, “woaaa l’auuut’ comment il fait son jacky”. Que nenni, je fais ça pour la posterité, la documentation, l’experience !

Voila.

Donc, afin de faire taire les mauvaises langues qui diraient que l’UI, sous NetBSD, elle a 8 ans de retard, je me propose de vous exposer ici une methode permettant d’activer le Direct Rendering sur une machine NetBSD, mais aussi de profiter des jolis effets proposés par les applications supportant la fonction “Composite” d’Xorg. La carte graphique cible est une Intel i945GM mais cette méthode fonctionnera sur toutes les cartes listées ici.

Sous NetBSD 5.0, le support drm n’est pas présent dans le noyau GENERIC (il l’est dans current). La première étape consiste donc à ajouter ce support comme suit :

# cd /usr/src/sys/arch/amd64/conf/
# cp GENERIC MABOXEN
# echo "i915drm*	at vga?" >> MABOXEN
# config MABOXEN
# cd ../compile/MABOXEN
# make depend && make
# cp /netbsd /netbsd.generic
# cp netbsd /netbsd
# sync

Puis informons Xorg que nous souhaitons bénéficier de quelques atouts supplémentaires :

Section "Device"
        Option      "DRI" "true"
        Option      "AccelMethod" "XAA"
        Option      "XAANoOffscreenPixmaps" "true"
        Option      "AllowGLXWithComposite" "true"
        Option      "XVideo" "true"
        Identifier  "Card0"
        Driver      "intel"
        VendorName  "Intel Corporation"
        BoardName   "Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller"
        BusID       "PCI:0:2:0"
EndSection

Section "DRI"
        Mode 0666
EndSection

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

Attention, vous noterez qu’ici je définis comme methode d’acceleration le mode “XAA”. En effet, par defaut, c’est le module “EXA” qui est choisi par Xorg, or ce dernier produit, lorsque je choisis d’activer “composite” sur ma machine en tout cas, des résultats pour le moins surprenants: ecran divisé, trainées de pixels, disparition de curseur et j’en passe. En “XAA”, mon interface fonctionne parfaitement et rapidement.

Une fois ces opérations effectuées, un reboot sera nécessaire afin que notre nouveau noyau puisse dialoguer avec Xorg, comme nous l’indique un dmesg après avoir démarré Xorg :

i915drm0: interrupting at ioapic0 pin 16

Si tout s’est bien déroulé, le fichier /var/log/Xorg.0.log devrait contenir quelque chose de ce style :

[...]
drmOpenByBusid: drmOpenMinor returns 6
drmOpenByBusid: drmGetBusid reports pci:0000:00:02.0
(II) [drm] DRM interface version 1.2
(II) [drm] DRM open master succeeded.
(II) intel(0): [drm] Using the DRM lock SAREA also for drawables.
(II) intel(0): [drm] framebuffer mapped by ddx driver
(II) intel(0): [drm] added 1 reserved context for kernel
(II) intel(0): X context handle = 0x1
(II) intel(0): [drm] installed DRM signal handler
[...]
(II) intel(0): [dri] visual configs initialized
[...]
(II) intel(0): [DRI] installation complete

Et la commande glxinfo devrait vous indiquer ceci :

$ glxinfo |grep ^direct
direct rendering: Yes

Signe que toutes les folies sont désormais possibles.

À ce stade, si vous utilisez metacity comme gestionnaire de fenêtre, il suffit d’activer son mode “compositing” à l’aide de gconftool-2 :

$ gconftool-2 -s '/apps/metacity/general/compositing_manager' --type bool true

Et là, tout de suite, ça en jette :

J’aime bien les trucs qui clignottent, j’aime bien quand ça fait *wouiz* *wouiz* “ton CPU a trop chaud” *zap* *zap* “tu fais le cochon avec ta RAM”, ce genre là.

Je fus fort déçu mais peu surpris de constater que ni “CPU frequency scaling monitor” ni “sensors applet” n’ont été portées dans pkgsrc. Ces deux applets utilisent en effet probablement un tas d’API totalement linux-centric, comme par exemple lm-sensors pour l’affichage des températures (non khali, je ne suis pas en train de dire du mal d’lm-sensors).

Je ne me sentais pas assez courageux pour recommencer à mettre les mains dans Conky mais c’est exactement ce type de petit gadget qui me manquait. Par chance, je découvre avec joie sysutils/torsmo, qui n’est ni plus ni moins que l’ancetre du sus-cité conky.

Le package fonctionne, mais s’avère faiblement utile, en effet, l’une des deux fonctions pour lesquelles je souhais un soft de ce genre, la température du système, n’est pas gérée. L’occasion étant trop belle, je pensais me fendre d’un patch salvateur et être erigé en héros au passage. Rien de tout cela, car en réalité, Adam “haad” Hamsik m’avait simplement précédé de 3 ans. Pour une raison que j’ignore, son patch n’a pas été integré à pkgsrc, donc, après un petit nettoyage du-dit patch, je vous le livre, prêt à etre appliqué après un make patch :

# cd /usr/pkgsrc/sysutils/torsmo && make patch
# cd work/torsmo-0.18 && patch < /path/vers/torsmo-temp.diff

Mais ce n'est pas tout !

Pour une autre raison que j'ignore -j'aurai bientot la réponse à ces angoissantes questions puisque j'ai contacté ghen@ qui maintient ce package-, le Makefile n'active pas le support Xft afin donner à torsmo la possibilité d'afficher de belles polices bien lisses. Ce patch là est trivial :

--- Makefile	2009-11-22 17:27:42.000000000 +0100
+++ Makefile.new	2009-11-22 17:27:17.000000000 +0100
@@ -13,6 +13,7 @@
 NOT_FOR_PLATFORM=	Darwin-*-*

 GNU_CONFIGURE=		yes
+CONFIGURE_ARGS+=	--enable-xft

 EGDIR=			${PREFIX}/share/examples/torsmo
 DOCDIR=			${PREFIX}/share/doc/torsmo
@@ -40,4 +41,5 @@
 .include "../../x11/libXext/buildlink3.mk"
 .include "../../x11/libXt/buildlink3.mk"
 .include "../../x11/xextproto/buildlink3.mk"
+.include "../../x11/libXft/buildlink3.mk"
 .include "../../mk/bsd.pkg.mk"

Et tout ça ?

pour ça: