Journal Xorg 7.3 chie sur ATI

Posté par  .
Étiquettes :
0
15
juin
2008
J'ai, sous Slackware et Debian, fait une mise à jour (Slack12.0->slack12.1; debian/etch->debian/lenny) qui implique la mise à jour vers Xorg 7.3 .
Et à chaque fois je me fais emmerder avec un DPI de merde qui fait que des horreurs sous GTK/KDE/IceWM (tout sauf e17) et une résolution par défaut de 640x350 (!) qui ne fait même pas partie des modes autorisés dans le xorg.conf de Debian .
Je sais très bien (maintenant) qu'il y a des solutions :
-Pour le DPI, il "suffit" de spécifier "DisplaySize", mais le problème c'est que ça dépend de la résolution de l'écran si on veut par exemple un DPI constant de 96 . Sous Debian lenny, on peut même pas régler le DPI avec Xfce .
-Pour la résolution, il suffit de se débrouiller dans l'interface graphique de KDE/Gnome/Xfce (facile avec 640x350 !) ou de modifier soi-même son .xinitrc afin de faire appel à Xrandr pour qu'il mette un mode correct .

Je voudrais aussi savoir si c'est parce que on m'a mis radeonhd d'office, ou parce que c'est Xorg qui foire de façon général (la première solution est préférable) .
Pour mon ATI Radeon 9550, Linux (à part les vieillissants Debian Etch et Slackware 12.0) n'est pas "desktop ready" en tout cas .
  • # librouproprieau ?

    Posté par  . Évalué à -1.

    tu as essayer XFdrake qui te mets des config aux petits oignons pour que cela fonctionne ?


    Ok, je sors -------->

    (j'aurais pu aussi demander pourquoi installer X11 sur slackware ou debian)



    Sinon, juste comme ça, tu utilises le driver libre (ati) ou proprio (fglrx) ?
    • [^] # Re: librouproprieau ?

      Posté par  . Évalué à 3.

      Le driver libre .
      • [^] # Re: librouproprieau ?

        Posté par  . Évalué à 0.

        je pense pas qu'il y ait incompatibilité entre driver libre et serveur X libre.
        Regarde ce qu iexpliqué en dessous à propos de la détéction des écrans.
  • # Carte intel et KDE4

    Posté par  . Évalué à 4.

    Moi j'ai chaque fois des problème de résolution avec ma carte intel 945 et KDE4, j'ai pas de problème avec KDE 3.5 ou Gnome (pas essayé d'autre) et je dois modifier mon fichier xorg.conf

    « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Carte intel et KDE4

      Posté par  . Évalué à 1.

      Avec kde4, j'ai des soucis avec nvidia qui ne me permettent pas de lancer ni l'Ig ni amarok, que ce soit avec ou sans compiz.

      Avec ma carte intel, pas de soucis pour kde 4.0.4
  • # Pourquoi faire un appel à xrandr ?

    Posté par  (site web personnel) . Évalué à 6.

    je vois pas bien l'intérêt de faire un appel à xrandr alors qu'il est aussi simple de configurer son écran dans xorg.conf. Par contre, il ne faut pas oublier que Randr1.2 change totalement la façon de configurer son écran (par exemple, on ne fournit plus vertrefresh et horizsync).

    un bon howto pour configurer tout ça :
    http://wiki.debian.org/XStrikeForce/HowToRandR12

    Et si tu as besoin d'une modeline, tu la génères avec cvt ou gtf
  • # Pour le DPI

    Posté par  . Évalué à 4.

    Tu peux forcer le DPI en ajoutant -dpi 96 aux arguments de lancement du serveur X, plus jamais besoin de t'en soucier ensuite. Après faut voir quel DM tu utilises (ou pas ?) pour voir si c'est facilement configurable ou pas chez toi.
    • [^] # Re: Pour le DPI

      Posté par  . Évalué à 2.

      J'ai essayé sous Slackware et c'est nul .
      "startx -- -dpi 96" me règle le DPI à 96 pour 640x350 et ça devient nul à chier quand je passe à 1400x1050 en mettant "xrandr -s 1400x1050" juste avant fluxbox dans le .xinitrc . Par contre ça marche bien si je lance xrandr à partir de Fluxbox .
      • [^] # Re: Pour le DPI

        Posté par  . Évalué à 3.

        Pure conjecture, n'ayant pas testé en pratique : peut-être qu'il reste au même dpi en passant de 640x350 à 1400x1050, alors que justement, si le "DisplaySize" reste le même, les dpi changent physiquement... d'où peut-être la recommandation d'utiliser "DisplaySize" plutôt que "-dpi"...

        En tout cas, changer les dpi à chaud via RandR n'est pas satisfaisant dans tous les cas... (re-)par exemple sous KDE 4, sous Fedora 9 : les décors des fenêtres, et plus généralement tout ce qui utilise plasma va chercher les dpi Xft dans un Xresources... donc, si on change via RandR en cours de session, ça ne changera pas les dpi Xft, et certaines choses seront donc moche (j'ai mis du temps à comprendre que ça venait de là :( )...
        • [^] # Re: Pour le DPI

          Posté par  . Évalué à 0.

          Non, justement il change de DPI et c'est pour ça qu'il me fout la même taille de polices que je sois en 640x350 ou en 1400x1050, ce qui fait que le 1400x1050 devient affreux (car la taille des images ne change pas) .
          On devrait déterminer justement la taille relative des polices en PIXELS et non pas en cm car c'est irréaliste d'avoir la même taille de police en 800x600 ou en 1600x1200 .
          • [^] # Re: Pour le DPI

            Posté par  . Évalué à 3.

            Garder la même taille de police à l'affichage, c'est vraiment quelque chose d'important pour moi : j'ai relativement pas mal d'afficheurs (chez moi, 6 écrans différents sont branchés à du X.org, tous avec des résolutions et des tailles physiques différentes, et du multi-écran, dont un triple quand le multi-board marchera de nouveau dans les X.org post-7.2)...

            Avoir des DPI cohérents (ie des DPI qui correspondent au DPI physique auquel on fait tourner l'écran, ie un DisplaySize qui reflète vraiment la taille physique de l'écran), ça m'assure que mes clickodromes afficheront tous la même taille de police, et auront la même lisibilité ; vu que je ne change jamais de résolution une fois un écran configuré, c'est à mes yeux davantage une meilleure feature qu'une mauvaise...



            Mais c'est vrai que ça peut être désagréable dans certains cas : je pense par exemple au branchement à un videoproj en mode clone (bien qu'en ce cas, je préfère faire avec deux écrans distincts, un pour afficher en plein-écran, un pour les contrôles... pas fan du mode clone, dans mes utilisations ; du tout) ;

            ... ou dans ton cas, quand on est forcé de passer par des résolutions assez fantasques, et que ça produit des tailles de polices désagréables...
  • # Mauvaise détection

    Posté par  . Évalué à 3.

    Je crois que dans les nouvelles versions de xorg, il peut sous-estimer les possibilités du moniteur. On peut le voir dans les logs. En tout cas quand j'ai mis à jour ma SID il y a quelques temps j'ai du rajouter ceci dans mon xorg.conf pour pas me retrouver en 640x480:

    Section "Monitor"
    .../...
    Option "PreferredMode" "1280x1024@60"
    EndSection
  • # Infos de l'écran

    Posté par  . Évalué à 10.

    N'aurais-tu pas un écran CRT ?

    Depuis quelques années, Xorg est devenu vachement intelligent : il se base sur les infos données par l'écran et les distributions se contentent donc de te faire un xorg.conf tout vide à l'installation et de le laisser faire.

    Avantage : Xorg produit ainsi automatiquement des modes écrans correspondant aux capacités de l'écran.

    Problème : beaucoup d'écrans CRT indiquent un mode par défaut complètement idiot, genre 1600x1200 sur un 17'', 1024x768 sur un 22'', voire 640x350 sur un 19''... Tu peux vérifier si c'est bien le problème avec read-edid (pour peu que tu ne sois pas en 64 bits), qui t'affichera les infos exactes rendues par l'écran.

    Solution : laisser tomber toutes les conneries intelligentes modernes et indiquer les modes dans xorg.conf, voire si ça ne suffit pas, repiquer les modelines dans le xorg.conf de l'ancienne distribution avec laquelle ça marchait bien.

    Moralité : ce n'est pas de la faute de Xorg ou d'ATI si certains fabriquants de moniteurs avaient pris le mode par défaut comme une grosse blague...

    « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

    • [^] # Re: Infos de l'écran

      Posté par  . Évalué à 3.

      read-edid > faudra que je teste ça sur mes LCD.

      2 LCD et pas un seul sur lequel l'affichage par défaut fonctionne et ce quelque soit la marque de la CG (intel, ati, nvidia). Un live cd et un xorg.conf généré automatiquement donnent un truc illisible (canal+ sans décodeur) depuis quelques version d'Xorg... avant c'était mieux xorg se lançait dans de basses définition mais lisibles.
    • [^] # Re: Infos de l'écran

      Posté par  . Évalué à 1.

      Xorg 7.2 me foutait un 1280x1024 avec 96 DPI sans que j'aie besoin de rien toucher .
      Mais maintenant Xorg 7.2 = debian etch si on veut un distribution dans sa dernière version .
      Pour get-edid | parse-edid :
      # EDID version 1 revision 1
      Section "Monitor"
      # Block type: 2:0 3:fd
      # Block type: 2:0 3:fc
      Identifier "AOC A770"
      VendorName "GSM"
      ModelName "AOC A770"
      # Block type: 2:0 3:fd
      HorizSync 31-70
      VertRefresh 48-130
      # Max dot clock not given
      # EDID version 3 GTF given: contact author
      # Block type: 2:0 3:fc
      # Block type: 2:0 3:fc
      # DPMS capabilities: Active off:yes Suspend:yes Standby:yes

      # Block type: 2:0 3:fd
      # Block type: 2:0 3:fc
      Mode "1280x544" # vfreq 111.078Hz, hfreq 63.981kHz
      DotClock 108.000000
      HTimings 1280 1312 1344 1688
      VTimings 544 546 546 576
      EndMode
      # Block type: 2:0 3:fc
      EndSection

      Un mode à la con sur EDID, je l'accorde, mais sûrement pas 640x350 .
      • [^] # Re: Infos de l'écran

        Posté par  . Évalué à 2.

        > Un mode à la con sur EDID, je l'accorde, mais sûrement pas 640x350

        640x350, c'est peut-être un mode DDC...

        Si tu vas farfouiller dans le /var/log/Xorg.0.log, tu devrais y trouver des modes DDC, des modes supplémentaires (ce qu'il y a dans l'EDID, a priori), et les modes que tu as pu déclarer à la mimine.
        • [^] # Re: Infos de l'écran

          Posté par  . Évalué à 1.

          (II) RADEON(0): EDID vendor "GSM", prod id 17138
          (II) RADEON(0): DDCModeFromDetailedTiming: Ignoring: We don't handle stereo.
          (II) RADEON(0): Output DVI-0 connected
          (II) RADEON(0): Output S-video disconnected
          (II) RADEON(0): Output DVI-0 using initial mode 640x350
          after xf86InitialConfiguration
          (**) RADEON(0): Display dimensions: (320, 240) mm
          (**) RADEON(0): DPI set to (133, 126)

          Le 640x350 n'est mentionné nulle part dans les modes DDC, ça commence à 640x480 .
          Les dimensions de l'écran sont correctement détectées, mais le DPI par défaut (avant d'avoir précisé DisplaySize) ne correspond manifestement pas au DisplaySize détecté puisque celui que j'ai précisé (370 278) est à peu de chose près le même et n'explique en aucun cas la différence.
          Et le (133,126) est ENTIEREMENT faux, ça ne correspond pas du tout au résultat du /etc/X11/xorg.conf vierge .

          Si maintenant X11 n'est même plus capable de calculer son DPI...
      • [^] # Re: Infos de l'écran

        Posté par  . Évalué à 4.

        VendorName "GSM"

        640x350 sur un gsm c'est pas si mal

        ~~~>[]
      • [^] # Si, 640x350, c'est possible !

        Posté par  . Évalué à 1.

        Un mode à la con sur EDID, je l'accorde, mais sûrement pas 640x350 .

        Extrait tout frais avec read-edid d'un Daewoo DT1926D (19'' cathodique) :
                # EDID version 1 revision 1
        Section "Monitor"
                # Block type: 2:0 3:0
                # Block type: 2:0 3:0
                # Block type: 2:0 3:0
                Identifier "LGI:0109"
                VendorName "LGI"
                ModelName "LGI:0109"
                # Block type: 2:0 3:0
                # Block type: 2:0 3:0
                # Block type: 2:0 3:0
                # DPMS capabilities: Active off:yes  Suspend:yes  Standby:yes

                Mode    "640x350"       # vfreq 70.072Hz, hfreq 31.462kHz
                        DotClock        25.170000
                        HTimings        640 656 752 800
                        VTimings        350 387 389 449
                        Flags   "-HSync" "+VSync"
                EndMode
                # Block type: 2:0 3:0
                # Block type: 2:0 3:0
                # Block type: 2:0 3:0
        EndSection

        (On notera accessoirement qu'il ne spécifie pas non plus ses plages de fréquences...)

        « Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone

  • # Recapitulationnons...

    Posté par  . Évalué à 4.

    Pour le DPI, il "suffit" de spécifier "DisplaySize"
    Non, ça ne suffit pas... et les trois quarts du temps, en fait, ça ne buggue pas, ça feature juste...

    Comme le dit Brice Goglin sur son blog [1] : "Non, DisplaySize et DPI ne sont pas (toujours) cassés"...

    En fait, le truc, c'est qu'il faut absolument définir un moniteur dans la section "Device" si on veut régler le "DisplaySize" d'autre chose que, a priori, de ce que j'ai compris, la sortie "VGA-0"...

    Soyons plus concrets : si je fais un "xrandr -q" sur ma machine, j'apprends que l'écran du laptop est sur "LVDS" : si je veux que le "DisplaySize" que je déclare dans la section "Monitor" idoine soit appliqué, il faut que je déclare dans la section "Device" quelque chose du genre : Option "Monitor-LVDS" "Identifiant moniteur"...

    Ca vaut d'ailleurs quoi qu'on mette dans ladite section "Monitor"... par défaut, si on ne met pas d'option du style "Monitor-BAR" "foo" dans la section "Device", c'est la sortie VGA-0 qui hérite des réglages de cette section, même si cette sortie n'est pas activée...

    ... je sais, c'est con : je me suis fait prendre aussi pendant quelques jours... en passant par les options crades, comme la modif du script d'init de X.org et autre Xresources (cependant, vu que je viens de m'installer une Fedora, avec KDE 4.05, et que les plasmoids ne respectent pas le DPI fixé par DisplaySize, il a quand même fallu que j'utilise en sus ce Xresources, pour que les polices des plasmoids soient lisibles... encore un truc con, mais qui est comme ça)...



    Pour la résolution, j'ai aussi eu le problème, sur un écran bizarre chez un pote, et sur ma TV LCD en DVI->HDMI...

    Dans mon cas, ce sont les données EDID de ces écrans qui étaient pourries... en faisant un "xrandr -q", normalement, tu as une étoile à côté du mode défini comme le préféré, et un "+" à côté de celui qui est en cours d'utilisation (ou inversement ; enfin, c'est l'idée)... j'avais bien le mode que je voulais comme préféré, mais un autre s'activait invariablement...

    En rajoutant une Option "IgnoreEDID" "true" dans la section "Device", tout est rentré dans l'ordre...



    Maintenant, c'est clair X.org 7.3 chie sur ATI... d'ailleurs, il chie tout court : c'est un très très très mauvaise release, et elle me saoule tellement que c'est pour la zapper que je me suis installé une Fedora 9... entre un KDE même pas à moitié fini et la pire release de X.org depuis des éons, j'ai bien dû choisir...

    Parmi les problèmes : j'ai vu trois personnes faire du multi-écran OpenGLisé avec des radeons à drivers libres sous X.org 7.3 (sans me compter)... on a tous des problèmes d'artefacts, de bugs et d'instabilité (enfin, légère : il ne m'a crashé X.org qu'une fois... soit moins que KDE4 depuis hier)...

    ... plus la disparition du support des multi-GPU (même s'ils ne marchaient qu'en non DRIsé, ça marchait très bien), qui me casse mon tri-écran (et ça, ça ne devrait pas revenir au moins avant X.org 7.5, avec les GPU objects)...

    L'erratum xserver 1.4.1 qui devait sortir presque immédiatement après le 1.4, en novembre dernier, et qui n'est finalement apparu officiellement qu'en début de cette semaine...

    Autant X.org 7.2 a ammené plein de performances, sans casser les fonctions, autant X.org 7.3 n'a pas ammené grand chose en la matière, mais casse moult sur son passage... c'en serait presque inquiétant pour X.org ;

    ... heureusement, le pre-7.4 que j'utilise depuis hier semble très bien fonctionner sur X800XL et 9600m (KDE 4, plutôt pas mal quant à lui, pour un truc qui relève de l'alpha stabilisée à grands efforts, même si ça frotte par endroits) : pas de bugs de textures, MythTV fonctionne nickel, tout bien... je garde, et j'évite soigneusement la 7.3, sans aucun doute la plus pourrie depuis que X.org est X.org... C'est d'ailleurs plutôt douteux de packager ce truc : j'ai du mal à comprendre comment il n'a pas été squeezé par les distros... :(



    [1] http://bgoglin.livejournal.com/15063.htmlhttp://bgoglin.live(...)
    • [^] # Re: Recapitulationnons...

      Posté par  . Évalué à 1.

      Mea culpa, pour l'URL, qui est en fait : http://bgoglin.livejournal.com/15063.html
    • [^] # Re: Recapitulationnons...

      Posté par  . Évalué à 1.

      Pour le DisplaySize il est bien dans la bonne section Monitor .
      Et sur "xrandr -q" j'ai pas de +, seulement un * sur le mode courant .
      • [^] # Re: Recapitulationnons...

        Posté par  . Évalué à 4.

        > Pour le DisplaySize il est bien dans la bonne section Monitor

        Ce n'est pas la question : ce que je disais, c'est que, dans la section "Device" (soit le GPU), il faut faire correspondre la sortie que tu utilises (LVDS, CRT-0, ou que sais-je ; cf "xrandr -q") à la ligne "Identifier" de ta section Monitor...

        Mettons que tu sortes sur la sortie RandR qui a le nom BAR (en pratique : LVDS, CRT-0, ...), et que ton moniteur s'appelle foo (par exemple : Hyundai, Philips, ... chut-chut : pas de marques), dans sa section, en ce cas, il faut que :
        - ta section "Device" inclue une ligne : Option "Monitor-BAR" "foo"
        - la section "Screen" idoine inclue une ligne : Identifier "foo"

        Ou alors, si tu ne mets rien dans la section "Device", il faut que "l'Identifier" soit le nom de la sortie, soit "BAR".

        Il doit aussi être possible de mettre un : Option "enabled" "false" dans la section du moniteur déclaré comme branché sur VGA-0, même s'il n'y en a pas physiquement, mais je n'ai pas essayé...

        En tout cas, ce problème apparent du DisplaySize vient de là : je m'en suis rendu compte en regardant les logs de X.org, où il m'avertissait que la section "Monitor" que j'avais déclaré n'étant reliée à aucune sortie RandR déclarée (faute d'en avoir mis une : je pensais qu'il le ferait tout seul s'il n'y avait qu'un écran branché ; et non : si on ne branche qu'un écran, pas besoin de section Monitor... et si on en met une, il faut l'attacher à une sortie RandR), par défaut, il l'attribuait à VGA-0, même si le seul écran branché l'était sur LVDS dans mon cas... c'est bête, mais c'est comme ça : c'est plus une feature foireuse qu'un bug.

        Cela dit, ça fera exactement la même chose qu'un "startx -- -dpi 96", au détail près que c'est maintenant la solution recommandée (et que ça peut ne pas tout solutionner, cf les plasmoids sur Fedora 9 qui demandent à régler le "Xft.dpi 96.00" ou à la valeur qui te sied, 133 dans mon cas, dans un Xresources).



        >Et sur "xrandr -q" j'ai pas de +, seulement un * sur le mode courant .

        En ce cas, c'est parce qu'il n'y a pas de "PreferredMode" défini dans la section "Screen" : tu as juste un mode activé, mais pas de préféré...

        Il faut donc que tu déclares un PreferredMode dans ta section "Monitor", comme expliqué dans l'excellente doc de la XStrikeForce qui t'est donné plus haut.

        Cela dit, si ça fait apparaître le "+" et le "*" sur deux lignes différentes, tu n'es pas encore sorti : il y a alors probablement le problème d'EDID que je t'ai décrit au-dessus (ce qui est probable, s'il n'arrive même pas à trouver un mode par défaut)... désactive alors EDID comme je te l'ai dit, et ça devrait rouler...



        Pour résumer :
        - pour changer le DPI via le DisplaySize sur une autre sortie que VGA-0, il faut déclarer explicitement qu'on ne le fait pas sur VGA-0
        - s'il n'y a pas de "+" à un "xrandr -q", il faut déclarer un "PreferredMode" dans la section "Monitor" (à moins qu'on aime cette résolution)
        - si "*" et "+" sont sur deux modes différents à un "xrandr -q", il est conseillé de désactiver la gestion des EDID, car ça signifie qu'un autre mode (*) que le préféré (+) est activé

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.