Reprise du message précédent :
quel type de connectique est utilisé ?

vga, dvi ou hdmi ?

si dvi il faudrait vérifier la qualité du cable et tester sur le second port dvi de la carte s'il y a 2 ports dvi

quelle est la marque de l'écran ?
écran cathodique ou LCD ?

pour la carte graphique il faudrait voir s'il y a moyen de flasher le firmware de la carte vers une version plus récente qui corrigerait le problème, attention c'est une opération à risque, c'est comme flasher le bios d'une carte mère

Oui c'est en 144Hz que tout déconne... MST c'est DP 1.3 non? Je suis en 1.2.
 
L'accélération graphique fonctionne. Driver xf86-video-ati-git. Et mesa-git aussi. DRI3 activé.
 
Edit :  
 
L'écran c'est un Asus MG279Q. Connecté en mini displayport sur une sapphire 290X.

J'ai supposé qu'il était en DP.
 
Repose ces ROM de cartes tout de suite
Ca c'est le dernier recours.
 
Il y a déjà beaucoup à faire avec les firmwares au runtime.
 
farika, pastebin-nous ton dmesg, ton Xorg.log aussi et un pacman -Q aussi tant qu'à faire.

quel est l'interêt de mettre une fréquence de rafraichissement supérieure à 60 hz avec un écran LCD ?

à priori 60hz ( ou à la rigueur 75 ) suffit sur un écran LCD, car l'affichage n'a rien à voir avec un écran cathodique ( l'image est affichée d'un seul tenant et non pas ligne par ligne, pas de balayage, donc aucun intérêt à mettre des valeurs XXL type 144 hz  )

Elbarto : Pour la fluidité car sous windows je joue et 60 c'est pas fluide. D'ailleurs sous linux j'ai même du ghosting sur le scrolling en 60 hz... C'est un écran freesync (que je désactive sur linux). En  60 hz tu vois l'ufo non fluide. En 144 c'est fluide : http://www.testufo.com/#test=framerates . De plus en jeu , un écran 60Hz avec un gpu qui envoie 45 fps va se caler en vsync au pallier en dessous : 30... Et là c'est la cata.  
 
Le xorg.log : http://pastebin.archlinux.fr/1903479
Dmesg : http://pastebin.archlinux.fr/1903480
Pacman -Q : http://pastebin.archlinux.fr/1903481
 
A savoir qu'il me reste 20 j pour me rétracter de l'écran si c'est lui qui merde. Pas du gpu par contre.  

ah la la cette arnaque marketing sur la fréquence de rafraichissement :

https://www.asus.com/fr/Monitors/MG279Q/

du 144hz n'est à priori justifié que pour un affichage 3D avec des lunettes :

https://fr.wikipedia.org/wiki/Fr%C3 [...] chissement

