je viens d'essayer les pilotes ATI avec le kernel 2.6.30 ça rox :-D
21734 frames in 5.0 seconds = 4326.079 FPS
# yum update --enablerepo=fedora-updates-testing
# yum install kmod-catalyst --enablerepo=rpmfusion-nonfree-updates-testing
j'ai un kernel 2.6.30 et un xserver plus récent aucun soucis avec ATI en revanche le xserver a cassé l'accélération 3D de ma carte intel sur le netbook :roll:
bioinfornatics wrote:je viens d'essayer les pilotes ATI avec le kernel 2.6.30 ça rox :-D
21734 frames in 5.0 seconds = 4326.079 FPS
Tu as quoi comme carte graphique?
nouvo09 wrote:
lecbee wrote:J'ai voulu tester ces pilotes. Résultat : hachures comme vous après le démarrage. (J'entends le son démarrage de KDE pourtant, donc derrière tout semble fonctionner).
Désinstallation immédiate et remise du pilote libre "radeon" : ça marche beaucoup mieux. Ils savent vraiment pas faire de pilotes chez ATI.
Je pense qu'il faudrait peut-être poser la question autrement. Fedora se veut une distribution d'avant garde. Comment un fabricant de matériel peut-il soutenir le même rythme ?

Il se trouve, pour ceux qui pensent que ATI travaille mal, que j'ai 2 Centos qui tournent, que ce sont des clones de RedHat comme chacun sait, et que sur ces Centos, les pilotes ATI s'installent en un clin d'oeil, à partir du pilote proprio, sans aucune manipulation particulière.

Qui travaille mal alors ?
C'est ce que je me tue à dire, mais bon...

Nvidia à eu pas mal de déboire aussi avec F11, la différence est que les bétâ récentes sont toujours là alors que chez ATI les pilotes sont à J -1 à 2 mois, mais cela je l'ai déjà expliqué il y a peut...

NVIDIA à l'air de moins dépendre du noyau si je ne me trompe pas...

Sinon pas mieux que ce que dit nouvo09, Fedora évolue tellement vite qu'il faut pouvoir suivre derrière, sans compter qu'ils apportent tellement de nouvelle choses que c'est souvent dure de suivre.

