Bonjour,

Suite aux récents problemes causé au nouveau noyau et au nouveau drivers propriétaire, je me pose quelques questions.

Pour commencer, depuis quelques jours, le kernel 3.14.2 est proposé en mise à jour (chose que nous avons bien sur tous ou presque fait).
Depuis quelques jours, le 25 avril pour etre précis, AMD propose un nouveau téléchargement : la version 14.4 des drivers qui en fait contient dans le fichier zip un "installeur" en 14.1 !?!
Cette "derniere" version ne serait compatible qu'avec une version de X Serveur 1.13 (pour rappel, nous somme sous F20 en 1.14-4)

Du coup, il ne nous resterait plus qu'à utiliser la version "beta" des drivers (2 lignes au dessous des drivers officiels).

Bref, j'ai eu des soucis avec l'ancienne version des drivers ATI suite à la mise à jour de mon kernel : seuls 2 de mes 3 écrans fonctionnaient ; je crois qu'une seule de mes 2 cartes graphique est prise en compte.

Je n'écris pas ce poste pour de l'aide (que je soliciterai surement si je ne m'en sors pas avec les drivers proprios), mais pour quelques questions lié aux avantages et inconvénients des pilotes libre vs pilotes proprios (avec F20).

Après mes problemes, j'ai désinstallé les pilotes propriétaires et j'ai commencé à utiliser les pilotes libres.
Mes 3 écrans fonctionnent, mais j'ai encores quelques soucis pour régler une résolution qui n'est pas proposée pour l'un de mes écrans (VGA).
J'ai aussi les "saccades" (ou entrelacements je crois) qui ne propose pas une "fluidité" dans le déplacement de fenetre.
Plus bizarre : dans une console, quand je tappe des commandes du type "ls" ou "cd ...", je me trouve à devoir attendre un certains temps inacceptable pour des demandes si basiques.

Bref, y a t il, moyen sous les pilotes libres de gerer ces problemes rencontrés ou pas ?

Au plaisir de vous lire

PS : j'ai lu la documentation en cours de rédaction sur les pilotes libres, mais les commandes pour ajouter des résolutions ne m'ont pas encore aidé.
Le problème des pilotes libres est la gestion de deux cartes graphique. Ils ne le font pas encore (c'est prévu, mais pas pour demain d'après ce que j'ai compris 🙁).

Pour les saccades les patchs sont dispo pour mesa 10.2, mais ils ne sont pas encore disponible.

Même sur mon HD 4850 j'ai dut repartir sur mesa 10.1 et je n'en suis pas content comme c'est le cas avec la 10.2, mais je n'arrive pas à construire les paquets avec depuis qqes mises à jours du git 🙁.

Comme je n'ai plus trop le temps de m'y pencher (formation intensive tout ça) et que j'ai prévu de changer de matos, ce n'est pas encore pour tout de suite.

La commande pour les résolutions date, il faudrait revoir complètement les choses. Ta pas gardé un fichier xorg.conf dans /etc/X11/ par hasard?

Merci pour l'information, c'est vraiment bizarre...

Pour les saccades et fluidité joue avec l'option vblank pour la synchro de l'écran.
Pour répondre et compléter,
j'ai ré-installé les pilotes proprios "14.4", pour faire en sorte de pouvoir travailler demain, mais je n'utilise pas le dernier noyau (3.14.2), j'utilise le précédent (3.13.10-200).
Mes 3 écrans fonctionnent, mes 2 cartes graphiques sont détectées, mais ce n'est pas grace à l'interface graphique que j'ai pu tout rétablir (amdcccle)
Oui, l'expérience m'a appris à concerver les fichiers de configurations utiles. j'ai donc une version du xorg.conf qui marchait avec l'ancienne version et je l'ai légèrement adaptée à la version actuelle.
Si cela peut aider qq, je peux le fournir.
ozit wrote:Pour répondre et compléter,
j'ai ré-installé les pilotes proprios "14.4", pour faire en sorte de pouvoir travailler demain, mais je n'utilise pas le dernier noyau (3.14.2), j'utilise le précédent (3.13.10-200).
.
Il n'y a que ça à faire dans l'immédiat.
8 jours plus tard
Quel Bx*!:@l !!

(quelques heures plus tard)

La mise à jour du kernel ne résoud rien à ces problemes de drivers AMD...

Je me retrouve à utiliser les drivers libres.

J'ai constaté ce matin, qu'un nouveau kernel 14.3 était disponible. Je l'installe donc (quelle erreur !), apres avoir constaté, non sans regret, qu'il n'y avait toujours pas de nouveau drivers proprio auters que ceux proposé le 25/4/2014 (voir posts précédents).
Je désinstalle les drivers proprio sur le noyau 14.2, reboot (en niveau 5 voir 3 [init]) sur le nouveau noyau, constate que j'ai toujours ces problemes de DKMS à l'installaiton, du coup, je redémarre sans trop d'illusion et constate que les drivers ne fonctionnnent pas.
Mais le moins drole c'est que maintenant, les drivers proprio (beta [question de Xserver] ou pas) ne sont plus "installable" sur le noyau 14.2.

Je dois aller me calmer un peu, car j'ai eu de droles d'idées de changer de distribution qui ont parcouru mon esprit, je dois vraiment etre à bout. Je vais aller me changer les idées.
Peut etre pourriez vous m'orienter vers de nouvelles pistes ?

Fil partiel des manipulations
1/ constat maj de noyau disponible
2/ yum update
3/ /usr/share/ati/amd-uninstall.sh
4/ redémarrage sur le nouveau noyau
5/ les drivers libres prennent le relai, c'est bien, mais lent, installation des drivers BETA
6/ redémarrage sur le nouveau noyay
7/ les drivers proprio sont bien actifs, mais tous mes écrans ne fonctionnent pas
8/ restauration de la configuration (xorg.conf dans /etc/X11/) que j'avais sauvegardé pour cette version de drivers proprio..
9/ redémarrage
10/ pas de changement, mon 3eme écran et ma deuxieme carte graphique ne sont toujours pas reconnus
...


J'ai recommencé, en init 3, j'ai meme testé les drivers proprio "stables" mais uniquement valider pour Xserver jusque la version 1.13. Pour rappel, on est en 1.14.
Toi tu confond noyau et pilote! Le noyau linux est en 3.14.3, il faut que le pilote le supporte vu que le noyau avance à grande vitesse ce dont le pilote proprio ne fait pas. Ce qui changera d'ici quelque temps...

Pour le pilote libre, il faut attendre mesa 10.2 pour certaines Radeon, surtout après les HD6xxx.

D'ici 15j j'accueille une R9 270X (une 7xxxx re-badgé boostée) ou une R9 280X. Je pourrai en dire plus d'ici là, mais pas avant 2 semaines environs. Cela permettra si possible de reprendre la doc vu que je ne trouve personne pour travailler avec moi avec des radeon plus performante. Déjà je renouvelle cpu/cm/ram, car vu ce que je fais avec ma machine actuel, le défaut du deuxième cœur de mon AMD 64x2 4600+ déconne trop souvent. (jusqu'au plantage noyau à répétition...).

Je vais aussi reprendre le chemin du packaging de mesa version développement, j'ai trouvé quelqu'un pour héberger le dépôt.
Non, je ne confonds pas, j'écris rapidement et ne me relis pas (trop ennervé)
Oui, il s'agit bien du noyau 3.14.3-200 qui me pose probleme depuis ce matin.
J'ai réussi à revenir à la configuration sur le noyau 3.13.10-200.fc20.x86_64, en mettant à jour les "mesa : 
yum --enablerepo updates-testing update mesa*
C'est la série des 3.14 qui a eu des modifs qui font que, ce n'est pas non plus un bogue du noyau, mais ça fait que le pilote proprio déconne.

Comme je l'ai dit ailleurs, d'ici quelques temps le pilote proprio vas reposer sur le pilote du noyau directement et sur gallium/mesa, du coup normalement il ne devrait plus y avoir de souci à ce niveau là. Il n'y aura plus que certaines parties "propriétaire" qui viendront se greffer dessus.
ozit wrote:Non, je ne confonds pas, j'écris rapidement et ne me relis pas (trop ennervé)
Oui, il s'agit bien du noyau 3.14.3-200 qui me pose probleme depuis ce matin.
Je te fais remarquer que cela a déjà été dit dans d'autres fils. Pour le moment, rester en noyau 3.13, ou tout au minimum augmenter la valeur de installonly_limit de manière à toujours conserver un noyau 3.13 opérationnel.

Pour ma part j'ai mis une ligne exclude=kernel* dans le fichier /etc/yum.conf
J'ai eu la meme idée pour me prémunir de tout nouveau probleme (de ne plus accepter de maj du noyau).
@
A tout hasard, conserver dans un dossier les paquets kernel, kernel-devel, kernel-headers, kernel-doc de la version 3.13 pour les réinstaller en cas de besoin.

Ils sont disponibles sur ftp.free.fr, section update.
Nouveau kernel 3.14.4-200, aujourd'hui !
Pas de nouveau pilote propriétaire ou beta chez AMD
Et toujours le meme probleme, obligeant à rester sur le kernel 3.13.10-200 🙁
C'est au pilote proprio de se mettre à la page.com déjà que l'on parle du 3.15...
Vivement une amélioration, j'ai l'impression de stagner (techniquement), mais que fait AMD ?
VINDICATORs wrote:C'est la série des 3.14 qui a eu des modifs qui font que, ce n'est pas non plus un bogue du noyau, mais ça fait que le pilote proprio déconne.

Comme je l'ai dit ailleurs, d'ici quelques temps le pilote proprio vas reposer sur le pilote du noyau directement et sur gallium/mesa, du coup normalement il ne devrait plus y avoir de souci à ce niveau là. Il n'y aura plus que certaines parties "propriétaire" qui viendront se greffer dessus.
AMD a déjà répondu qu'ils refusaient de courir derrière Fedora au motif que les modifications sont apportées de manière intempestive et sans informer les tiers afin qu'ils puissent en tirer les conclusions et réagir.

Et ils répondent : vous n'avez qu'à utiliser une distribution qui ne change pas toutes les dix minutes.
On m'a quand même répondu ça:

Apply this patch or edit "/lib/modules/fglrx/build_mod/firegl_public.c" and recompile fglrx kmod.
I tried it under "3.14.4 fc20 x86_64" and "Catalyst 14.4 beta" driver.
diff -rup orig/firegl_public.c /lib/modules/fglrx/build_mod/firegl_public.c
--- orig/firegl_public.c 2014-05-17 04:09:11.729270252 +0900
+++ /lib/modules/fglrx/build_mod/firegl_public.c 2014-05-17 03:50:53.632524689 +0900
@@ -1784,7 +1784,8 @@ KCL_TYPE_Uid ATI_API_CALL KCL_GetEffecti
#else

#ifdef current_euid
-    return current_euid();
+//    return current_euid();
+    return __kuid_val(current_euid());
#else
     return current->euid;

#endif
3 mois plus tard
nouvo09 wrote:On m'a quand même répondu ça:

Apply this patch...
Ouais enfin bon depuis 3 mois ils n'ont même pas jugé bon d'intégrer ce patch à leur version beta (dernière release 14/07/2014)...
Comme je n'ai pas de carte récente pour tester, je ne peux confirmer pour pouvoir modifier la doc en conséquence. Il serait bon de le proposer avec un paquet qui vas bien, chose que rpmfusion ne fait plus depuis longtemps... Si cela ne tiens qu'à un patch, je ne pense pas que ce soit bien compliqué à mettre en place non?

A voir... à la rentrée j'ai une R9 280x qui arrive, je verrai bien à ce moment là selon ma disponibilité. J'ai le matos pour le faire, mais le temps risque de me manquer.

Mais si il n'y a pas de soucis avec le patch, il a sa place dans la doc quand même, surtout si la méthode reste simple.