En matière de benchmark, sinon, il y a le Phoronix Test Suite...
... bon, par contre, pas encore réussi à l'essayer : j'avais installé le .deb pour fetcher les benchmmarks, et avais voulu prendre ceux liés au clickodrome ; mais il me mourrait dans les doigts en remplissant mon /tmp (pourtant de 2Gio) de trucs trop gros (raison précise pour laquelle j'ai un /tmp séparé, au demeurant... mon / est d'ailleurs bien plus petit que ça), alors qu'au final, il les dépose dans le ~/... faudrait que j'essaye de nouveau, tiens - au pire, en ayant le courage de redimensionner le LVM...
Déjà, ça râle surtout parce qu'il n'y a pas de specs (enfin, tous les constructeurs ne veulent toujours pas en donner)...
... je ne suis pas sûr que la libération de fglrx, avec tous les hacks ignobles qui sont sortis d'un strace, genre du "c:\program files" en dur, soit ce qui est le plus demandé par la communauté libre, pas plus qu'un meilleur fglrx ; si ça venait, ma foi, pourquoi pas, mais ce n'est pas ce qui nous est essentiel pour avoir un driver libre pérenne.
Maintenant, s'ils fournissent des drivers qui sont loin de pouvoir marcher, on a quand même le droit de le remarquer, non ?
Si un nouvel utilisateur vient me voir en me disant que le driver sur son CD ne marche pas, et qu'il va falloir que je tienne la tronçonneuse pour lui, j'ai quand même bien le droit de lui expliquer pourquoi il vaut mieux éviter d'utiliser des trucs hors gestionnaire de paquet, quand on ne sait pas ce qu'on fait, a fortiori pour des blobs.
Quand je vois le nombre de redmondiens (bon, eux, je m'en fous : ça fait un moment que je refuse d'intervenir, au motif que je n'utilise plus ces choses depuis si longtemps que je ne les connais plus assez bien) qui n'installent que ce qu'ils trouvent sur le CD, y compris les kits de connection à une box FAI en ethernet (misère !), ou qui n'utilisent que le driver machin du CD, dépassé depuis 3 ans parce que la boîte du matos traînait dans une remise du vendeur, sur un système avec tous les service packs, et sur lequel ça ne passe évidemment plus... et qui sont estomaqués quand on leur dit que le driver téléchargé sur le site du constructeur a infiniment plus de chances de marcher que celui du CD...
... eh bien, quand je vois ça, je me dis que les remarques, conseils et mises en garde sur l'administration, on n'en donne jamais trop.
>Non, parce que vous ne l'utilisez pas
Ca, je n'en sais rien... si un autre utilisateur s'en sert, pour voir, par exemple, alors qu'en tant qu'administrateur, j'aurais pourtant voulu que non.
>Ce qu'il vous faudrait peut être c'est Gentoo.
J'aime beaucoup Gentoo, j'y ai passé beaucoup de temps, et il m'arrive encore de m'en servir (enfin, surtout le fabuleux livecd minimal, qui m'a plus d'une fois sorti de la panade), mais elle ne me convient tout simplement plus (recul sur le bleeding-edge, plus envie de compiler des heures, et je trouve que le projet est bien moins robuste qu'il y a 4 ans, quand j'avais commencé à l'utiliser - pour résumer).
Non, là, je veux une orgie de bleeding-edge, tout en restant fidèle à mes principes et mes affinités (donc, pas de suse ni d'ubuntu), mais sans trop me casser la tête non plus... bon, forcément, il va y avoir des compromis à faire ; mais la demi-absence de gestion des dépendances, ce n'en est pas un petit, pour moi : c'est tout.
1) Ce n'est pas tant que ce ne soit pas dispo dans yum, à la limite, qui me dérange : c'est que ce ne soit pas dispo du tout... même dans les yum-utils, il n'y a que package-clean, qui n'est capable comme je l'ai dit que de virer les libs qui ne dépendent de rien ; c'est très maigre...
Après, deborphan ne fait rien de mieux que packageclean non plus... La question est plutôt l'option autoremove d'apt, ou le comportement par défaut d'aptitude, qui sont quand même fonctionnels depuis un moment. Quand on est habitué, ça fait drôle de ne plus avoir.
2) Je fais surtout partie des personnes qui aiment bien savoir ce qu'il y a sur la machine et qui détestent les répertoires bourrés d'inutilités, parce que c'est plus dur de s'y retrouver... je ne vois pas ce que l'optimisation a à voir là-dedans : c'est une question d'administrabilité.
3) Mettons que j'ai un problème de sécurité, non encore connu, et donc encore moins patché, dans un programme installé en tant que dépendance, de quelque chose que j'ai viré depuis. Si le gestionnaire de paquets gère complètement les dépendances à la désinstallation, je ne suis pas sujet à cette faille ; dans le cas de yum, j'y suis.
Laisser le bloat s'installer, si, ça peut être grave. Ou alors, avoir tout et n'importe quoi sur les machines, ce n'est pas grave ? Ce n'est pas en niant qu'on résoud les problèmes.
4) Qu'est-ce qui est à utiliser avec précaution ? Enlever les dépendances installées quand elles ne sont plus utiles ? Ca fait au moins depuis Etch que c'est le comportement par défaut, sous Debian, et je n'ai eu aucun problème avec.
Maintenant, si c'est une possibilité, par contre, comment on fait ? Jusqu'ici, pour moi, ce n'est même pas une possibilité... Un revdep-rebuild à l'envers (pour les dépendances, elles, à l'endroit), à la Gentoo, ie pas dans le gestionnaire de paquets en lui-même, ça m'irait pourtant parfaitement... mais non, même pas.
D'un autre côté, si le driver est trop récent, qu'est-ce qui te dit qu'il marchera sur ta distro ? Kernel, X.org et changement d'API : gros risque de paf le chien...
Bon, après, je dis ça, peut-être qu'ils mettent plusieurs versions, adaptées à diverses distros... je n'en sais rien.
J'ai bien crû comprendre... mais ne connaissant pas et ne m'attendant pas du tout à ça, surtout sur une distro plus ou moins vouée à tester plein de choses...
... c'est dommage, parce que la distro me plaisait conceptuellement plutôt bien : bleeding edge extrême et activement pro-libre, c'est ce que je recherchais...
Mais là, franchement, je considère mon système comme déjà irrémédiablement bloaté, après avoir installé 4 ou 5 trucs... paie ta maintenance à l'ancienne. Je me vois vraiment mal mettre un truc qui utilise ce "gestionnaire" de paquets sur un serveur : déjà que ça risque de me saouler vite sur de la workstation... ma période Slackwaro-LFSiste, je ne la regrette pas, mais elle est derrière moi depuis long.
Ce genre de trucs, ça me donne une très grosse envie de resortir assez vite les backups Debian sur les machines où j'ai testé - même si ça m'embête, parce que je n'y aime pas X.org (7.1 est trop lent, 7.3 pas assez stable, pour ce qui m'ennuie le plus). Non, franchement, après avoir testé yum, une chose est claire : il existe des différences dantesques entre les distros, au niveau du gestionnaire de paquets... On peut cacher ça derrière PackageKit (j'ai même tendance à penser que c'est souhaitable, pour unifier les syntaxes et ne pas confuser les nouveaux arrivants), ça ne change rien aux possibilités respectives.
Bon, ça me fera toujours un truc à dire, la prochaine fois qu'IsNotGood tonitruera que soit-disant, yum n'a pas de très graves problèmes au niveau de la gestion des dépendances.
> une croyance généralisée qu'un gestionnaire de dépendances et de téléchargement est ce qui différencie les distros entre elles... mais en fait non, tout ça est résolu, avec plus ou moins de bonheur et de perfs, dans toutes les distros majeures, depuis longtemps, et quasiment de la même façon, aux détails techniques prêts
Faut le dire vite...
Ca fait 5-6 jours que je teste Fedora... et donc yum, que je ne connaissais pas du tout...
... et bien, je cherche encore la manière de désinstaller automatiquement les dépendances pullées par un paquet installé...
Genre :
- yum install revisor : m'installe plein de trucs
- yum remove revisor : ne me vire que l'espèce de méta-paquet (mea culpa si la terminologie est inexacte) revisor... et rien de ce qui le compose vraiment, ie ses moult dépendances
- par contre, les dépendances inversées marchent bien (il y a eu un journal assez trollesque là-dessus récemment) : si je vire revisor-cli, il me vire revisor-gui, revisor-comps et revisor... m'enfin : c'est quand j'ai installé revisor, que ça a fait venir tout ça, pas revisor-cli...
J'ai demandé aux Fedoriens que je connais, je suis allé sur le forum de Fedora, j'ai googlé : tout ce que j'ai vu, c'est une remarque comme quoi c'est bel et bien une feature [1], et des bidouilles totalement inutiles avec package-clean, et hors-propos, dès lors que ce qu'on veut virer n'est pas une lib (or, les dépendances ne sont pas toujours des libs)... Mouais : bah feature ou pas, à la désinstallation, yum ne gère pas les dépendances, seulement les dépendances inversées...
Je ne connaissais donc pas du tout jusqu'ici, mais je vois mal comment on peut comparer ça avec apt/aptitude (hors troll rpm/deb dont je me fous pour l'instant, n'ayant pas encore essayé de crafter du rpm... mais sachant déjà que ce n'est pas spécialement la joie avec les debs, en comparaison de ce que j'ai également pu voir sous Gentoo)... ou alors, je me suis tout confusé, et l'explication est vraiment bien cachée... l'instabilité de KDE, je peux encore faire avec, et c'était justement une des motivations de tester la distro (juillet et KDE 4.1 approchant fort, et KDE 4.0.5 étant sorti au début du mois, et ayant été updaté) : mais un gestionnaire de paquets qui ne gère les dépendances qu'à moitié, ie à l'installation, là, j'ai plus de mal...
Pour le support de Xv sous Compiz, certes : il faut user de X11 ; comme avec les drivers libres Intel que j'ai vus (en utilisant le compositage intégré à son gestionnaire de fenêtres, cela dit, comme sous KDE4, même si ce dernier n'est pas très stable, Xv marche très bien, hein - entre compiz et le driver radeon, j'ai mon petit avis quant auquel est le plus stable et abouti, et sur lequel survivra à l'autre)... pour la lenteur, oui, si tu mets des effets de flammes, de fenêtres gélatineuses, etc, à la limite : mais j'ai une 9600m sur mon laptop en 1920x1200, et en se contentant d'effets raisonnables, ça marche plutôt bien.
> les jeux ont des perfs assez médiocres
Je veux bien le croire [1], n'ayant pas testé... Bon, par contre, l'article de Phoronix date de X.org 7.2, et le peu que j'ai pu tester de X.org 7.4 me fait dire qu'il serait temps de retester (ie du MythTV OpenGLisé... OK, pas forcément outrancier, en demande de perfs, mais c'était lent comme la mort avec X.org 7.1, beaucoup mieux avec 7.2, buggé comme jamais avec 7.3, et nickel au possible avec le 7.4 - je suis très enthousiaste à propos des progrès de X.org, mais ça ne m'empêche pas d'être très réaliste à ce sujet non plus)...
... même si je dois avouer que pouvoir jouer sous Linux ne me préoccupe personnellement pas tant que ça.
> le rendu 3D a parfois des bugs d'affichage
J'en ai vu dans deux cas :
- quand je forçais DRI en utilisant deux cartes (non, ça n'est pas supporté... oui, ça marchouillait, le problème essentiel étant l'initialisation des cartes qui foirait une fois sur trois, en entrée ou en sortie de X.org... quelques artefacts aussi, dans cette situation hautement insupportée [un des devs freedesktop du pilote tombait des nues quand je lui ai dit que j'étais arrivé à faire marchouiller ça, en jouant du module Int0, alors qu'il ne croyait pas que c'était ne serait-ce que vaguement possible])
- avec cette incurie qu'est X.org 7.3... alors, certes, la plupart des distros l'utilisent maintenant... ça n'en fait pas moins à mes yeux une release digne d'une alpha, cassant des tonnes de choses (y compris le multi-écran... même si ça apport une bien meilleure syntaxe et un bien meilleur backend : non, ce n'est pas stable à compter de la 7.3), et fonctionnant globalement mal (même si c'est à partir de lui que le driver radeon supporte un virtual allant jusqu'à 3968x3968, permettant de faire du gros multi-écran DRIsé... ou un EXA décent, pour donner un autre exemple)... le seul problème de textures corrompues que j'ai pu avoir avec 7.3, ie les textures de MythTV qui se corrompent d'un seul coup (seulement gênant dans l'interface des menus) sont résolus avec le 7.4.
> Les versions récentes du driver libre font freezer le système
Des radeons, j'en utilise 3, sous X.org : deux X800 et une 9600m... toutes avec le dernier driver, soit le 6.8... aucun freeze : sources ?
> ATI sous linux, c'est un peu la roulette russe des cartes 3D, il suffit d'aller voir sur les forums pour se faire une idée
Mouais... l'aide aux utilisateurs libres de radeon, sur les forums, je n'en suis pas en reste...
Ce que je vois, c'est surtout du FUD, et des problèmes essentiellement dûs à l'absence de la libmesa-gl, fournissant le backent OpenGL libre... je n'ai toujours pas compris si c'était parce que les utilisateurs avaient utilisé le blob fglrx avant, et qu'il l'avait écrasée (j'ai déjà vu du bordel de symlinks imbitable, avec ces libs, sur des machines ou des cochonneries comme envy et autres script-tronçonneuses avaient sévi) ou si leur distro n'inclue pas le backend OpenGL libre par défaut (ubuntu, sur laquelle le problème était systématique, il y a quelques temps), mais c'est le problème le plus grave (et de loin, le plus courant) que j'aie jamais vu à ce niveau...
...mais comme par hasard, à chaque fois que quelqu'un me demande comment faire fonctionner sa radeon<=R400, de manière libre, pour avoir plein d'effets kikoolol, ça finit par très bien marcher, avec des utilisateurs très satisfaits : bizarre, non ?
Comme quoi, le FUD, sur les forums, dans les commentaires, partout... ; Fait : les radeons qui fonctionnent avec des drivers libres sont depuis très longtemps (je suis linuxien intensif depuis 4 ans... et je me suis orienté vers les radeons sur les conseils de quelqu'un qui n'utilisait que ça et qui avait commencé un an avant moi) les cartes les mieux librement supportées sous Linux... les seules proprement supportées, en cartes non intégrées, en outre (pour inclure les chips Intel parmis les GPU les mieux supportées) - dire le contraire, vu que c'est quelque chose que j'ai quand même un peu moult expérimenté, pour moi, c'est du FUD ; Oui : fglrx est une bouse inepte - Non : le driver libre n'en est pas une - prière de ne pas réduire les cartes Radeon au driver que ses concepteurs nous fournissent.
... alors après, on peut mettre ça en parallèle avec ce qui se fait sous les autres OS, ou avec des cartes à blobs - mais personnellement, je m'en fous : mes GPU fonctionnent depuis des années avec des drivers libres (j'ai essayé les nvidia blobées : j'en suis revenu très très vite - entre legacy qui perd plein d'options, sortie TV de qualité pire qu'en passant par un scaler à 30€, la recompilation du HAL binaire au changement de kernel, ... c'est bon : j'ai moins de problèmes avec les radeons reverse-engineerées), et vu que ça marche très bien pour les besoins que j'en ai, et que c'est libre, ça me va donc très bien.
PS : désolé pour ce long message, mais le FUD sur les radeons, juste parce que le ATI-bashing a longtemps été de mise, rapport à l'un des pires blobs qui ait probablement pu être (il paraît qu'il s'est amélioré : mais je m'en fous tout aussi bien), et bien que ce bashing ne soit pas applicable aux Radeon<=R400 à drivers libre depuis longtemps également, ça fait donc quelques années que ça me sort par les trous de nez.
Si j'en crois mon yum, actuellement, ie sous Fedora 9, IcedTea, ce serait plus du <=> java 1.6...
Après, il me semble qu'il y a pas mal de backports de ce que devrait être le java 1.7 officiellement tout libre.
Et en effet, passe pas avec les impôts...
Perso, je suis passé à Fedora ce weekend, en quête de moult bleeding edge, et pour fuir le X.org 7.3 arrivé sur Lenny il n'y a pas si longtemps... et je ne regrette pour l'instant pas - à part qu'il faudra m'expliquer comment gérer la désinstallation automatique des dépendances, quand on désinstalle le paquet qui les a ramenées, avec yum... sous peine que j'en vienne à croire que yum et les dépendances (pas inverses, ça, oui, ça marche, comme l'a montré le journal über-trollesque d'il y a quelques temps), c'est à moitié (à la désinstallation) de l'escroquerie :(
Si tu n'as pas besoin de perfs démentes, en PCI-e, tu devrais pouvoir trouver, d'occas, par contre, maintenant, de la X800XL et autres R4xx , tout à fait correctement supportées (dual screen, sortie TV, DRI jusqu'à un virtual de 3968x3968, compiz, ...), en PCI-e, et pour pas cher du tout [1] ...
C'est ce que j'utilise (des PowerColor, parce qu'elles ne sont pas chères, fournies avec un câble YUV, qu'on peut mettre le dissipateur qu'on veut dessus, et qu'elles ont un connecteur d'alim molex, ce qui n'est pas le cas de toutes) dans mon salon, avec un MythTV sous render OpenGL, sur un 42" full-hd, en dual-screen avec un LCD 17" en 1280x1024, mais aussi sur une autre machine avec un 22" et un 19" cathodique en dual screen (et avant X.org 7.3, je me servais d'une deuxième carte identique pour sortir sur une TV cathodique en plus, sans DRI par contre, puisque pas possible en multi-board)...
Ca fait presque deux ans que je les utilise (avant, j'utilisais des R300, avec des drivers libres... et avant, des R200, toujours avec des drivers libres... j'ai bien du mal à me souvenir de la dernière fois qu'un fglrx est venu pourrir mes machines : même mon laptop est à base de Radeon libre), et je n'ai pas à m'en plaindre (à part quelques bugs de corruption, si je fais du multi-écran avec X.org 7.3 : ça n'arrive cela dit pas avec le 7.2 ni le pre-7.4, pas plus que si je me contente du mono-écran).
En plus, ça ne chauffe pas trop, et avec une bonne ventilation de boîtier, ça se contente allègrement d'un refroidisseur passif à caléoducs...
... préfère quand même les cartes qui ont une prise d'alimentation (6 pins, je crois, pour les GPU ; au pire, il y a des adaptateurs), plutôt que celles qui ne peuvent tirer leur jus que du port PCI-e : de ce que j'ai vu, ça m'a semblé beaucoup plus robuste (sur 6 cartes du genre que j'ai vu, dont 4 à moi, les deux que j'ai vu lâcher n'étaient alimentées que par le PCI-e, les autres, par un connecteur molex : je sais, c'est maigre pour faire des stats... j'ai au moins la décence de le reconnaître : je prends davantage celles qui ont un port d'alimentation par darwinisme préventif et empirique qu'autre chose) ;
Bon, par contre, je ne suis pas gamer sur PC (je me fais déjà engueuler par des potes parce que je n'installe même pas Frozen Bubble par défaut...), donc, je ne saurais dire ce qu'il est pratiquement possible de faire à ce sujet ; cela dit, il me semble qu'un article Phoronix montrait que les performances des ces cartes avec les drivers libres n'étaient pas si loin de celles avec le blob infâme.
Après, course au renouvellement oblige, comme je l'ai dit, ça ne se trouve plus que d'occas... faudrait d'ailleurs que je m'en achète une ou deux autres, au cas où : je l'aurais mauvaise si j'en avais une qui claquait, le driver n'étant pas spécialement prêt pour les R500 et supérieures, et Intel ne faisant toujours, hélas, pas de GPU sur PCI-e...
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...
> 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.
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à :( )...
> 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é
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... :(
Cf mon post au-dessus : ça existe, soit par palliers en jouant au morse avec l'interrupteur (un peu moyen-âgeux, je trouve), soit en continu (mais je n'ai pas encore vu les modèles dispos en hexagone)...
Pour les lampes fluocompactes à variation linéaire, j'ai retrouvé [1] ... par contre, je devais mal me souvenir à propos du temps d'allumage, la fiche de présentation mentionnant qu'il faut qu'elles chauffent pendant une minute quand même...
> surtout, ne jamais la brancher sur un variateur de lumière
... c'est aussi valable pour les lampes à LED... D'après ce que j'ai compris, celles-ci fonctionnent en courant continu, à basse tension (bah oui, ce sont des LED), d'où la nécessité d'avoir un transfo dans l'ampoule, qui ne supporterait pas la variation de tension en entrée...
J'ai d'ailleurs lu que, malgré le fait que les LED en elle-mêmes ne consommaient presque rien, certaines ampoules à LED, dans leur globalité, consommaient finalement pas mal d'énergie (de l'ordre de quelques dizaines de watts, si je m'en souviens), si elles embarquaient un transfo de mauvaise qualité, de telle sorte que certaines consommaient plus que des fluo... bon, après, je n'en ai jamais acheté, ni démonté, donc, je n'en sais rien en pratique (j'ai dit, "j'ai [...] lu")...
Par contre, pour la variation ce n'est pas si vrai que ça, pour les fluo... en fait, il existe deux types de fluo à variateurs :
- par palliers : apparemment, on fait si on "fait du morse" avec l'interrupteur, ça change l'intensité lumineuse, avec 3 ou 4 intensités possibles ;
- par variation continue : je n'ai vu ces ampoules à la vente qu'outre-Manche (enfin, je n'ai pas regardé non plus outre-Atlantique), mais elles semblent faites pour encaisser la variation continue de lumière, avec un variateur classique, avoir un délai de chauffe très court, et être plus résistantes... par contre, assez chères, de l'ordre de 15-20€, d'après mes souvenirs...
Désolé de ne pas donner de liens sur le test de conso des ampoules LED et sur les fluo à variation : je ne suis pas sur le PC avec ces bookmarks-là :(
Fourniret, j'y crois pas : paraît qu'il ne travaille qu'aux livecd... c'est plus facile et plus économique avec eux d'utiliser un support qui a toujours été vierge avant...
... par contre, Dutroux, j'imagine qu'il sera intéressé par un FS peu mature, et particulièrement efficace sur les fichiers de petite taille...
[^] # Re: Wouhou
Posté par Aefron . En réponse au journal Nouvelle version du pilote libre pour les ATI Radeon. Évalué à 2.
... bon, par contre, pas encore réussi à l'essayer : j'avais installé le .deb pour fetcher les benchmmarks, et avais voulu prendre ceux liés au clickodrome ; mais il me mourrait dans les doigts en remplissant mon /tmp (pourtant de 2Gio) de trucs trop gros (raison précise pour laquelle j'ai un /tmp séparé, au demeurant... mon / est d'ailleurs bien plus petit que ça), alors qu'au final, il les dépose dans le ~/... faudrait que j'essaye de nouveau, tiens - au pire, en ayant le courage de redimensionner le LVM...
[^] # Re: BAM ! Dans ta gueule Mark :-D
Posté par Aefron . En réponse au journal Réponse à Mark Shuttleworth. Évalué à 9.
[^] # Re: Intéréchiant
Posté par Aefron . En réponse à la dépêche openSUSE 11.0 : nouvelle mouture du caméléon disponible. Évalué à 4.
Bah installe un bon vieux ouin-ouin qui tourne en root, alors.
[^] # Re: Bonne nouvelle.
Posté par Aefron . En réponse au journal AMD et ATI réaffirment leur soutien à Linux. Évalué à 2.
[^] # Re: Intéréchiant
Posté par Aefron . En réponse à la dépêche openSUSE 11.0 : nouvelle mouture du caméléon disponible. Évalué à 2.
[^] # Re: Bonne nouvelle.
Posté par Aefron . En réponse au journal AMD et ATI réaffirment leur soutien à Linux. Évalué à 5.
... je ne suis pas sûr que la libération de fglrx, avec tous les hacks ignobles qui sont sortis d'un strace, genre du "c:\program files" en dur, soit ce qui est le plus demandé par la communauté libre, pas plus qu'un meilleur fglrx ; si ça venait, ma foi, pourquoi pas, mais ce n'est pas ce qui nous est essentiel pour avoir un driver libre pérenne.
Maintenant, s'ils fournissent des drivers qui sont loin de pouvoir marcher, on a quand même le droit de le remarquer, non ?
Si un nouvel utilisateur vient me voir en me disant que le driver sur son CD ne marche pas, et qu'il va falloir que je tienne la tronçonneuse pour lui, j'ai quand même bien le droit de lui expliquer pourquoi il vaut mieux éviter d'utiliser des trucs hors gestionnaire de paquet, quand on ne sait pas ce qu'on fait, a fortiori pour des blobs.
Quand je vois le nombre de redmondiens (bon, eux, je m'en fous : ça fait un moment que je refuse d'intervenir, au motif que je n'utilise plus ces choses depuis si longtemps que je ne les connais plus assez bien) qui n'installent que ce qu'ils trouvent sur le CD, y compris les kits de connection à une box FAI en ethernet (misère !), ou qui n'utilisent que le driver machin du CD, dépassé depuis 3 ans parce que la boîte du matos traînait dans une remise du vendeur, sur un système avec tous les service packs, et sur lequel ça ne passe évidemment plus... et qui sont estomaqués quand on leur dit que le driver téléchargé sur le site du constructeur a infiniment plus de chances de marcher que celui du CD...
... eh bien, quand je vois ça, je me dis que les remarques, conseils et mises en garde sur l'administration, on n'en donne jamais trop.
[^] # Re: Intéréchiant
Posté par Aefron . En réponse à la dépêche openSUSE 11.0 : nouvelle mouture du caméléon disponible. Évalué à 2.
Ca, je n'en sais rien... si un autre utilisateur s'en sert, pour voir, par exemple, alors qu'en tant qu'administrateur, j'aurais pourtant voulu que non.
>Ce qu'il vous faudrait peut être c'est Gentoo.
J'aime beaucoup Gentoo, j'y ai passé beaucoup de temps, et il m'arrive encore de m'en servir (enfin, surtout le fabuleux livecd minimal, qui m'a plus d'une fois sorti de la panade), mais elle ne me convient tout simplement plus (recul sur le bleeding-edge, plus envie de compiler des heures, et je trouve que le projet est bien moins robuste qu'il y a 4 ans, quand j'avais commencé à l'utiliser - pour résumer).
Non, là, je veux une orgie de bleeding-edge, tout en restant fidèle à mes principes et mes affinités (donc, pas de suse ni d'ubuntu), mais sans trop me casser la tête non plus... bon, forcément, il va y avoir des compromis à faire ; mais la demi-absence de gestion des dépendances, ce n'en est pas un petit, pour moi : c'est tout.
[^] # Re: Intéréchiant
Posté par Aefron . En réponse à la dépêche openSUSE 11.0 : nouvelle mouture du caméléon disponible. Évalué à 5.
Après, deborphan ne fait rien de mieux que packageclean non plus... La question est plutôt l'option autoremove d'apt, ou le comportement par défaut d'aptitude, qui sont quand même fonctionnels depuis un moment. Quand on est habitué, ça fait drôle de ne plus avoir.
2) Je fais surtout partie des personnes qui aiment bien savoir ce qu'il y a sur la machine et qui détestent les répertoires bourrés d'inutilités, parce que c'est plus dur de s'y retrouver... je ne vois pas ce que l'optimisation a à voir là-dedans : c'est une question d'administrabilité.
3) Mettons que j'ai un problème de sécurité, non encore connu, et donc encore moins patché, dans un programme installé en tant que dépendance, de quelque chose que j'ai viré depuis. Si le gestionnaire de paquets gère complètement les dépendances à la désinstallation, je ne suis pas sujet à cette faille ; dans le cas de yum, j'y suis.
Laisser le bloat s'installer, si, ça peut être grave. Ou alors, avoir tout et n'importe quoi sur les machines, ce n'est pas grave ? Ce n'est pas en niant qu'on résoud les problèmes.
4) Qu'est-ce qui est à utiliser avec précaution ? Enlever les dépendances installées quand elles ne sont plus utiles ? Ca fait au moins depuis Etch que c'est le comportement par défaut, sous Debian, et je n'ai eu aucun problème avec.
Maintenant, si c'est une possibilité, par contre, comment on fait ? Jusqu'ici, pour moi, ce n'est même pas une possibilité... Un revdep-rebuild à l'envers (pour les dépendances, elles, à l'endroit), à la Gentoo, ie pas dans le gestionnaire de paquets en lui-même, ça m'irait pourtant parfaitement... mais non, même pas.
[^] # Re: Bonne nouvelle.
Posté par Aefron . En réponse au journal AMD et ATI réaffirment leur soutien à Linux. Évalué à 0.
Bon, après, je dis ça, peut-être qu'ils mettent plusieurs versions, adaptées à diverses distros... je n'en sais rien.
[^] # Re: Intéréchiant
Posté par Aefron . En réponse à la dépêche openSUSE 11.0 : nouvelle mouture du caméléon disponible. Évalué à 5.
... c'est dommage, parce que la distro me plaisait conceptuellement plutôt bien : bleeding edge extrême et activement pro-libre, c'est ce que je recherchais...
Mais là, franchement, je considère mon système comme déjà irrémédiablement bloaté, après avoir installé 4 ou 5 trucs... paie ta maintenance à l'ancienne. Je me vois vraiment mal mettre un truc qui utilise ce "gestionnaire" de paquets sur un serveur : déjà que ça risque de me saouler vite sur de la workstation... ma période Slackwaro-LFSiste, je ne la regrette pas, mais elle est derrière moi depuis long.
Ce genre de trucs, ça me donne une très grosse envie de resortir assez vite les backups Debian sur les machines où j'ai testé - même si ça m'embête, parce que je n'y aime pas X.org (7.1 est trop lent, 7.3 pas assez stable, pour ce qui m'ennuie le plus). Non, franchement, après avoir testé yum, une chose est claire : il existe des différences dantesques entre les distros, au niveau du gestionnaire de paquets... On peut cacher ça derrière PackageKit (j'ai même tendance à penser que c'est souhaitable, pour unifier les syntaxes et ne pas confuser les nouveaux arrivants), ça ne change rien aux possibilités respectives.
Bon, ça me fera toujours un truc à dire, la prochaine fois qu'IsNotGood tonitruera que soit-disant, yum n'a pas de très graves problèmes au niveau de la gestion des dépendances.
[^] # Re: Intéréchiant
Posté par Aefron . En réponse à la dépêche openSUSE 11.0 : nouvelle mouture du caméléon disponible. Évalué à 9.
Faut le dire vite...
Ca fait 5-6 jours que je teste Fedora... et donc yum, que je ne connaissais pas du tout...
... et bien, je cherche encore la manière de désinstaller automatiquement les dépendances pullées par un paquet installé...
Genre :
- yum install revisor : m'installe plein de trucs
- yum remove revisor : ne me vire que l'espèce de méta-paquet (mea culpa si la terminologie est inexacte) revisor... et rien de ce qui le compose vraiment, ie ses moult dépendances
- par contre, les dépendances inversées marchent bien (il y a eu un journal assez trollesque là-dessus récemment) : si je vire revisor-cli, il me vire revisor-gui, revisor-comps et revisor... m'enfin : c'est quand j'ai installé revisor, que ça a fait venir tout ça, pas revisor-cli...
J'ai demandé aux Fedoriens que je connais, je suis allé sur le forum de Fedora, j'ai googlé : tout ce que j'ai vu, c'est une remarque comme quoi c'est bel et bien une feature [1], et des bidouilles totalement inutiles avec package-clean, et hors-propos, dès lors que ce qu'on veut virer n'est pas une lib (or, les dépendances ne sont pas toujours des libs)... Mouais : bah feature ou pas, à la désinstallation, yum ne gère pas les dépendances, seulement les dépendances inversées...
Je ne connaissais donc pas du tout jusqu'ici, mais je vois mal comment on peut comparer ça avec apt/aptitude (hors troll rpm/deb dont je me fous pour l'instant, n'ayant pas encore essayé de crafter du rpm... mais sachant déjà que ce n'est pas spécialement la joie avec les debs, en comparaison de ce que j'ai également pu voir sous Gentoo)... ou alors, je me suis tout confusé, et l'explication est vraiment bien cachée... l'instabilité de KDE, je peux encore faire avec, et c'était justement une des motivations de tester la distro (juillet et KDE 4.1 approchant fort, et KDE 4.0.5 étant sorti au début du mois, et ayant été updaté) : mais un gestionnaire de paquets qui ne gère les dépendances qu'à moitié, ie à l'installation, là, j'ai plus de mal...
[1] http://fedoraproject.org/wiki/FWN/Issue100#Yum_Reverse_Depen(...)
[^] # Re: NVidia
Posté par Aefron . En réponse au journal De retour sous Mandriva après 6 ans : compte rendu détaillé.. Évalué à 2.
Pour le support de Xv sous Compiz, certes : il faut user de X11 ; comme avec les drivers libres Intel que j'ai vus (en utilisant le compositage intégré à son gestionnaire de fenêtres, cela dit, comme sous KDE4, même si ce dernier n'est pas très stable, Xv marche très bien, hein - entre compiz et le driver radeon, j'ai mon petit avis quant auquel est le plus stable et abouti, et sur lequel survivra à l'autre)... pour la lenteur, oui, si tu mets des effets de flammes, de fenêtres gélatineuses, etc, à la limite : mais j'ai une 9600m sur mon laptop en 1920x1200, et en se contentant d'effets raisonnables, ça marche plutôt bien.
> les jeux ont des perfs assez médiocres
Je veux bien le croire [1], n'ayant pas testé... Bon, par contre, l'article de Phoronix date de X.org 7.2, et le peu que j'ai pu tester de X.org 7.4 me fait dire qu'il serait temps de retester (ie du MythTV OpenGLisé... OK, pas forcément outrancier, en demande de perfs, mais c'était lent comme la mort avec X.org 7.1, beaucoup mieux avec 7.2, buggé comme jamais avec 7.3, et nickel au possible avec le 7.4 - je suis très enthousiaste à propos des progrès de X.org, mais ça ne m'empêche pas d'être très réaliste à ce sujet non plus)...
... même si je dois avouer que pouvoir jouer sous Linux ne me préoccupe personnellement pas tant que ça.
> le rendu 3D a parfois des bugs d'affichage
J'en ai vu dans deux cas :
- quand je forçais DRI en utilisant deux cartes (non, ça n'est pas supporté... oui, ça marchouillait, le problème essentiel étant l'initialisation des cartes qui foirait une fois sur trois, en entrée ou en sortie de X.org... quelques artefacts aussi, dans cette situation hautement insupportée [un des devs freedesktop du pilote tombait des nues quand je lui ai dit que j'étais arrivé à faire marchouiller ça, en jouant du module Int0, alors qu'il ne croyait pas que c'était ne serait-ce que vaguement possible])
- avec cette incurie qu'est X.org 7.3... alors, certes, la plupart des distros l'utilisent maintenant... ça n'en fait pas moins à mes yeux une release digne d'une alpha, cassant des tonnes de choses (y compris le multi-écran... même si ça apport une bien meilleure syntaxe et un bien meilleur backend : non, ce n'est pas stable à compter de la 7.3), et fonctionnant globalement mal (même si c'est à partir de lui que le driver radeon supporte un virtual allant jusqu'à 3968x3968, permettant de faire du gros multi-écran DRIsé... ou un EXA décent, pour donner un autre exemple)... le seul problème de textures corrompues que j'ai pu avoir avec 7.3, ie les textures de MythTV qui se corrompent d'un seul coup (seulement gênant dans l'interface des menus) sont résolus avec le 7.4.
> Les versions récentes du driver libre font freezer le système
Des radeons, j'en utilise 3, sous X.org : deux X800 et une 9600m... toutes avec le dernier driver, soit le 6.8... aucun freeze : sources ?
> ATI sous linux, c'est un peu la roulette russe des cartes 3D, il suffit d'aller voir sur les forums pour se faire une idée
Mouais... l'aide aux utilisateurs libres de radeon, sur les forums, je n'en suis pas en reste...
Ce que je vois, c'est surtout du FUD, et des problèmes essentiellement dûs à l'absence de la libmesa-gl, fournissant le backent OpenGL libre... je n'ai toujours pas compris si c'était parce que les utilisateurs avaient utilisé le blob fglrx avant, et qu'il l'avait écrasée (j'ai déjà vu du bordel de symlinks imbitable, avec ces libs, sur des machines ou des cochonneries comme envy et autres script-tronçonneuses avaient sévi) ou si leur distro n'inclue pas le backend OpenGL libre par défaut (ubuntu, sur laquelle le problème était systématique, il y a quelques temps), mais c'est le problème le plus grave (et de loin, le plus courant) que j'aie jamais vu à ce niveau...
...mais comme par hasard, à chaque fois que quelqu'un me demande comment faire fonctionner sa radeon<=R400, de manière libre, pour avoir plein d'effets kikoolol, ça finit par très bien marcher, avec des utilisateurs très satisfaits : bizarre, non ?
Comme quoi, le FUD, sur les forums, dans les commentaires, partout... ; Fait : les radeons qui fonctionnent avec des drivers libres sont depuis très longtemps (je suis linuxien intensif depuis 4 ans... et je me suis orienté vers les radeons sur les conseils de quelqu'un qui n'utilisait que ça et qui avait commencé un an avant moi) les cartes les mieux librement supportées sous Linux... les seules proprement supportées, en cartes non intégrées, en outre (pour inclure les chips Intel parmis les GPU les mieux supportées) - dire le contraire, vu que c'est quelque chose que j'ai quand même un peu moult expérimenté, pour moi, c'est du FUD ; Oui : fglrx est une bouse inepte - Non : le driver libre n'en est pas une - prière de ne pas réduire les cartes Radeon au driver que ses concepteurs nous fournissent.
... alors après, on peut mettre ça en parallèle avec ce qui se fait sous les autres OS, ou avec des cartes à blobs - mais personnellement, je m'en fous : mes GPU fonctionnent depuis des années avec des drivers libres (j'ai essayé les nvidia blobées : j'en suis revenu très très vite - entre legacy qui perd plein d'options, sortie TV de qualité pire qu'en passant par un scaler à 30€, la recompilation du HAL binaire au changement de kernel, ... c'est bon : j'ai moins de problèmes avec les radeons reverse-engineerées), et vu que ça marche très bien pour les besoins que j'en ai, et que c'est libre, ça me va donc très bien.
PS : désolé pour ce long message, mais le FUD sur les radeons, juste parce que le ATI-bashing a longtemps été de mise, rapport à l'un des pires blobs qui ait probablement pu être (il paraît qu'il s'est amélioré : mais je m'en fous tout aussi bien), et bien que ce bashing ne soit pas applicable aux Radeon<=R400 à drivers libre depuis longtemps également, ça fait donc quelques années que ça me sort par les trous de nez.
[1] http://www.phoronix.com/scan.php?page=article&item=639&a(...)
[^] # Re: Fedora ou Mandriva ?
Posté par Aefron . En réponse au journal De retour sous Mandriva après 6 ans : compte rendu détaillé.. Évalué à 2.
Après, il me semble qu'il y a pas mal de backports de ce que devrait être le java 1.7 officiellement tout libre.
Et en effet, passe pas avec les impôts...
Perso, je suis passé à Fedora ce weekend, en quête de moult bleeding edge, et pour fuir le X.org 7.3 arrivé sur Lenny il n'y a pas si longtemps... et je ne regrette pour l'instant pas - à part qu'il faudra m'expliquer comment gérer la désinstallation automatique des dépendances, quand on désinstalle le paquet qui les a ramenées, avec yum... sous peine que j'en vienne à croire que yum et les dépendances (pas inverses, ça, oui, ça marche, comme l'a montré le journal über-trollesque d'il y a quelques temps), c'est à moitié (à la désinstallation) de l'escroquerie :(
[^] # Re: NVidia
Posté par Aefron . En réponse au journal De retour sous Mandriva après 6 ans : compte rendu détaillé.. Évalué à 5.
C'est ce que j'utilise (des PowerColor, parce qu'elles ne sont pas chères, fournies avec un câble YUV, qu'on peut mettre le dissipateur qu'on veut dessus, et qu'elles ont un connecteur d'alim molex, ce qui n'est pas le cas de toutes) dans mon salon, avec un MythTV sous render OpenGL, sur un 42" full-hd, en dual-screen avec un LCD 17" en 1280x1024, mais aussi sur une autre machine avec un 22" et un 19" cathodique en dual screen (et avant X.org 7.3, je me servais d'une deuxième carte identique pour sortir sur une TV cathodique en plus, sans DRI par contre, puisque pas possible en multi-board)...
Ca fait presque deux ans que je les utilise (avant, j'utilisais des R300, avec des drivers libres... et avant, des R200, toujours avec des drivers libres... j'ai bien du mal à me souvenir de la dernière fois qu'un fglrx est venu pourrir mes machines : même mon laptop est à base de Radeon libre), et je n'ai pas à m'en plaindre (à part quelques bugs de corruption, si je fais du multi-écran avec X.org 7.3 : ça n'arrive cela dit pas avec le 7.2 ni le pre-7.4, pas plus que si je me contente du mono-écran).
En plus, ça ne chauffe pas trop, et avec une bonne ventilation de boîtier, ça se contente allègrement d'un refroidisseur passif à caléoducs...
... préfère quand même les cartes qui ont une prise d'alimentation (6 pins, je crois, pour les GPU ; au pire, il y a des adaptateurs), plutôt que celles qui ne peuvent tirer leur jus que du port PCI-e : de ce que j'ai vu, ça m'a semblé beaucoup plus robuste (sur 6 cartes du genre que j'ai vu, dont 4 à moi, les deux que j'ai vu lâcher n'étaient alimentées que par le PCI-e, les autres, par un connecteur molex : je sais, c'est maigre pour faire des stats... j'ai au moins la décence de le reconnaître : je prends davantage celles qui ont un port d'alimentation par darwinisme préventif et empirique qu'autre chose) ;
Bon, par contre, je ne suis pas gamer sur PC (je me fais déjà engueuler par des potes parce que je n'installe même pas Frozen Bubble par défaut...), donc, je ne saurais dire ce qu'il est pratiquement possible de faire à ce sujet ; cela dit, il me semble qu'un article Phoronix montrait que les performances des ces cartes avec les drivers libres n'étaient pas si loin de celles avec le blob infâme.
Après, course au renouvellement oblige, comme je l'ai dit, ça ne se trouve plus que d'occas... faudrait d'ailleurs que je m'en achète une ou deux autres, au cas où : je l'aurais mauvaise si j'en avais une qui claquait, le driver n'étant pas spécialement prêt pour les R500 et supérieures, et Intel ne faisant toujours, hélas, pas de GPU sur PCI-e...
[1] par exemple : http://www.priceminister.com/navigation/se/category/sa/kw/x8(...)
[^] # Re: Pour le DPI
Posté par Aefron . En réponse au journal Xorg 7.3 chie sur ATI. É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...
[^] # Re: Infos de l'écran
Posté par Aefron . En réponse au journal Xorg 7.3 chie sur ATI. É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: Pour le DPI
Posté par Aefron . En réponse au journal Xorg 7.3 chie sur ATI. É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: Recapitulationnons...
Posté par Aefron . En réponse au journal Xorg 7.3 chie sur ATI. É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é
[^] # Re: Recapitulationnons...
Posté par Aefron . En réponse au journal Xorg 7.3 chie sur ATI. Évalué à 1.
# Recapitulationnons...
Posté par Aefron . En réponse au journal Xorg 7.3 chie sur ATI. É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: Remplacer un halogène
Posté par Aefron . En réponse au journal Halogène vs fluo vs led vs induction. Évalué à 3.
[^] # Re: les lampes à fluorescence, mauvaises pour la santé ?
Posté par Aefron . En réponse au journal Halogène vs fluo vs led vs induction. Évalué à 2.
[1] http://www.megaman.cc/var/files/global/products/booklets/200(...)
[^] # Re: les lampes à fluorescence, mauvaises pour la santé ?
Posté par Aefron . En réponse au journal Halogène vs fluo vs led vs induction. Évalué à 2.
... c'est aussi valable pour les lampes à LED... D'après ce que j'ai compris, celles-ci fonctionnent en courant continu, à basse tension (bah oui, ce sont des LED), d'où la nécessité d'avoir un transfo dans l'ampoule, qui ne supporterait pas la variation de tension en entrée...
J'ai d'ailleurs lu que, malgré le fait que les LED en elle-mêmes ne consommaient presque rien, certaines ampoules à LED, dans leur globalité, consommaient finalement pas mal d'énergie (de l'ordre de quelques dizaines de watts, si je m'en souviens), si elles embarquaient un transfo de mauvaise qualité, de telle sorte que certaines consommaient plus que des fluo... bon, après, je n'en ai jamais acheté, ni démonté, donc, je n'en sais rien en pratique (j'ai dit, "j'ai [...] lu")...
Par contre, pour la variation ce n'est pas si vrai que ça, pour les fluo... en fait, il existe deux types de fluo à variateurs :
- par palliers : apparemment, on fait si on "fait du morse" avec l'interrupteur, ça change l'intensité lumineuse, avec 3 ou 4 intensités possibles ;
- par variation continue : je n'ai vu ces ampoules à la vente qu'outre-Manche (enfin, je n'ai pas regardé non plus outre-Atlantique), mais elles semblent faites pour encaisser la variation continue de lumière, avec un variateur classique, avoir un délai de chauffe très court, et être plus résistantes... par contre, assez chères, de l'ordre de 15-20€, d'après mes souvenirs...
Désolé de ne pas donner de liens sur le test de conso des ampoules LED et sur les fluo à variation : je ne suis pas sur le PC avec ces bookmarks-là :(
[^] # Re: Glauque
Posté par Aefron . En réponse au journal Hans Reiser propose de devoiler l'emplacement du corps de sa femme. Évalué à 10.
... par contre, Dutroux, j'imagine qu'il sera intéressé par un FS peu mature, et particulièrement efficace sur les fichiers de petite taille...
[^] # Re: Arf...
Posté par Aefron . En réponse au journal Firefox est-il toujours libre ?. Évalué à 1.
Plutôt que de parler de logiciel open-sources, on devrait alors parler de logiciels sources : on a le code (enfin, a priori), mais bon...