F11 testé avec pilote 9.8 au propre sur le disque externe et aucun soucis, cela fonctionne aussi bien que sur F10 (et F10 avec le 2.6.29.. d'update-testing).

Par contre même bogues qu'avec F10 au niveau du panneau de contrôle, mais cela est connu chez ATI et devrait être corrigé dans la prochaine version (quelques erreurs de segmentation par moment assez pénible lors du choix de la résolution et des modes écrans...).
lecbee wrote:NVIDIA fournit un pilote proprio fonctionnel pour F11 depuis un certain moment déjà il me semble. Comme quoi un fabricant de matériel peut soutenir le rythme si il s'en donne les moyens.
Ca ne prouve rien. Si dans le même temps ses composants n'ont pas beaucoup évolué, le fabricant n'a pas trop de mal à faire évoluer ses pilotes. En revanche si dans le même temps un fabricant fait évoluer beaucoup ses caractéristiques, il ira clairement au plus pressé et favorisera les distributions les plus nombreuses et les plus représentatives.

Lance le pilote proprio ati avec l'option --listpkg tu verras combien de distribs sont supportées. Alors dire qu'ils ne savent pas écrire de pilotes est un peu tendancieux.
Bizarrement Stewart Adam (qui s'occupe de la construction des paquets ATI chez rpmfusion) n'a pas rencontré de soucis, et il est pointilleux généralement...
Question aux propriétéaires de cartes ATI avec gpu <= R5xx: Quelqu'un a-t-il essayé d'installer la version 9.3 du pilote proprio sur F1 en utilisant les paquets pour F10?

Si oui, avec quel succès (ou insuccès)?
Ce pilote ne fonctionne pas avec le noyau 2.6.29 et +!

Voilà c'est dit...
Le temps que ces pilotes arrivent à maturité, oui... Mais cela devrait le faire d'ici peut...
J'ai re-installé les pilotes, j'ai modifié le xorg.conf en remplaçant fglrx par radeonhd. Mais je pense que je vais mettre vesa à la place.

Et j'ai le droit à ceci:
$fglrxinfo 
fglrxinfo: error while loading shared libraries: /usr/lib/catalyst/libGL.so.1: cannot restore segment prot after reloc: Permission denied
Le SELinux:
Résumé:

SELinux is preventing fglrxinfo from loading /usr/lib/catalyst/libGL.so.1.2
which requires text relocation.

[b]Description détaillée:[/b]

The fglrxinfo application attempted to load /usr/lib/catalyst/libGL.so.1.2 which
requires text relocation. This is a potential security problem. Most libraries
do not need this permission. Libraries are sometimes coded incorrectly and
request this permission. The SELinux Memory Protection Tests
(http://people.redhat.com/drepper/selinux-mem.html) web page explains how to
remove this requirement. You can configure SELinux temporarily to allow
/usr/lib/catalyst/libGL.so.1.2 to use relocation as a workaround, until the
library is fixed. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.

[b]Autoriser l'accès:[/b]

If you trust /usr/lib/catalyst/libGL.so.1.2 to run correctly, you can change the
file context to textrel_shlib_t. "chcon -t textrel_shlib_t
'/usr/lib/catalyst/libGL.so.1.2'" You must also change the default file context
files on the system in order to preserve them even on a full relabel. "semanage
fcontext -a -t textrel_shlib_t '/usr/lib/catalyst/libGL.so.1.2'"

[b]Commande de correction:[/b]

chcon -t textrel_shlib_t '/usr/lib/catalyst/libGL.so.1.2'

[b]Informations complémentaires:[/b]

Contexte source               unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Contexte cible                system_u:object_r:lib_t:s0
Objets du contexte            /usr/lib/catalyst/libGL.so.1.2 [ file ]
source                        fglrxinfo
Chemin de la source           /usr/bin/fglrxinfo
Port                          <Inconnu>
Hôte                         aspire8920g
Paquetages RPM source         xorg-x11-drv-catalyst-9.8-1.fc11
Paquetages RPM cible          xorg-x11-drv-catalyst-libs-9.8-1.fc11
Politique RPM                 selinux-policy-3.6.12-78.fc11
Selinux activé               True
Type de politique             targeted
MLS activé                   True
Mode strict                   Enforcing
Nom du plugin                 allow_execmod
Nom de l'hôte                aspire8920g
Plateforme                    Linux aspire8920g 2.6.29.6-217.2.8.fc11.i686.PAE
                              #1 SMP Sat Aug 15 01:07:59 EDT 2009 i686 i686
Compteur d'alertes            5
Première alerte              lun. 24 août 2009 19:25:23 CEST
Dernière alerte              mar. 25 août 2009 12:22:20 CEST
ID local                      fde7f1cf-f440-472b-bebe-ac7960a17c99
Numéros des lignes           

Messages d'audit bruts        

node=aspire8920g type=AVC msg=audit(1251195740.914:32423): avc:  denied  { execmod } for  pid=3794 comm="fglrxinfo" path="/usr/lib/catalyst/libGL.so.1.2" dev=dm-0 ino=32996 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=file

node=aspire8920g type=SYSCALL msg=audit(1251195740.914:32423): arch=40000003 syscall=125 success=no exit=-13 a0=dfb000 a1=85000 a2=5 a3=bfb5a1f0 items=0 ppid=2791 pid=3794 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=1 comm="fglrxinfo" exe="/usr/bin/fglrxinfo" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
Moi je pense que ça vient de fglrx, car j'ai pu installé kmod-catalyst et avoir une session graphique, sans aucun problème en modifiant fglrx par radeonhd.
deltaromeo wrote:Désolé de revenir, mais ca marche po

J'ai bien démarré en init3, j'ai fait une remove kmod-catalyst, mais au redémarrage toujours ecran blanc...

Il doit me manquer quelquechose
J'étais dans le même cas que le tiens, perso j'ai fait un: 
yum remove livna-config-display kmod-catalyst xorg-x11-drv-catalyst*
Pour supprimer toutes les dépendances installées lors de l'installation du kmod-catalyst, ensuite j'ai remplacé mon xorg.conf par celui que j'avais mis en backup (vu mes déboires avec les drivers ATI je ne prend plus de risques maintenant :-P) 
su -
cp /etc/X11/ton_xorg_backup /etc/X11/xorg.conf
En attendant les catalyst 9.8 ne marchent tjrs pas chez moi, toujours, ce patchwork avec des hachures (comme pas mal de monde ici), que ce soit avec le .run ou du dépot, même résultat, j'ai aussi essayé un "nomodeset" dans la ligne de boot de kernel de grub et rien de plus.
Si ceux qui ont réussi à faire fonctionner les drivers pouvaient filer un ptit coup de main :-D
Au passage vous pensez à virer tout ce qui peut toucher à fglrx/catalyst comme le /etc/ati/ ou en faisant une recherche? Faire un updatedb en root pour avoir une base de donnée de vos fichiers mis à jours!

Selinux en permissif?
STALKER59 wrote:J'ai re-installé les pilotes, j'ai modifié le xorg.conf en remplaçant fglrx par radeonhd. Mais je pense que je vais mettre vesa à la place.

Et j'ai le droit à ceci:
[b]Description détaillée:[/b]

The fglrxinfo application attempted to load /usr/lib/catalyst/libGL.so.1.2 which
requires text relocation. This is a potential security problem. Most libraries
do not need this permission. Libraries are sometimes coded incorrectly and
request this permission. The SELinux Memory Protection Tests
(http://people.redhat.com/drepper/selinux-mem.html) web page explains how to
remove this requirement. You can configure SELinux temporarily to allow
/usr/lib/catalyst/libGL.so.1.2 to use relocation as a workaround, until the
library is fixed. Please file a bug report
(http://bugzilla.redhat.com/bugzilla/enter_bug.cgi) against this package.

[b]Autoriser l'accès:[/b]

If you trust /usr/lib/catalyst/libGL.so.1.2 to run correctly, you can change the
file context to textrel_shlib_t. "chcon -t textrel_shlib_t
'/usr/lib/catalyst/libGL.so.1.2'" You must also change the default file context
files on the system in order to preserve them even on a full relabel. "semanage
fcontext -a -t textrel_shlib_t '/usr/lib/catalyst/libGL.so.1.2'"

[b]Commande de correction:[/b]

chcon -t textrel_shlib_t '/usr/lib/catalyst/libGL.so.1.2'

[b]Informations complémentaires:[/b]

Contexte source               unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
                              023
Contexte cible                system_u:object_r:lib_t:s0
Objets du contexte            /usr/lib/catalyst/libGL.so.1.2 [ file ]
source                        fglrxinfo
Chemin de la source           /usr/bin/fglrxinfo
Port                          <Inconnu>
Hôte                         aspire8920g
Paquetages RPM source         xorg-x11-drv-catalyst-9.8-1.fc11
Paquetages RPM cible          xorg-x11-drv-catalyst-libs-9.8-1.fc11
Politique RPM                 selinux-policy-3.6.12-78.fc11
Selinux activé               True
Type de politique             targeted
MLS activé                   True
Mode strict                   Enforcing
Nom du plugin                 allow_execmod
Nom de l'hôte                aspire8920g
Plateforme                    Linux aspire8920g 2.6.29.6-217.2.8.fc11.i686.PAE
                              #1 SMP Sat Aug 15 01:07:59 EDT 2009 i686 i686
Compteur d'alertes            5
Première alerte              lun. 24 août 2009 19:25:23 CEST
Dernière alerte              mar. 25 août 2009 12:22:20 CEST
ID local                      fde7f1cf-f440-472b-bebe-ac7960a17c99
Numéros des lignes           

Messages d'audit bruts        

node=aspire8920g type=AVC msg=audit(1251195740.914:32423): avc:  denied  { execmod } for  pid=3794 comm="fglrxinfo" path="/usr/lib/catalyst/libGL.so.1.2" dev=dm-0 ino=32996 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:lib_t:s0 tclass=file

node=aspire8920g type=SYSCALL msg=audit(1251195740.914:32423): arch=40000003 syscall=125 success=no exit=-13 a0=dfb000 a1=85000 a2=5 a3=bfb5a1f0 items=0 ppid=2791 pid=3794 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=1 comm="fglrxinfo" exe="/usr/bin/fglrxinfo" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
Moi je pense que ça vient de fglrx, car j'ai pu installé kmod-catalyst et avoir une session graphique, sans aucun problème en modifiant fglrx par radeonhd.
Navré mais tu dis n'importe quoi. Tu as un message en clair qui dit que SElinux interdit l'accès au composant demandé et que ca bloque le démarrage de la session graphique. Pourquoi crois-tu que je t'ai posé la question?

Et tu penses.. que dis-je, tu supputes, tu subodores, tu imagines, tu entrevois que ça "doit" venir de fglrx.

Si tu ne comprends pas le message, alors dis-le et on t'aidera à y voir plus clair et à résoudre le souci, mais de grâce n'invente pas, Fedora-fr.org n'étant pas un forum d'arts divinatoires.
STALKER59 : la réponse à ton problème était dans le message de rapport de SELinux :
Commande de correction:

chcon -t textrel_shlib_t '/usr/lib/catalyst/libGL.so.1.2'
Ceci dit, pourquoi utiliser cette commande qui repose sur les pilotes proprios alors que tu utilises désormais radeonhd ?
Mouhais... c'est bien ce que je dit que des expériences hasardeuse sans suivre les conseils que l'on est pas mal à donné ici fait que cela a mis un beau bazar dans les installations...

Je vais voir ce que cela donne avec des bidouillages...
Oui enfin s'il utilise radeon ou radeonhd je ne pense pas que le binz dans les bibliothèques fglrx soit gênant.

Par contre ce que ne je comprends pas c'est que chez moi sans fichier xorg.conf, apparemment le pilote chargé par DDC est : ati (si je ne m'abuse)
Je vient d'installé en netinstall F11(xfce) sur mon powerbook g4 est je rencontre de gros problème graphique.
Déjà avant la barre de chargement j'ai cette erreur qui s'affiche sur l'écran "radeonFB 0000:00:10.0: Invalid ROM contente"
Une fois démarré tout texte est illisible

Je démarre en mode 3 je vais voire dans X11 et la pas de xorg.conf, donc je ne vois pas quoi faire.
# yum install system-config-display
# system-config-display &
et s'il vous plaît retenez problème xorg == commande suivante: 
grep -E "EE|WW" /var/log/Xorg.0.log
Merci
Voila le résulta de Xorg.0.log 
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(II) Loading extension MIT-SCREEN-SAVER
(WW) Falling back to old probe method for fbdev
(WW) RADEON(0): Failed to read PCI ROM!
(WW) RADEON(0): Failed to read PCI ROM!
(WW) RADEON(0): Unrecognized BIOS signature, BIOS data will not be used
(WW) RADEON(0): Video BIOS not detected, using default clock settings!
(WW) RADEON(0): Panel size 1280x854 is derived, this may not be correct.
(WW) RADEON(0): DRI init changed memory map, adjusting ...
(WW) RADEON(0):   MC_FB_LOCATION  was: 0xbbffb800 is: 0xbbffb800
(WW) RADEON(0):   MC_AGP_LOCATION was: 0xffffffc0 is: 0xbc7fbc00
Sinon j'ai installer system-config-display mais avec le problème d'affichage il est presque inutile, j'ai teste avec vesa plutôt que radeon mais la plantage total, je suis donc repasser sur radeon mais le problème persiste.