Bonne nouvelle (si il marche).
J'essaierais la semaine prochaine en espérant avoir une bonne surprise. J'en ai marre de devoir jouer à ETQW sous Windows.

Depuis le passage au noyaux 2.6.32, j'avais un problème d'écran externe "fuzzy" (vibration horizontale comme s'il y avait un pb de synchronisation verticale), ce dès le démarrage. Du coup, lorsque je devais travailler avec un écran ou un projecteur externe, je démarrais tjs sur le noyau 2.6.31...

En fouillant un peu (http://forum.nginx.org/read.php?30,72627), j'ai trouvé cette solution: ajouter nomodeset dans grub.conf.

C'est OK au niveau affichage sur l'écran externe, mais ce l'est moins au niveau de l'OpenGL... CairoDock ne fonctionne plus avec OpenGL; si j'utilise compiz comme gestionnaire de fenêtre, j'ai un tas de comportement bizares comme par exemple les fenêtres d'applications qui sont vide à l'ouverture et qu'il faut replier puis redéployer pour voire apparaître quelque chose...

Comment pouvoir à nouveau utiliser complètement Compiz en gardant l'option nomodeset au démarrage?

Merci d'avance.

VINDICATORs wrote:Normal, tu n'accède plus au matériel directement...

Je n'ai toujours pas reproduit ton problème...

Ta testé avec la version de mesa sur koji?

J'ai installé la dernière version de mesa:

# rpm -qa | grep mesa
mesa-libOSMesa-devel-7.7-5.fc12.i686
mesa-libGLU-devel-7.7-5.fc12.i686
mesa-libGLU-7.7-5.fc12.i686
mesa-dri-drivers-7.7-5.fc12.i686
mesa-libGL-devel-7.7-5.fc12.i686
mesa-libGL-7.7-5.fc12.i686
mesa-libOSMesa-7.7-5.fc12.i686

mais le problème est tjs là.

Très franchement, sans vouloir me gausser d'être un spécialiste, je ne pense pas qu'il s'agisse d'un pb de pilotes mais bien de noyau. Les stries horizontales apparaissent sur l'écran externe dès le démarrage. J'ai testé la dernière version d'Ubuntu (noyau 2.6.32) à partir du desktop CD, j'ai observé exactement le même comportement...

J'ai signalé le bogue sur bugzilla mais peut-être n'est-il pas bien commenté et donc personne ne semble s'en soucier. Bon je vais vivre avec, mais quand je n'aurai plus la possibilité d'utiliser un noyau je serai bien em..... pour donner cours.

Y'a pas moyen de reprendre proprement le contrôle après le boot et l'ouverture de session????

J'ai essayé les trois combinaisons suivantes :
1. Le dernier noyau d'update testing (2.6.32.12-114) avec la version 7.7.5 de mesa
2. Le noyau 2.6.32.1-99 avec la toute dernière version de mesa (7.8.1-6)
3. le dernier noyau et la dernière version de mesa

Sans succès... 🙁

Juste par curiosité, tu peux nous donner le lien du bug (bugzilla) ?

lecbee wrote:Juste par curiosité, tu peux nous donner le lien du bug (bugzilla) ?

Voici le lien: https://bugzilla.redhat.com/show_bug.cgi?id=571406

VINDICATORs wrote:Et le serveur graphique?

Il n'y avait pas de version plus récente que celle déjà installée...

Dans la doc, il y a deux trucs qui reste peu clairs pour moi: vu le type de ma carte graphique (Radeon mobility X1600, a priori GPU RV530/RV560...)
1. dois-je ou non installer mesa-dri-drivers-experimental
2. que dois-je mettre dans xorg.conf: Driver "radeon" ou Driver "ati"
????

Autre question: parmi la liste des paquets ci-dessous, lesquels dois-je absolument installer, lesquels ne dois-je surtout pas installer ???

[q]glx-utils-7.7-5.fc12.i686.rpm
mesa-demos-7.7-5.fc12.i686.rpm
mesa-dri-drivers-7.7-5.fc12.i686.rpm
mesa-dri-drivers-experimental-7.7-5.fc12.i686.rpm
mesa-libGL-7.7-5.fc12.i686.rpm
mesa-libGL-devel-7.7-5.fc12.i686.rpm
mesa-libGLU-7.7-5.fc12.i686.rpm
mesa-libGLU-devel-7.7-5.fc12.i686.rpm
mesa-libOSMesa-7.7-5.fc12.i686.rpm
mesa-libOSMesa-devel-7.7-5.fc12.i686.rpm
mesa-debuginfo-7.7-5.fc12.i686.rpm[/q]

Déjà tous les paquets -devel ne devrait pas t'être utiles.

mesa-dri-drivers-experimental-7.7-5.fc12.i686.rpm non plus (c'est pour les R600 et +).

Pour les autres je ne sais pas spécifiquement, mais leur installation ne posera pas de problèmes en tout cas.