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 .
Journal Xorg 7.3 chie sur ATI
15
juin
2008
# librouproprieau ?
Posté par libre Cuauhtémoc . Évalué à -1.
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 FreeB5D . Évalué à 3.
[^] # Re: librouproprieau ?
Posté par libre Cuauhtémoc . Évalué à 0.
Regarde ce qu iexpliqué en dessous à propos de la détéction des écrans.
# Carte intel et KDE4
Posté par claudex . Évalué à 4.
« 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 libre Cuauhtémoc . Évalué à 1.
Avec ma carte intel, pas de soucis pour kde 4.0.4
# Pourquoi faire un appel à xrandr ?
Posté par Mjules (site web personnel) . Évalué à 6.
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 peikk0 . Évalué à 4.
[^] # Re: Pour le DPI
Posté par FreeB5D . Évalué à 2.
"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 Aefron . Évalué à 3.
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 FreeB5D . Évalué à 0.
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 Aefron . Évalué à 3.
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 Romuald Delavergne . Évalué à 3.
Section "Monitor"
.../...
Option "PreferredMode" "1280x1024@60"
EndSection
# Infos de l'écran
Posté par Arthur Accroc . Évalué à 10.
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 SF . Évalué à 3.
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 FreeB5D . Évalué à 1.
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 Aefron . Évalué à 2.
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 FreeB5D . Évalué à 1.
(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 jeffcom . Évalué à 4.
640x350 sur un gsm c'est pas si mal
~~~>[]
[^] # Si, 640x350, c'est possible !
Posté par Arthur Accroc . Évalué à 1.
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 Aefron . Évalué à 4.
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 Aefron . Évalué à 1.
[^] # Re: Recapitulationnons...
Posté par FreeB5D . Évalué à 1.
Et sur "xrandr -q" j'ai pas de +, seulement un * sur le mode courant .
[^] # Re: Recapitulationnons...
Posté par Aefron . Évalué à 4.
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.