Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information

Journal : Les grands écrans c'est bien (mais galère)

Posté par Croconux () le 28 décembre 2007
Après avoir bien galéré, je me suis décidé à écrire ce journal car je pense que ça peut servir à d'autres.

Pour mon nowel, je me suis fait plaisir, je me suis acheté un grand écran qui troue les fesses : 24" 1920x1200, que du bonheur (pensais-je). J'ai passé une demi journée à galérer pour le faire fonctionner correctement. En démarrant sous Linux (Debian sid à jour), je me suis retrouvé avec une résolution très laide (1280x768). Bon, jusque là c'est normal, mon ancien écran était un 19" à tube donc je pensais naivement qu'en ajoutant les modes supplémentaires ça passerait. Que nenni. En cherchant sur le net, je me suis rendu compte que je n'étais pas un cas isolé. Visiblement, les écrans avec une résolution trop élevée (22" et plus) posent pas mal de problèmes. D'après ce que j'ai pu trouver, les modes jusqu'à 1600x1200 sont standardisé VESA mais au dessus, chaque fabricant d'écran fait un peu ce qu'il veut et c'est franchement le boxon.

Première piste, les modelines. Chez certains ça semble résoudre le problème. En cherchant à droite à gauche, j'ai vu que pour une même résolution, il y avait à peu près autant de timings que d'écrans. J'en ai essayé quelques uns sans succès. Dans Xorg.log, j'ai toujours "No valid mode for 1920x1200. Removing". Je me suis dit qu'il me fallait surement les timing exacts de mon écran. Bon, comment les obtenir ? Après enquête, chaque moniteur est capable de donner les informations sur les modes qu'il supporte. Plusieurs outils permettent de lire ses infos :

- "read-edid"/"get-edid" : Pas de bol ces outils font des appels VBE de bas niveau (un truc hérité du DOS) qui ne marchent qu'en 32bits et je suis sur AMD64. C'est mort.

- "xresprobe" : Un script fourni avec xorg. D'après ce que j'ai pu lire, il n'est pas trop maintenu et, contrairement à ce que dit la doc, il utilise encore les infos VBE (pour les DFP en tous cas). C'est mort aussi. Il me renvoie des infos vides.

- "ddcprobe" : Apparemment, il interroge la carte graphique et l'écran. Pas de bol non plus, il me liste une série de modes standards (jusqu'à 1280x1024) puis dans la section "edid" se contente d'un joli "edidfail". Tiens donc, mon écran renverrait-il des conneries ? Dans le doute je met la main sur une box windows pour voir ce que ça donne et là, plein les yeux. La résolution native de mon écran est reconnue et c'est magnifique. Bon si ça marche sans avoir installé le moindre driver, ça doit bien pouvoir marcher sous mon manchot, nom d'un eskimo à la banane !

Retour sous Linux mais cette fois en VGA (jusqu'ici j'avais utilisé le DVI). Bizarrement, là xorg me trouve le mode 1600x1200. Pas top mais il y a du mieux. "xresprobe" me trouve cette fois si des infos, même s'il reconnait pour le coup mon écran comme un CRT (c'est bizarre qu'en analogique on arrive à obtenir des infos et pas en numérique, mais bon). Du coup, il semble black lister les modes au dessus de 1600x1200. Après re-enquête, il s'avère qu'en interne, xorg ne fait plus appel à ces divers utilitaires pour lire les infos EDID. Il a sa propre méthode de lecture. Re-merde. Je sens que je vais finir par m'arracher les poils du cul à la pince à épiler.

