• [supprimé]

  • Message #21
Essayes avec un "# yum localupdate --nogpgcheck <les_paquets_sur_ton_disque>"
j'ai lancé la commande : 
yum localupdate --nogpgcheck '/home/brain/Téléchargement/mesa-dri-drivers-7.8.1-6.fc13.x86_64.rpm' 
Modules complémentaires chargés : presto, refresh-packagekit
Configuration du processus de paquets locaux
Résolution des dépendances
--> Lancement de la transaction de test
--> Traitement de la dépendance : libdricore.so()(64bit) pour le paquet : mesa-dri-drivers-experimental-7.7-4.fc12.x86_64
--> Traitement de la dépendance : mesa-dri-drivers(x86-64) = 7.7-4.fc12 pour le paquet : mesa-libGL-7.7-4.fc12.x86_64
---> Paquet mesa-dri-drivers.x86_64 0:7.8.1-6.fc13 marqué pour être mis à jour 
--> Résolution des dépendances terminée
Erreur : Package: mesa-libGL-7.7-4.fc12.x86_64 (@updates)
             Requires: mesa-dri-drivers(x86-64) = 7.7-4.fc12
             Suppression: mesa-dri-drivers-7.7-4.fc12.x86_64 (@updates)
             Available: mesa-dri-drivers-7.6-0.13.fc12.x86_64 (fedora)
Erreur : Package: mesa-dri-drivers-experimental-7.7-4.fc12.x86_64 (@updates)
             Requires: libdricore.so()(64bit)
             Suppression: mesa-dri-drivers-7.7-4.fc12.x86_64 (@updates)
             Available: mesa-dri-drivers-7.6-0.13.fc12.x86_64 (fedora)
 Vous pouvez essayer d'utiliser --skip-broken pour contourner le problème
 You could try running: rpm -Va --nofiles --nodigest
On me propose de contourner le problème , mais est ce la bonne solution?
lecbee wrote:Essayes avec un "# yum localupdate --nogpgcheck <les_paquets_sur_ton_disque>"
Encore une fois, --nogpgcheck n'est pas la panacée et n'aura pas d'effet ici. Cette option ne fait qu'éviter de traiter les paquets en erreur, elle ne cherche pas à passer outre les conflits en écrasant des fichiers. Ici, le conflit mesa-dri-drivers.fc13/mesa-dri-drivers-experimental.fc13 empêchera cette mise à jour.

Accessoirement, je désapprouve cette tentative de mise à jour. Ou on passe à Fedora 13 sereinement, ou on se contente de Fedora 12.

  • [supprimé]

  • Message #24
Pikachu_2014 wrote:
lecbee wrote:Essayes avec un "# yum localupdate --nogpgcheck <les_paquets_sur_ton_disque>"
Encore une fois, --nogpgcheck n'est pas la panacée et n'aura pas d'effet ici. Cette option ne fait qu'éviter de traiter les paquets en erreur, elle ne cherche pas à passer outre les conflits en écrasant des fichiers.
Je sais très bien à quoi sert ce paramètre. j'aurais pu l'omettre mais moi je le met pour pas avoir à devoir encore à taper sur le clavier pour une confirmation.
lecbee wrote:
Pikachu_2014 wrote:
lecbee wrote:Essayes avec un "# yum localupdate --nogpgcheck <les_paquets_sur_ton_disque>"
Encore une fois, --nogpgcheck n'est pas la panacée et n'aura pas d'effet ici. Cette option ne fait qu'éviter de traiter les paquets en erreur, elle ne cherche pas à passer outre les conflits en écrasant des fichiers.
Je sais très bien à quoi sert ce paramètre. j'aurais pu l'omettre mais moi je le met pour pas avoir à devoir encore à taper sur le clavier pour une confirmation.
Dans ce cas, l'option « -y » eut été plus appropriée. Mais ça n'est pas plus fin, surtout pour installer des paquets « expérimentaux ».
Au passage il faut aussi mettre à jour les autres paquets avec mesa...

merci pour le -y, mais je pensé que --nogpgcheck était pour passer outre la signature non?
VINDICATORs wrote:Au passage il faut aussi mettre à jour les autres paquets avec mesa...

