Le G62-a57SF est un portable HP 15,6". Bien que manifestement assez largement distribué, il existe peu (voire pas) de documentation en ligne sur l'installation de GNU/Linux sur cette machine, sauf quelques rares fils de forums rapportant des soucis, et bien peu de solutions. Voici des notes prises au terme de quelques heures passées en compagnie de l'ordi en question.
Si vous savez mieux faire, faites le savoir en mailant. Merci !
Deux chipsets sont embarqués, un ATI pour la puissance et un Intel pour l'économie. Le premier est géré par le pilote libre radeon sous xorg, le second par le pilote intel.
Problème : le pilote radeon ne gère pas correctement la carte (pas d'affichage), pas plus que le pilote non-libre fglrx, semble-t-il.
Or, pendant la séquence de boot, les deux cartes sont initialisées, et les Kernel Mode Settings des deux cartes activés. Pour des raisons qui ne sont pas très claires (battery or not battery?), l'une ou l'autre carte prend la main, et l'on peut se retrouver avec un écran noir si la radeon est utilisée.
Solution : désactiver la carte ATI complètement, en
utilisant le mécanisme vga_switcheroo dispo dans le noyau de Maverick
et/ou Natty. Pour ce faire, il suffit d'ajouter les lignes suivantes dans
/etc/rc.local :
# activate discrete graphics (radeon) echo DIS > /sys/kernel/debug/vgaswitcheroo/switch # activate integrated graphical device (intel) echo DIS > /sys/kernel/debug/vgaswitcheroo/switch # power-off discrete graphics echo OFF > /sys/kernel/debug/vgaswitcheroo/switch
Note : il semble qu'il ne faille pas blacklister le module radeon comme je l'avais fait au départ afin que vgaswitcheroo soit initialisé. Manifestement, le noyau ne le lance que si les deux modules sont chargés par l'initramfs.
Update (Ubuntu 11.10 Oneiric) : la mise à jour vers cette version d'Ubuntu ajoute un nouveau problème dans la gestion de la luminosité. Au démarrage, la backlight est positionnée à son niveau minimum, sans que l'on puisse aisément le changer ; la solution consiste à passer l'argument acpi_osi=Linux au noyau (il suffit de l'ajouter à la variable GRUB_CMDLINE_LINUX_DEFAULT dans /etc/default/grub puis de lacner update-grub), puis de taper la commande suivante (qu'on ajoutera là encore à /etc/rc.local pour automatiser la chose :
echo 8 > /sys/class/backlight/acpi_video0/brightness
Elles ne marchent simplement pas, et aucun évènement xev n'est détecté. Dès lors, que faire ? Une option du BIOS permet de théoriquement de les utiliser en pressant la touche Fonction, et cela semble avoir déclanché la détection pour d'anciens modèles de portables HP, mais pour celui-là... nada.
Si vous savez comment faire, n'hésitez pas.
Cette machine est un buffle. Le fait de désactiver la carte ATI a pour effet de ramener la soufflerie à quelque chose de plus raisonnable, mais c'est quand même vraiment pénible pour qui est habitué à un modèle silencieux. Il paraît que c'est pareil sous Windows, ceci dit.
Aujourd'hui, ne pas crypter ses données, c'est un peu, euh, le passé. La manière simple, coole et efficace de le faire, c'est LUKS et le cryptage de la partition racine (ce qu'Alternate Installer d'Ubuntu permet de faire).
Dans le cas présent, en raison des problèmes graphiques liés aux KMS, la seule façon d'avoir une visibilité sur le moment d'entrer la phrase de passe LUKS au démarrage est de démarrer avec l'option nomodeset passée au noyau via grub2.
Problème : cette option désactive les Kernel Mode Settings, et seul le pilote xorg vesa est alors disponible, ce qui limite la résolution à 1024x768 (et provoque un affichage distordu et dégueulasse) en plus de brider considérablement les possibilités des cartes. S'il peut être bon de booter avec nomodeset en cas de merde avec un pilote graphique, ce n'est pas une solution.
Solution(s) :