Retour en DVI (si j'ai pris un écran avec prise DVI ce n'est pas pour passer par de l'analogique). Un bon moyen de voir ce qui se passe : En mode console, démarrer X avec un maximum de logs "startx -- -logverbose 6". Là je me rend compte qu'xorg arrive bien à lire les infos EDID. Il liste les modes standards -plus- les modes supplémentaires de mon écran et le 1920x1200 en fait partie avec les timings exacts et tout. Sauf qu'un peu plus loin la plupart des modes sont invalidés "Mode is rejected: VertRefresh (75.0 Hz) out range" (celui là je veux bien, à la résolution max, il ne supporte que du 60 Hz) ou bien "Mode is rejected: Mode (1920 x 1200) is too large for DFP. Native resolution (Max: 1280 x 768)". Apparemment xorg s'est planté sur le calcul de la résolution native de mon écran.

Visiblement, certaines infos remontées sont erronées et du coup xorg invalides des modes qui sont bien valides. Il existe plusieurs façon de passer outre. Dans la section "Device" du xorg.conf il est possible de mettre "UseEDIDDpi", "UseEDIDFreqs" ou carrément "UseEDID" à false. J'ajoute en modeline le mode exact remonté par mon écran et je tente le coup. Les deux premiers ne changent rien. Après hésitation je tente le 3e en priant et là c'est l'écran noir. Je sens que je ne suis pas couché. Il existe aussi une option "ModeValidation" "NoEDIDModes" mais rien à faire. Puis c'est l'illumination : Je découvre une option de la mort inconnue de la section "Monitor" : "ModeValidation" "NoDFPNativeResolutionCheck". Miracle, ça marche nickel.

Bilan des courses, c'est quand même un peu le bronx dès qu'on sort des sentiers battus. Il y a une foule d'options pas franchement documentées dans xorg plus sans compter le fait que sur la section "Device" suivant le driver utilisé, les options sont différentes ou ne s'appellent pas pareil. Sinon, j'ai aussi découvert qu'apparemment le port DVI est limité en débit et ne permet pas de faire passer les résolutions les plus élevées (c'est vraiment couillon pour une norme aussi récente). Pour celà, il faut un DVI dual link. La limite est définie par le standard mais il est possible de passer outre (les liaisons DVI acceptent souvent plus que ce que le standard impose) et d'autoriser un débit plus élevé (Option "NoMaxPClkCheck"). Si ça ne marche pas, il faut ajouter une modeline limitant le débit. Pour celà, l'utilitaire "cvt" permet de générer des modelines avec débit réduit (option "-r"). Le port VGA ne semble pas soumis à ce type de limitation.

Bon, voilà c'était un peu long mais je pense avoir expérimenté quasiment toutes les looses possibles donc si ça peut aider... Maintenant je peux mouler et travailler en même temps sans avoir à changer de bureau. Que du bonheur.

> Lire le journal (46 commentaires, moyenne: 1,4).  

Vous avez demandé le commentaire #892648.

Mon 22"

Posté par Ph Husson (page perso, ) le 28/12/2007 à 20:31. (lien). Évalué à 1.

J'ai recu hier un écran 22" en 1680x1050 qui n'est apparement pas une résolution VESA (enfin d'apres mon Xorg.0.log), et je dois avouer que j'ai eu des difficultés énorme à le faire marcher, j'ai eu besoin de euh... rien en fait...
J'ai branché l'écran, allumer mon ordinateur, et tout simplement constaté que le driver nvidia s'était mis dans la bonne résolution.

En ce qui concerne ton cas, j'ai lu ce que t'as dit tres rapidement, et à vue de nez ca ressemble plutot à ton écran qui dit des aneries (ou ta carte graphique qui ment). Le VBE n'a rien de spécifique au 32 bits ou 64bits (de toutes facons les procos 64bits fonctionnent aussi en 32bits et 16 bits ...).

Pour finir les « options pas franchement documentées dans xorg » que tu cites, ne sont pas des options de Xorg, mais du driver nvidia, et sont, amha, assez bien documentés dans le README du driver nvidia.

PS: Ca se voit que j'ai la flemme de faire un commentaire structuré ?

  • [^]Re: Mon 22"

    Posté par ahuillet (page perso, ) le 28/12/2007 à 20:41. (lien). Évalué à 1.

    Y a quelques ennuis pour la lecture de l'EDID avec certains écrans sur certaines machines. Le problème n'apparaît pas que sur les cartes nvidia, mais les forums tels que nvnews regorgent d'exemples.
    J'ai vécu ce problème aujourd'hui, où une de mes machines (slackware-current sur les deux, mais plus ou moins "-current" :p) a pu démarrer l'écran dans sa résolution native directement, alors que l'autre disait ne pas pouvoir lire l'EDID, et évidemment ne fonctionnait pas. (Il s'agit d'un écran au format "wide", résolution native 1440x900 je crois).

    [^]Re: Mon 22"

    Posté par Croconux () le 28/12/2007 à 23:36. (lien). Évalué à 1.

    Le VBE n'a rien de spécifique au 32 bits ou 64bits (de toutes facons les procos 64bits fonctionnent aussi en 32bits et 16 bits ...).

    Je faisais référence à ça http://www.delorie.com/djgpp/doc/ug/graphics/vbe20.html et ça https://bugs.launchpad.net/ubuntu/+source/vbetool/+bug/8177/(...) . VBE (Vesa Bios Extension) utilise un appel en mode réel au bios conçu à l'origne pour tourner sur des machines 16bis. En 32 bits, le processeur est obligé de passer en mode 16 bits pour effectuer un appel en mode réel. En 64 bits, il n'est apparemment pas possible de faire ce genre d'appel. Les logiciels comme vbetool et compagnie qui utilise les appels directs à VBE n'existent pas en version 64bits (cf http://packages.debian.org/fr/sid/read-edid)

    • [^]Re: Mon 22"

      Posté par Ph Husson (page perso, ) le 28/12/2007 à 23:52. (lien). Évalué à 1.

      On peut pas passer du 64bits au mode réél alors qu'on peut passer du 32 bits au mode réél ?
      Ils sont tordus chez intel et/ou amd /o\
      Enfin dans ce cas je retire ce que j'ai dit sur le vbe (enfin ca n'empeche que les infos DDC sont accessibles par les drivers de la carte graphique, mais bon ca explique que les outils génériques ne marchent pas)

    [^]Re: Mon 22"

    Posté par briaeros007 () le 29/12/2007 à 00:43. (lien). Évalué à 2.

    note
    Si tu utilise le mode VGA (ma cg ne gere pas le dvi, et puis comme ca la ps3 utilise le dvi de mon écran :P), il est possible que tu sois obligé de trouver une modeline pour que l'autodétection de la résolution de l'écran marche bien.
    (xvidtune powaaa)

    --
    Subete ga wakatta toki…watashi ga anta wo korosu.