merci pour le -y, mais je pensé que --nogpgcheck était pour passer outre la signature non?
Bon , la mise à jour c'est correctement passé et ce sans aucune erreur ou bidouillage. Il suffisait de supprimer mon paquet mesa-experimental qui n'était lié lui , à aucun autres paquets . Et de mettre à jour mes paquets mesa par les plus récent avec un : yum localupdate

Merci à vous.
Normal, experimental est pour nouveau maintenant... (voir doc...)
VINDICATORs wrote:Et oui sans distinctions, les R8xx devraient être supporté d'ici peut (toujours d'après les rapports de développement et phoronix).
Un certain nombre d'échanges sur la kernel mailing list me rendent modérément optimiste sur la disponibilité rapide du support des R8xx avant le kernel 2.6.36.

Il semble en effet qu'il y ait un peu de flottement entre Dave Airlie et Linus Torvalds, ce dernier souhaitant avant tout au niveau drm que toutes les régressions soient fixées et non que de nouvelles fonctionnalités soient supportées :
Date Mon, 7 Jun 2010 11:00:51 -0700 (PDT)
From Linus Torvalds <>
Subject Re: [git pull] drm fixes



On Mon, 7 Jun 2010, Dave Airlie wrote:
>
> 3 regressions fixes, one radeon loading on IGP, one i865 loading, one and
> an evergreen userspace interaction workaround.

This is:

26 files changed, 372 insertions(+), 66 deletions(-)

and there are apparently several reports of known problems (the problem
with modesetting) that isn't even addressed.

See my -rc2 announcement. I absolutely do NOT want any new code. I want
regression fixes, fixes for security issues, and fixes for oopses. Nothing
else. I'm going to be hardassed about this, because quite frankly, if I'm
not, people will just continue with the same-old, same-old, and send me
random stuff without thinking hard about it.

So please. Just make me a tree that has regression fixes _only_. I'm not
AT ALL interested in "it is useful to report the gpu temp". If it was so
useful, and if it was ready before the merge window, it should hav gone in
then. That clearly wasn't the case, so it's not going in now either.

Linus
http://lkml.org/lkml/2010/6/7/240

Appliqué à la lettre, cela signifie que les nouveaux développements pour les R8xx ne seront pas intégrés dans le kernel dans l'immédiat...

Je pense personnellement qu'il ne faut pas se précipiter pour acheter une carte HD5xxx à base de R8xx et qu'il peut être intéressant d'acheter d'une carte de génération précédente.
Le support sera effectif avec Mesa au travers des développements de Gallium3D.

Après quand je parle rapidement cela ne veux pas non plus dire dans la minute qui suit cette information. Sans compter que ce n'est pas parce que ce n'est pas intégré officiellement dans le noyau officiel que cela ne sera pas le cas dans le noyau préparé par Fedora. Comme ce fut le cas avec nouveau et "radeon" pendant un moment (voir les discutions enflammés à ce sujet entre linus et les développeurs de nouveau...).

Par contre je ne pige pas cette histoire de "nouvelles fonctionnalité" à ce niveau. L'architecture R8xx "evergreen" commence à avoir de l'âge, donc il ne faudrait pas non plus attendre la saint glinglin pour être supporté.

Enfin bref... Tout cela ne dépend pas que du noyau.
Sur le pourquoi du nomodeset, man radeon en dit plus :
Option "ClockGating" "boolean"
Enable dynamic clock gating. This can help reduce heat and increase battery life by reducing power usage. Some users report reduced 3D
performance with this enabled. The default is off.

Option "ForceLowPowerMode" "boolean"
Enable a static low power mode. This can help reduce heat and increase battery life by reducing power usage at the expense of perfor-
mance. The default is off.

Option "DynamicPM" "boolean"
Enable dynamic power mode switching. This can help reduce heat and increase battery life by reducing power usage when the system is idle
(DPMS active). The default is off.
Vu ma faible utilisation de la carte graphique (Compiz, WoG), l'activation des deux dernières options étaient plus que bénéfique : diminution de 10°C de la température du GPU, avec le ventilateur toujours au minimum, une batterie qui durait plus longtemps. Malheureusement, ce n'est pas vraiment supporté par le Projet, donc avec les bugs dû à l'UMS, j'ai du fait un choix cornélien.
Au passage, si j'ai le temps, je vais entamer quelques tests sur les sections du xorg.conf dispatché en autant de fichiers. Comme cela à l'air de fonctionner comme cela maintenant (répertoire xorg.conf.d/).