pour la fluidité dans les jeux je pense que c'est un réglage dans le jeu ou le pilote afin de synchroniser le nombre de FPS coté openGL avec celui affiché par l'écran, comme ça tout sera synchro, une option pour limiter le nombre de FPS dans le jeu à 60 ( au passage ça va soulager la carte graphique qui pourra consacrer sa puissance à d'autres paramètres plus importants comme la qualité des textures, le lissage des contours )

edit : finalement tu as peut-être raison pour ces histoires de 144hz et de fluidité, je ne suis pas très gaming et il se peut que certains écrans aient besoin de beaucoup de FPS pour donner une impression de fluidité dans les jeux

Apparemment MST c'est DP1.2.
 
Je vois rien de spécial dans tes logs.
A part que toute la stack video est en version instable
 
Je te conseille de contacter des devs du dri sur IRC ou par leur ml, regarde si y a pas des bugs déjà ouvert là-dessus sur le bugzilla du kernel d'abord.

C'est surtout que le 144Hz a des fréquences de rafraichissement intermédiaires quand on arrive pas à tenir le 60 FPS. a 1440p de résolution c'est compliqué sur des jeux gourmands. 36 > 48 > 72 > 144fps.
Alors qu'en 60Hz c'est soit tu tiens les 60, soit tu tombe à 30.
 
Edit : Je vais repasser la 7950 pour vérifier le problème mais j'ai bien l'impression que c'est depuis la 290X. J'ai l'écran depuis 48h et le gpu depuis 24h.  
 
Ensuite je peux peut être essayer les driver proprio?

 
Crois-moi, même sur le desktop (Windows ou Linux), sur un écran 120hz ou 144 hz, switche entre 60 hz et 120 / 144 hz, je peux te JURER qu'on voit clairement la différence de fluidité, c'est le jour et la nuit.

Bon je viens de remonter la 7950 et aucun problème en 144 hertz donc je pense qu'on peut élimer la piste écran... mais il reste la piste gpu avec les drivers etc...  
 
Le même cable displayport a été utilisé mais à l'envers... La 7950 a des mini display port alors que la 290X n'a que le gros et mon écran a les deux.
 
Sur la config de l'affichage madeinkde je vois quand même une différence. Sur la 7950 j'ai même pas le choix et il me balance du 144 hertz d'un coup. Alors que sur la 290X il me fait du 139,9 hz foireux et j'ai des choix.
 
Je reremonte la 290X.
 
Edit : Donc c'est bien à 290x que le problème est et uniquement à 144Hz. En fait dès grub il se calle à 144hz. Ensuite quand KDE est démarré il se recalle à 60 et le problème disparait et revient si je remet le 144. Donc peut être que la carte est foireuse , mais je n'ai aucun soucis sous windows... Donc ça laisse quand même penser que...  
 
Edit2 : Grub et Linux sous la 290X détectent mal mon écran. Dans la configuration je vois qu'un 143,9hz à activer, et ce qui donne un 139hertz sur l'OSD de mon écran. Alors que sous la 7950 c'est 144 sous KDE + OSD. J'ai beau faire un xrandr --rate 144 il me balance toujours du 143.86 qui donne 139 dans l'OSD.

C'est louche que KDE se recale à 60Hz.
Si tu changes la résolution à la main par xrandr ça fait pareil ?
Tu pourrais virer xf86-video-ati et tester le module modesetting inclus dans Xorg, des fois que...
Mais le problème semble "plus bas" quand même là.

Oui je viens de tester. La 7950 active bien le 144 hertz avec xrandr. Alors que la 290X ne veut rien savoir et se cale à une fréquence bateau. C'est moi qui a forcé le 60 sur KDE pour vous parler et ne pas avoir le probleme. Pas sur que ce soit top pour l'écran de tourner à une fréquence bizarre .

Ca sent le MST foireux, je maintiens
Attends linux 4.5 (Ou parle du problème aux devs)

Je suis revenu faire deux photos. Tu sais qui il faut que je contacte ?  
 
7950 : 144 hertz activé et 144 hertz réel. Aucun soucis
 

 
290 : Même xrandr, mais 139 hertz foireux réel. Ecran flou , barre à gauche qui vibre et artefacts.

 
Aucun soucis à 60Hz sur les deux cartes.

Parfaites ces 2 photos
Commence par #dri-devel sur freenode, tu trouveras peut-être des réponses déjà.

J'ai tenté un bug...  
 
https://bugs.freedesktop.org/show_bug.cgi?id=93826
 
Mais il y en a plein de NEW... Je ne sais pas si c'est rapidement traité

J'ai également tenté #dri-devel mais les non voicé n'ont pas le droit de parler sur le channel .

Faut probablement réserver son nick d'abord, ça fait un moment que j'y suis pas allé.
Le serveur doit te dire ce qu'il attend quand tu te connectes ou essaie de poster normalement.

Test Catalyst proprio : 144Hz bien activé, ça roule ... Mais plein de merde autour (accélération qui marche pas sur firefox et scrolling qui rame à mort).  
 
Mais ca prouve quand même que mon soucis vient des driver libres et même des drivers VGA : J'ai toujours le problème sur grub... Et la je ne vois pas comment le résoudre, on peut pas installer catalyst sous grub   . Il faudrait forcer grub à me balancer une autre résolution inférieure. Avec le bios pareil , il tente le 2560x1440 et il foire à me mettre le bon refresh rate. J'ai pu dire au bios de me mettre une résolution inférieure.  
Et je resterais en driver proprio jusqu'à que les libres soient corrigés  

tu as essayé de forcer une modeline correcte avec les pilotes libres ?
 

 
pour revenir à la configuration prédétectée :

 
Si ça marche pour fixer tout ça, il faudra aller configurer xorg.conf

Glouwps non vu que le passage au proprio a soldé le problème tout seul.
 
Pour grub j'ai pas réussi à faire marcher le 2560x1440_144.0 mais GRUB_GFXMODE=1200x800 dans /etc/default/grub a en parti résolu le problème. Il calle bien la résolution en 1200 et puis bon 144 Hz dans grub c'est pas trop utile .

Bon j'ai essayé de repasser aux drivers libre pour tester la manip de Mjules... Et j'ai tout planté. Ca ne démarre plus après le fsck... Et je n'arrive pas à avoir d'invite... Impossible de lancer un autre TTY quand il a fini... Et pas de message d'erreur.  
 
https://wiki.archlinux.org/index.ph [...] stallation
 
Normalement j'ai bien suivi cette partie... Et xorg-server 1.18 est bien remis avec x86-video-ati...
 
Help  

il fallait anticiper ce problème en créant une entrée dans grub pour démarrer en mode minimal de secours dans une console,

avec systemd il suffit d'utiliser le mode "rescue target" en ajoutant cette option pour le noyau :

autre alternative : démarrer avec une clé USB ou un CD de boot afin de faire un "chroot" pour annuler la modif que tu as faite :

https://wiki.archlinux.fr/Chroot

avec archlinux vu le coté rolling-release il est important de connaitre ces deux astuces pour s'auto-dépanner, sinon au moindre bug/paquet~noyau bogué qui rend le boot impossible tu vas être bloqué

Hm ouais... J'ai pas pensé à créer ça... Je le ferais dès que j'aurais sauvé mon système car là j'échoue là :

Si t'arrives jusque la tu devrais avoir acces a TTY avec CTRL+ALT+F2

Nan le clavier veut rien savoir... Même un CTRL + ALT + SUPR ne marche pas. Je ne sais pas pourquoi .

Je sais qu'il y a un moyen d'éditer la ligne de boot dans grub (en appuyant sur e) pour lancer une console en root et réparer ton système. Ton problème m'est déjà arrivé et j'avais fait ça. J'essaie de retrouver comment faire...

essaie de démarrer avec un CD de boot d'installation archlinux, tu fais ensuite les étapes classiques du chroot, ce qui te permettra d'annuler la modif que tu as faite,

et éventuellement de downgrader certains paquets ou de revenir aux pilotes libres

J'ai retrouvé : https://askubuntu.com/questions/132 [...] -from-grub

 
Super comme astuce. Ca marche ! Je suis en root...
 
Sauf que je ne vois pas ce qui merde   . Pas d'erreur kernel ni xorg ...

tes soucis me conforte dans l'idée que pour être peinard sous linux il vaut mieux avoir du vieux matos
 
sinon tu peux essayer d'autres valeurs pour le modeline ( sans sauvegarder les modifications dans un fichier ) puis de lancer l'interface graphique via la commande startx, si ça ne plante plus alors c'est que tu as trouvé le bon réglage

J'ai réinstallé tout les paquet en bloc mesa/ ati / xorg et ca démarre. Je test la manip de Mjules
 
EDIT2 et réponse à Mjules :  
http://pastebin.com/1iq1cWuT
J'étais en 60 Hz pour ne pas avoir le bug et j'ai ensuite suivi tes commandes. Après avoir suivi les commendes (cf pastebin) et activé le mode 2560x1440_144.00 j'ai eu un truc encore plus foireux : un 99hertz avec l'image qui vibre de partout...
J'ai ensuite retenté un xrandr -s 2560x1440 -r 144 et là c'est le retour à la config foireuse de la page précédente avec artefact + flou + 139Hz réel sur l'OSD.
 
Pour rappel : Aucun problème sur windows et en catalyst proprio (sauf des lag sur firefox/ accélération video qui marche pas , mais c'est plus lié à fglrx)
Donc ca va être retour direct aux catalyst proprio ! Le driver libre n'aime pas le combo 290X (Hawai) + 144 hertz.

il serait intéressant de tester avec le noyau linux mainline 4.4-1 pour voir si ça va mieux avec le pilote libre :

https://aur.archlinux.org/packages/linux-mainline/

ne pas oublier de lancer la commande "grub-mkconfig -o /boot/grub/grub.cfg" pour qu'une nouvelle ligne "linux-mainline 4.4-1" soit ajouté dans le menu de grub

Pas mieux . J'étais en 4.4.0-4.
 
Après j'ai lancé un bug chez dri-devel... Pour l'instant il est toujours en attente.  
 
https://bugs.freedesktop.org/show_bug.cgi?id=93826
 
Je repasse sur fglrx en attendant un retour même si j'ai des soucis avec aussi... (surtout firefox qui rame:!). Mais au moins mon rafraichissement est correct directement.
 
EDIT : Oui en catalyst , quand il y a scrolling (sous hfr c'est affreux) xorg utilise 100% du cpu.
 
EDIT2 : malheureusement je n'ai pas l'impression que les bug radeon dri soient traités, ils ne sont jamais assignés... https://bugs.freedesktop.org/buglis [...] _id=567467  

Je n'aurais pas du leur dire que j'ai le même bug que sous le driver opensource avec grub... Du coup on me dit c'est ton hardware... Wai sauf que sous catalyst linux et windows je touche du bois...
 
 Michel Dänzer 2016-01-25 07:27:11 UTC
 
grub doesn't use this driver, so there might be a hardware/VBIOS issue. Maybe the other drivers work around that somehow.

Linux + radeon = corruption sous grub
Linux + catalyst = pas corruption sous grub  
 
C'est ça ? En effet c'est pas logique du tout.

 
Non ce n'est pas ca    
 
Linux + Catalyst ou Linux  + Radeon = Corruption sous grub mais rien à carrer car j'ai modifié la résolution sur grub avec GRUB_GFXMODE= pour un 1280 et du coup ça passe à 60Hz sans artefact. C'est grub , pas besoin d'être en 4K 144Hz .
 
Par contre sous Linux + Catalyst : Aucun soucis.  
Linux + Radeon : Ne marche qu'en 60Hz. Impossible d'activer un vrai 144Hz.
 
Et donc je voudrais que Radeon fonctionne comme sous Catalyst ou windows...

si on résume le problème c'est donc un problème lié à la technologie "freesync" utilisée par ton écran asus MG279Q et ta radeon R9 290X

http://www.amd.com/fr-fr/innovatio [...] g/freesync
https://en.wikipedia.org/wiki/FreeSync

il faudrait que le développeur linux chargé de la partie "freesync/adaptative sync" du pilote radeon ( ou du noyau linux ) tombe sur ton rapport de bug, en éditant le titre du rapport de bug pour ajouter le mot clé "freesync" ça pourrait attirer l'attention du développeur en question et les autres utilisateurs victimes de ce bug quand ils utiliseront le moteur de recherche

Rien a voir avec freesync. C'est en effet une option de mon moniteur mais je ne m'en sert qu'en jeu sous windows. Sous linux il est désactivé dans l'OSD : Freesync n'est pas encore supporté par linux (et n'est pas prêt de l'être... Contrairement à Gsync de nvidia). C'est donc un moniteur 144Hz comme les autres.
 
http://www.legitreviews.com/wp-con [...] /image.jpg
 
Par contre là tu as pas faux c'est que c'est lié à la 290X. Car comme je l'ai dit sur la page précédente je n'ai aucun problème avec le pilote radeon, le même écran (freesync off) et une 7950 ! Je pense donc à un probleme entre les puces "hawai" et le pilote radeon dans sa gestion des refresh rate.
 
Pour résumer (le tout avec le MG279Q):
Avec 290X:  
- Windows ok
- Catalyst FGLRX ok
- Linux Radeon @60Hz ok
- Linux Radeon @144Hz : Pas ok
- Grub : Ok @60Hz mais on s'en tape
 
Avec 7950 :  
Ok partout.

 
c'est quand même bizarre que le problème se produit dès grub alors que le pilote radeon n'est pas utilisé, ça conforte l'idée du gars qui t'a répondu dans le rapport de bug, un bug de bas-niveau lié à ta carte graphique, bios, un truc matériel ou connectique type cable douteux
 
les trucs de base type pilote vga ça doit marcher sans broncher quelque soit la carte, si ça se trouve le bug est présent aussi avec les utilitaires de boot windows type ms-dos ou utilitaire système si le même genre de pilote est utilisé,
 
est-ce qu'en utilisant memtest ( cd de boot ou clé USB ) tu as aussi un affichage corrompu ?
 
il y a la possibilité de vérifier si le bios de ta carte graphique radeon r9 290X est à jour, si une version corrige le problème, mais l'opération est risquée  
 
https://www.techpowerup.com/vgabios [...] 67b0--4002
http://www.clubic.com/forum/hardwa [...] page1.html
 
avant de tenter quoique ce soit : sauvegarde ton bios actuel avec GPU-Z,
 
si le rapport de bug n'avance pas alors essaie de poser ta question sur le forum amd :
 
https://community.amd.com/community [...] lastunread

Affichage corrompu aussi sous memtest.
 
J'ai ouvert un ticket chez sapphire mais bon , ca ne donne pas grand chose encore...  
 
La MAJ du bios n'a rien changé non plus.
 
Par contre chez amd on va éviter. Ils vont dire "utilisez le driver proprio" et en effet, avec j'ai pas de problème