Le Vaio VGN-S1HP est un Centrino d'il y a 4-5 ans équipé d'un PentiumM 1.5GHz, d'une carte réseau wifi Intel IPW2200BG et surtout d'une ATI Radeon Mobility 9200 pilotant une dalle LCD 1280x800(WXGA de 13,3" de diagonale, rapport 16/10). C'est ce dernièr couple qui a posé problème.
Certes dotée de fonctions accélératrices 3D, c'est une carte qui accuse son âge mais qui dispose depuis peu de pilotes open-sources (depuis qu'AMD a racheté ATI et a ouvert les specs).
Si le fonctionnement en 2D (Xorg+Metacity) est sans histoire, il est impossible de lancer Compiz depuis le menu de configuration des Apparences (Système >> Préférences >> Apparence). Que cela ne nous arrête, pas, on est sous linux ou non ???
En ligne de commande,
compiz
nous renvoie un gentil mot nous disant que vu qu'on utilise un chipset ATI, on est privé de compiz.
Soit, avec son éditeur de texte préféré, il suffit de virer ce test enervant qui se trouve en ligne 275 de /usr/bin/compiz :
#don't run on laptops using ati driver
if laptop-detect; then
for DRV in ati radeon; do
if egrep -q "Loading ${XORG_DRIVER_PATH}${DRV}_drv\.so" $LOG &&
! egrep -q "Unloading ${XORG_DRIVER_PATH}${DRV}_drv\.so" $LOG;
then
verbose "Found laptop using ${DRV} driver. \n"
return 1
fi
done
fi
On se contente d'enlever la valeur de retour du test en commentant la ligne
# return 1
... Mais ca ne suffit pas, le script de compiz nous crache une nouvelle insulte à la figure :
Comparing resolution (1280x800) to maximum 3D texture size (1024): Failed.
Grrr, on pourrait croire qu'il ne nous aime pas...
Chouette, ca marche... pas...
A ce stade, je me suis dit qu'il fallait faire un crash test pour voir si par hasard, compiz avait réellement de bonnes raisons de ne pas démarrer. Le seul moyen ? démarrer compiz directement sans le script qui l'enrobe habituellement.
Le résultat fut... mitigé.
OUI compiz a démarré,
OUI on avait les effets 3D et tout le bouzin de compositing,
MAIS la largeur d'écran utilisable était limité à 1024 pixels, imaginez un écran de 1280 avec un gros pavé entre les colonnes 1024 et 1280, c'est pas présentable tout de même.
A ce moment, je me suis dit, c'est cuit, c'est la taille de texture (1024) comme me le dit le script de compiz qui vu qu'elle est inférieure à la taille d'écran empèche le fonctionnement... Grrr...
Mais c'était en oubliant que Google est mon ami. 10 minutes de recherches diverses sur le sujet m'ont permis de trouver deux contournements : 1 propre mais pas satisfaisant et un plus bizarre mais qui me met aux anges :
La solution propre
La solution propre est tout simplement de diminuer la profondeur de couleur. 24bits ca bouffe 1 octet de plus que 16bits (original non) donc en diminuant la profondeur de couleur on augmente la taille de la texture manipulable (on code plus de pixels dans autant de place).
La solution efficace
La solution efficace m'a un peu étonné il faut dire... Elle consiste à définir le mode Virtuel de l'écran à sa taille physique et le mode à la taille de la texture manipulable.
Le mode virtuel grossomodo c'est pour avoir un bureau plus grand que l'écran
Avec ce petit hack, l'écran est totalement rempli et compiz fonctionne comme un charme !
A rajouter dans la section "Screen" de /etc/X11/xorg.conf
DefaultDepth 24
SubSection "Display"
Depth 24
Virtual 1280 800
Modes "1024x800"
EndSubSection
ET VOILA