Sinon le xorg.conf est toujours pris en compte prioritairement.

Par contre tu te passe de l'accélération matériel dans pas mal de cas.

  • [supprimé]

  • Message #33
VINDICATORs wrote:Au passage, si j'ai le temps, je vais entamer quelques tests sur les sections du xorg.conf dispatché en autant de fichiers. Comme cela à l'air de fonctionner comme cela maintenant (répertoire xorg.conf.d/).
Ah ouai ça sera cool parce que je pense que quasiment personne ne doit savoir comment cela fonctionne maintenant (moi le premier).
En fait c'est juste que normalement tout est séparé, mais faut que je confirme, parce que cela à l'air complexe dans un certain sens...
VINDICATORs wrote:Enfin bref... Tout cela ne dépend pas que du noyau.
Ma compréhension est que le driver xorg et mesa qui s'exécutent tous les deux en user space utilisent tous les deux les fonctionnalités drm du kernel au travers de libdrm.

Pour preuve, libdrm fait partie des dépendances requises :
$ rpm -qpR mesa-dri-drivers-7.9-0.1.fc14.x86_64.rpm
---/---
libdrm.so.2()(64bit)
libdrm_intel.so.1()(64bit)
libdrm_radeon.so.1()(64bit)
---/---
$ rpm -qpR xorg-x11-drv-ati-6.13.1-0.20100519git428125c09.fc14.x86_64.rpm
---/---
libdrm >= 2.4.17-0.1
libdrm.so.2()(64bit)
libdrm_radeon.so.1()(64bit)
---/---
A partir de là, tant que drm qui est inclut dans le kernel ne supporte pas complètement les r8xx j'ai du mal à voir comment ça peut fonctionner avec les cartes pourvues de ce GPU...
Oui mais seul cela ne fait pas tout. Après il faut voir comme ils vont faire et comment cela vas sortir. Mesa pousse pour que ce soit implanté dans Mesa 7.9 le plus rapidement possible, donc le reste devrait suivre aussi. Fedora/redhat est souvent en avance à ce sujet par rapport à la version "stable" officiel.

Les travaux de gallium3D avance rapidement à ce sujet et seront rapidement intégré à Mesa si tout vas bien.

De plus à la vitesse que sortent les RC du noyau, il faudra voir comment cela se présente.

Pour changer de sujet, j'aimerais bien pouvoir avoir accès aux versions Bétâ du pilote propriétaire, mais il faut se ubuntoutiser pour cela... Donc c'est rapé...
Je crois qu'il faut télécharger la version du noyau concernée, exécuter le patch grâce à la commande éponyme et compiler le tout :hammer:
J'allais le dire. Tu peux déjà passer à ce qui est indiqué sur le sujet principal.

De plus, encore une fois, ce patch est principalement à utiliser avec des cartes qui respectent les spécifications officiel de l'atombios, ce que certains équipementiers ne font pas à 100%... C'est souvent un beau bordel et la cause des problèmes à ce niveau! Demandé à certains qui ne passe pas par le pilote préparé par l'équipementier et qui est souvent, très vite, abandonné après quelques temps...

A ce sujet le top, au niveau de la gestion de la vitesse du ventilateur, serait de pouvoir avoir du semi-automatique. Une gestion automatique couplé à une mollette pour ajusté au mieux le niveau bruit/efficacité. Ce serait déjà une bonne idée... Ce qui ne peut se faire sur les ventilateurs d'origine.

Comme dit friandise, tu peux te construire un noyau avec ce patch, il faudrait voir du coté de la documentation pour cela : http://doc.fedora-fr.org/wiki/Recompilation_du_noyau_Fedora

A ce sujet, en cas de problèmes, tu pourra toujours relancer ta machine sur une version fonctionnel du noyau, vu que Fedora garde les 3 derniers et donc au moins un qui fonctionne...

N'oublie pas de nous faire un compte rendu de tes "expérimentations" à ce sujet si tu te lance dedans.