Archlinux.fr [Forums]

Bonjour,

je dispose sur mon laptop d'une carte graphique détectée comme étant la RS482, avec lspci.
Bien que le pilote xf86-video-ati soit indiqué comme stable, ce dernier plante tout de même en m'affichant un écran figé avec des bandes de couleurs une fois sur trois au démarrage (problème que j'ai eu avec d'autres distributions Linux comme Fedora).
Ce comportement survient quand je ne configure rien de particulier et que hal se charge lui-même de la détection (sans xorg.conf).

Ensuite, j'ai bien suivi la méthode indiquée sur le wiki, j'ai voulu utiliser le xorg.conf (initialisé avec X -configure) indiqué en cas d'utilisation de pilotes libres, mais rien n'y fait : avec cette méthode, je n'obtiens qu'un écran noir après la commande startx.

Je suis un peu coincé : je ne peux plus utiliser les pilotes propriétaires avec cette carte (plus de support de la part de Catalyst) sans repasser à un noyau < 2.6.26.

J'ai recherché dans le forum, et tenté les quelques solutions que j'ai trouvées, mais sans plus de résultat.

J'ai peur que je n'arrive plus jamais à faire fonctionner une interface graphique sans rester sur un vieux noyau...

L'écran noir, c'est normal. En effet, X est lancé, point barre.
Lance :
startx & sleep 30; killall X

Et ensuite, postes nous tes logs de Xorg pour vérifier que tout marche, ou alors lance directement kdm ou gdm

Que ce soit après la commande que tu m'as donnée, ou après avoir lancé gdm, j'obtiens toujours le même écran noir. Qui ne disparait pas.

Et les logs ?

Murzan a écrit :Et les logs ?

Je suis obligé d'éteindre la machine pour quitter l'écran noir, je suppose que ces derniers sont alors effacés. Après rédémarrage, je m'aperçois en mode console que /var/log/Xorg/0.log est un fichier entièrement vide.

Si tu as la chance d'avoir 2 machines, tu lances openssh sur ton portable, et lorsque ton X plante, tu te connectes pour nous fournir les logs (voire tuer X aussi au passage)...

Sinon, essaye d'abord avec le driver Vesa pour voir.

Sinon y a la méthode brevetée à la Rache :
En init 3 (sans gdm/kdm/slim/xdm/entrance...): ça lance X pendant 30 secondes et pouf

Non il y a une erreur startx ne redonne jamais la main, le plus fiable :

startx & sleep 30; killall X

Euh, la commande, je la donne un peu plus haut hein

Oups, mais il fallait comme même préciser que le post qui était juste au dessus du mien était faux

Rebonjour,

je rouvre ce vieux topic, car depuis de grosses mises à jour noyau ont eu lieu.
J'ai toujours le même chipset graphique (RS482) correspondant à une carte Xpress 200M (en réalité ATI Radeon Xpress 1150). J'ai réinstallé Arch avec les toutes dernières versions noyaux, réinstallé xorg avec driver libre radeon.
Cela dit, j'ai encore des plantages graphiques aléatoires.

Sans l'option "nomodeset" passée au noyau, j'ai un plantage graphique une fois sur deux en moyenne dès le démarrage de xorg (plantage noyau, plus rien ne répond même le joker REISUB...), qui se traduit par un affichage de bandes verticales reserrées et colorées, totalement figé. Le redémarrage est alors obligatoire.
Les seules fois où ça marche, le plantage peut survenir en pleine utilisation du bureau (et est encore une fois définitif). glxgears, dans ce mode, m'affiche des résultats à 60FPS.

Avec l'option "nomodeset", plus de plantages dès le lancement. glxgears parvient à plus de 1000FPS. Par contre, j'ai encore des plantages du bureau aléatoires, qui se traduisent de temps à autre (en cliquant sur la barre de démarrage KDE parfois) par l'affichage inopiné du même écran de bandes colorées (ou rien ne transparait, je ne vois plus mon bureau du tout !). Sauf que par rapport à la fois où je n'ai pas passé d'options au kernel, je reviens sous KDM après 5 secondes en moyenne. Dans ce cas, le "plantage graphique" n'est pas définitif.
C'est cependant assez embétant, puisque je perds alors tout dans KDE (fenetres ouvertes etc...) à la reconnexion. Et ce plantage aléatoire rend impossible une utilisation de bureau normale...

J'ai aussi testé à tout bout de champ d'autres options noyau, telles que "pci=nomsi" ou "radeon.modeset=0 ou 1" sans plus de succès...

Voilà voilà, si parmi vous certains ont l'immense privilège d'avoir cette carte graphique que même Ubuntu.fr traite avec bienveillance :
"R300 : Radeon Xpress 1100 (RC410) : reconnue comme Xpress 200M, la configuration par défaut peut poser problèmes (défauts graphiques, plantages…). Ces problèmes peuvent parfois être résolus en changeant le KMS (Kernel Mode Setting). Ajoutez l'option "radeon.modeset=1" à la ligne de commande grub (touche "e" à l'invite de grub, puis touche "e" sur l'entrée à éditer ; ajouter l'option -sans les guillemets- puis "Entrée" suivi de "b"). Si rien ne change, essayez avec l'option "nomodeset" (ce qui a marché pour moi)."

tiré de http://doc.ubuntu-fr.org/radeon

N'hésitez pas à me faire partager vos idées, où même me rassurer un bon coup en me disant que de toute façon, le prochain kernel 2.8 résoudra tout ça d'ici deux trois ans.

Amicalement !

Je te conseils fortement xf86-video-ati, radeonhd est d'ailleurs plus dans les dépôts officiels, voir https://wiki.archlinux.org/index.php/ATI

Salut benjarobin,

merci pour ta réponse. En fait, j'avais déjà installé le paquet xf86-video-ati (seul paquet disponible par ailleurs pour cette carte ).

J'ai eu l'occasion de retester de multiples fois depuis tout à l'heure. Il semble que :
- l'option "nomodeset" est obligatoire rien que pour avoir un affichage 2D correct au démarrage,
- l'option "pci=nomsi" n'apporte pas grand chose de plus. En fait, il me semble que c'est même activé par défaut sur les noyaux 2.35,
- le plantage graphique sur le bureau ne survient que lors d'opérations 3D particulières (entre autres, réduction d'une fenetre sous KDE avec "Desktop Effects activés"). Je n'ai pas encore testé avec des jeux du genre extremetuxracer ou armagetronad pour voir si ça risque de planter. Ce plantage ne fait pas planter l'ensemble du noyau, il fait juste revenir à KDM après l'affichage de bandes colorées...

Donc, bilan, jusqu'à nouvel ordre :
- pas de KDE Desktop Effects ni Compiz (à confirmer pour ce dernier point, cependant...),
- option nomodeset à spécifier, donc pas de support KMS pour cette carte jusqu'à présent.

En attente de tests plus poussés, et en espérant que le support de la 3d ne sera pas que partiel dans le futur...

Amicalement !