[Résolu] OpenBSD 4.1 (radeon mobility X700)

[H3dy]

Aefron,

je précise que startx lance bien fluxbox comme souhaiter (d'ailleur si tu connais une méthode pour démarrer comme une balle sans passer pour passer! .>..(je le trouve un peu lent au boot avec tout ce que le système doit charger...)

donc:

-l'option DCCmode est déjà supporter

-je nettoye la section Screen & Viewport

Puis-je compacter la section "InputDevice" car le keyboard n'est pas FR_fr et n'est même pas présent dans /etc/X11/xorg.conf?

ou je rajoute:

Section "InputDevice"
Identifier "keyboard0"
Driver "keyboard"
Option "CoreKeyboard"
Option "?"
Option "XkbLayout" "fr"
EndSection

Concernant X11 j'utilise celle de la version d'openBSD 4.1...

tu m'excuses si j'incite sur le driver ati (linux) mais je ne trouve pas ca normal que qu'en je lance le serveur X qu'il ne soit pas capable de détecter ni les drivers "ati" ou "radeon" et me force à utiliser "vesa" pour une indétection d'écran!...

[Compte_supprime_74291]

Si le clavier ne te convient pas, tu peux rajouter :

Option		  "XkbModel"	  "pc105"
Option		  "XkbVariant"	"latin9"

A moduler en fonction du modèle exact de ton clavier et de la variante du clavier français que tu souhaite...

Sinon, tu confirmes bien que ça marche avec un autre écran ET le driver libre (ce que tu as dit plus haut)? Auquel cas, j'en reste sur l'idée que c'est un problème de modeline et/ou de sortie numérique sur DVI... les LCD sont extrêmements sensibles aux mauvais modelines, et les écrans à entrée numérique encore plus...

Ah oui... en l'état (X.org pré-7.3), pas d'autodétection des drivers... il utilise par défaut celui qui est déclaré dans le xorg.conf... Si tu obtiens un écran noir, c'est soit que le driver est buggé (je n'ai eu aucun problème avec lui lors de mon passage sous OpenBSD... ce qui est cool, vu que je n'ai que des radeons), soit qu'il est mal configuré...

As-tu essayé de voir s'il y avait des choses bizarres dans /var/log/Xorg.log.0 (oui, je sais, plus facile à dire qu'à faire...)...? essaye de voir ce qui s'y rapporte à ton écran... s'il y a quelque chose de pas net, il te mettra des warning ou des erreurs...

Autrement, pour le blob ati sous OpenBSD, je me répète, mais n'y pense même pas... j'aurais tendance à dire: aucune chance...

[H3dy]

#Option "DDCMode" #[<bool>]

#Option "MonitorLayout" #[<str>]

faut il remplacer "MonitorLayout" str par bool ou c'est des options invariables?

je confirme que startx (driver "ati") fonctionne très bien par la sortie vga de ma carte graphique lorsque je branche un autre écran et sans celui ci le serveur X me force à utiliser "vesa".

[H3dy]

Aefron,

tu as raison..c'est un vulgaire problème de sensibilité (problème de modeline non supporté) puisque je vois le début du lancement de startx (quelques fractions de secondes) et par la suite j'ai un écran noir. (comme ci l'écran était éteint)

[Compte_supprime_74291]

Si tu veux utiliser ces options, décommente les lignes (enlève le # en début) et remplace #[<bool>] soit par "0", "1", "true", "false", "on" ou "off" (ils doivent marcher tous les 6)...

... et remplace #[<str>] par "LVDS,NONE" ou d'autre combinaisons avec les mots-clés de le page de man que je t'ai linkée (ça force le mode des deux sorties de ton GPU... par exemple, dans le cas que je te donne LCD pour la première sortie, rien sur la deuxième sortie)...

Sinon, ton écran, c'est un LCD en DVI? En tout cas, le fait que ça marche avec le CRT confirme ce que je pense du problème: modeline (fréquences de rafraîchissements version hardcore, ce qui peut interférer avec celles que tu as déclarées si elles ne sont pas adaptées à ton écran) et/ou sortie numérique pas correctement détectée... Es-tu sûr que les fréquences de rafraîchissement que tu as déclarées sont valides pour l'écran que tu veux (à vérifier sur la fiche du constructeur, par exemple... ou via les informations DDC données par l'écran au GPU)...

Edit: si c'est vraiment un problème de modeline, tu peux en générer un spécifique avec les générateurs de modeline que tu pourras trouver sur le net (ce qui nécessitera quand même de connaître les bonnes fréquences de ton écran), ou essayer de faire marcher le DDC...

Re-edit : ah oui... un truc qui peut déconner des fois... les bios des GPU sont souvent bizarres, et si un connecteur n'est pas utilisé lors du boot du PC, il se peut qu'il reste désactivé par la suite, jusqu'à ce qu'il soit branché lors d'un reboot successif... ça arrive et ça peut éventuellement se corriger à chaud avec les options Int0 de X.org pour forcer une réinitialisation de la carte au démarrage de X.org, mais là, c'est de la haute bidouille...

[H3dy]

Aefron,

mon écran est un "écran 15.4" WXGA TFT LCD" (jai pas plus d'informations), connaiterais tu une méthode pour inutiliser le driver xf86? ou suis-je forcer à l'utiliser? (avec un startx fonctionnel)

j'ai déclaré des plages de fréquences, j'utilise 60Hz par défaut...

[Compte_supprime_74291]

Si tu n'as pas plus d'informations et que DDC ne fonctionne pas directement, tu peux espérer que les infos soient quand même déclarées à ton GPU... dans ce cas, ouvre le fichier /var/log/Xorg.log.0, et fais-y une recherche sur le mot "modeline" (pas le choix, il va falloir y mettre les mains )...

Tu devrais tomber sur quelque chose du genre (ce que j'ai sur le laptop d'où je t'écris) :

(II) RADEON(0): Validating modes on Primary head ---------
(II) RADEON(0): Panel ID string: 1920X1200 WUXGA
(II) RADEON(0): Panel Size from BIOS: 1920x1200
(II) RADEON(0): BIOS provided dividers will be used.
(II) RADEON(0): Total number of valid DDC mode(s) found: 0
(II) RADEON(0): Valid mode using on-chip RMX: 1920x1200
(II) RADEON(0): Total number of valid FP mode(s) found: 1
(--) RADEON(0): Virtual size is 1920x1200 (pitch 1920)
(**) RADEON(0): *Mode "1920x1200": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "1920x1200"  157.50  1920 2008 2040 2144  1200 1202 1203 1212
(**) RADEON(0):  Default mode "640x350": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "640x350"  157.50  640 2008 2040 2144  350 1202 1203 1212
(**) RADEON(0):  Default mode "640x400": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "640x400"  157.50  640 2008 2040 2144  400 1202 1203 1212
(**) RADEON(0):  Default mode "720x400": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "720x400"  157.50  720 2008 2040 2144  400 1202 1203 1212
(**) RADEON(0):  Default mode "640x480": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "640x480"  157.50  640 2008 2040 2144  480 1202 1203 1212
(**) RADEON(0):  Default mode "800x600": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "800x600"  157.50  800 2008 2040 2144  600 1202 1203 1212
(**) RADEON(0):  Default mode "1024x768": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "1024x768"  157.50  1024 2008 2040 2144  768 1202 1203 1212
(**) RADEON(0):  Default mode "1152x864": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "1152x864"  157.50  1152 2008 2040 2144  864 1202 1203 1212
(**) RADEON(0):  Default mode "1280x960": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "1280x960"  157.50  1280 2008 2040 2144  960 1202 1203 1212
(**) RADEON(0):  Default mode "1280x1024": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "1280x1024"  157.50  1280 2008 2040 2144  1024 1202 1203 1212
(**) RADEON(0):  Default mode "1600x1200": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "1600x1200"  157.50  1600 2008 2040 2144  1200 1202 1203 1212
(**) RADEON(0):  Default mode "832x624": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "832x624"  157.50  832 2008 2040 2144  624 1202 1203 1212
(**) RADEON(0):  Default mode "1280x768": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "1280x768"  157.50  1280 2008 2040 2144  768 1202 1203 1212
(**) RADEON(0):  Default mode "1280x800": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "1280x800"  157.50  1280 2008 2040 2144  800 1202 1203 1212
(**) RADEON(0):  Default mode "1152x768": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "1152x768"  157.50  1152 2008 2040 2144  768 1202 1203 1212
(**) RADEON(0):  Default mode "1400x1050": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "1400x1050"  157.50  1400 2008 2040 2144  1050 1202 1203 1212
(**) RADEON(0):  Default mode "1440x900": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "1440x900"  157.50  1440 2008 2040 2144  900 1202 1203 1212
(**) RADEON(0):  Default mode "1600x1024": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "1600x1024"  157.50  1600 2008 2040 2144  1024 1202 1203 1212
(**) RADEON(0):  Default mode "1680x1050": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz
(II) RADEON(0): Modeline "1680x1050"  157.50  1680 2008 2040 2144  1050 1202 1203 1212

Tu peux alors tenter de copier une des lignes du genre :

Modeline "1920x1200"  157.50  1920 2008 2040 2144  1200 1202 1203 1212

dans la section Monitor faisant référence à ton écran (et en commentant VertRefresh et HorizSync, a priori)... ou juste d'utiliser les deux derniers chiffres de la ligne au-dessus qui correspondent respectivement à HorizSync et VertRefresh pour la résolution concernée...

[H3dy]

donc :

HorizSync 1203

VertRefresh 1212

Modes "1920x1200"

aie-je bon si j'en suis ton exemple?

[Compte_supprime_74291]

Non... j'ai parlé de la ligne au dessus du modeline complet, soit, en l'occurence :

(**) RADEON(0): *Mode "1920x1200": 157.5 MHz (scaled from 0.0 MHz), 73.5 kHz, 60.6 Hz

qui correspondrait à :

HorizSync 73.5
VertRefresh 60.6
Modes "1920x1200"

dans mon cas... (la fréquence verticale est toujours de l'ordre de quelques dizaines à la centaine de Hz, ce qui correspond d'à quelques dizaines à la centaine de fois par seconde... soit le framerate, grosso merdo... et la fréquence horizontale, du fait de la nécessité de balayer tout l'écran à chaque frame, ou plus précisément toute la largeur de l'écran à chaque ligne, est de l'ordre de quelques dizaines de kHz, soit mille fois plus rapidement, à une vache près, en fonction de la résolution de l'écran)...

Edit : le modeline complet rajoute plein de valeurs que je serais bien en peine d'expliquer et que je considère allègrement comme du vaudou incantatoire, ceci dit bien pratique pour pousser un peu les CRT dans leurs retranchements, ou faire marcher les écrans en numérique

Re-edit: sinon, pour info, dans mon exemple, le 175MHz correspond à la fréquence à laquelle le GPU envoie des infos à l'écran... c'est grosso merdo la fréquence du RAMDAC...

[Compte_supprime_74291]

si tu connais une méthode pour démarrer comme une balle sans passer pour passer! .>..(je le trouve un peu lent au boot avec tout ce que le système doit charger...)

Ah oui... je n'avais pas répondu à ça...

Bon, ça dépend de ce que tu veux obtenir... soit tu utilises un session manager (gdm, kdm, xdm, ...) que tu fais lancer en tant que service au boot... cas classique...

Soit tu ne peux pas blairer le login clickodromé (moi, je ne peux pas ... je considère que c'est du bloat ), et tu te loggues en tty avec un startx lancé par le .bashrc de l'utilisateur dès qu'il s'est loggué...

A remarquer que tu peux faire de l'autologin dans un cas comme dans l'autre, à condition d'évaluer les risques de bugs de l'interface chaise/clavier (sur un laptop, je ne le ferais pas... pas confiance dans les gens chez qui j'amène mon laptop, puisque ce sont des "autres", ie des aliens [en espérant que la douce succube qui dort ronfle dans la pièce d'à côté ne lise pas ça ]... pour le HTPC, ça me paraît par contre indispensable... et gare au malheureux qui essaiera de faire des abus sur mes terres )... en tty ça se fait avec des tty du genre de mingetty...

[H3dy]

en faite le driver xf86 dépend de l'architecture embarqué si on veut utiliser le "window manager", en l'occurence dans mon cas i386..

si la valeur est à 1 il correspond au serveur Xfree86

si la valeur est à 2 il correspond au serveur X.org

si la valeur est à 0 le driver xf86 est dèsactiver

je prècise encore que le faite qu'il soit activer génére plus ou moin des failles de sécurité!

j'aurai qu'en même voullu savoir par curiosité quelles sont les architectures qui peuvent utiliser un window manager sans même utiliser xf86?

[madko]

activer cette option ne "genere" pas de faille de sécurité

ensuite un window manager qui utilise pas xf86, ba il utilisera xorg c'est compatible.

Je te conseille de te faire la main sur un linux, prend un truc facile d'acces, genre Ubuntu, ou Fedora. T'aura surement Xorg d'autoconfiguré, tu pourra regarder comment c'est fait. Une fois que t'aura vu et appris comment marche un unix tu pourra revenir a OpenBSD

[H3dy]

madko,

j'ai déjà un exemple d'autoconfiguration sur le liveCD que j'emploie qui lui même n'a pas accès à la partition ou est installé Openbsd.

"d'ailleur c'est grâce à lui si j'ai un serveur X fonctionnel par le driver vesa"

"Il existe des conséquences sur la sécurité, ne le faites pas si vous n'en avez pas vraiment besoin."

ce n'est pas moi qui le dit mais la documentation officielle d'OpenBSD 4.1.

et dans la logique si j'installe le serveur xorg je dois utiliser le driver aperture xf86...donc j'en conclus que le driver xf86 correspond bien aux 2 serveurs que l'on peut employer soit xorg ou xfree86 (avec ces trois modes de fonctionnement qu'il utilise citez ci dessus! (0, 1 & 2)

c'est le même "pilote aperture" qu'employe les 2 serveurs.

[madko]

"Il existe des conséquences sur la sécurité, ne le faites pas si vous n'en avez pas vraiment besoin."

mais il me semble que c'est pour ton poste de travail nan?? c'est pas un serveur que tu monte?? c'est sur vu que tu veux le mode graphique. Qu'on parle de sécurité pour un poste de travail ok, mais pas de paranoia.

X et toute application quelqu'elle soit peut avoir des conséquences sur la sécurité donc ça veut rien dire ce truc. Je veux pas descendre OpenBSD, jmen suis servi pendant des années, cet OS est plutot correcte, mais c'est sa "communication" qui enerve un peu. OK ya un vrai audit sur certaines parties de codes, mais serieusement ne tombe pas dans le panneau des slogans d'OpenBSD. Genre "seulement 2 failles decouvertes en 10ans sur une installation par defaut" tu en comprend quoi? que le code et les appli sont ultra sécurisée? et bien non, ça veut juste dire que par defaut ya aucun service/appli qui tourne. Pas de services, pas de failles utilisables, mais elles peuvent etre là. Yaurai pas de correctifs de sécurité sinon... Et si c'etait si sécurisé que ça on le verait partout en entreprise, j'en ai jamais croisé pour l'instant... Mais qui a besoin d'un OS qui ne fait rien tourner? mais ça reste un gage de qualité quand meme, mais il faut prendre ce slogan dans le bon sens

En plus, faire en sorte que les pilotes graphiques fonctionne bien je pense que c'est pas la priorité sur OpenBSD, Si tu veux un jour utilisé ta carte video correctement vise qqchose de plus supporté comme un Linux (ou meme un FreeBSD je pense, voire meme solaris c'est pour dire). Je dis ça car si ça se trouve c'est tout simplement pas possible de faire marcher ta carte video sur cet OS. T'a trouvé avec google des cas où ça marchait?

Mais bon jme trompe peut etre, c'est vrai que je suis l'evolution d'openBSD que de tres loin, ils sont peut etre a la pointe, genre avec les dernieres version de Xorg 7.3, des trucs ultimes sur le kernel, genre la virtualisation, et des appli recentes (genre firefox 2.0.6 ba ouai vaut mieux avoir la derniere version pour surfer en toute securité).

Bon sinon je maintient ce que je dis, activé l'option aperture truc ne genere pas des failles de secu, quand meme voyons un generateur de bugs apres?

[Compte_supprime_74291]

OK ya un vrai audit sur certaines parties de codes, mais serieusement ne tombe pas dans le panneau des slogans d'OpenBSD. Genre "seulement 2 failles decouvertes en 10ans sur une installation par defaut" tu en comprend quoi? que le code et les appli sont ultra sécurisée? et bien non, ça veut juste dire que par defaut ya aucun service/appli qui tourne. Pas de services, pas de failles utilisables, mais elles peuvent etre là. Yaurai pas de correctifs de sécurité sinon...

+1 Madko... la sécurité est une attitude... ne pas faire tourner de choses inutiles, comprendre au maximum comment sa machine fonctionne, faire des compromis dont on mesure l'implication...

... s'il y avait des solutions miracles, ça se saurait... la parano est une manière de vivre l'informatique... pas un mantra miracle...

Après, je ne dis pas... il y a des choses très sympas sur OpenBSD... mais on peut en retrouver beaucoup (pour ainsi dire, en ce qui concerne du moins le plan technique, toutes) sur d'autres OS (notamment, en utilisant une distro compatible PAX/Grsec, par exemple)...

Mais bon... si tu en es à te prendre la tête sur si tu dois utiliser xfree ou X.org, alors que le second est un fork du premier, premier qu'on ne doit plus des masses trouver sur les distros ultra-libristes du fait de son changement de license pourri, tu te prends peut-être beaucoup la tête alors qu'un peu d'expérience en plus ne te ferait pas de mal, H3dy...

... c'est comme vouloir faire tourner opera, un logiciel proprio, sur un OS qui base une partie de sa sécurité sur la compilation des applis en utilisant PIE et cie... et se dire que comme l'OS serait "sécurisé", ce serait cohérent... bah non... opera, tu ne peux pas le recompiler, donc niveau protection de la pile mémoire, c'est zobi... pareil pour le blob fglrx... c'est incohérent... et ce, même en faisant abstraction de tout extrêmisme open-sourcien...

Tant que tu ne comprends pas en quoi il y a des incidences sur la sécurité à faire telle ou telle chose, c'est comme mettre un casque à visière opaque et rouler à 300km/h en deux roues en te disant qu'au moins, rien ne risque de t'exploser les yeux...

[H3dy]

madko,

c'est bien pour une workstation, ma carte graphique ne fonctionne qu'avec le pilote "vesa" que j'avais déjà préciser dans mes posts précédents donc j'en déduis que ma carte graphique (vidéo) fonctionne.

ton raisonnement est logique en somme, les failles de sécurité sur OpenBSD ne concerne pas que le système en lui même, d'autres applications utilisable génère une donnée X (nombre de failles possibles) "c'est les Algorithmes et Probabilités" dont il s'agit. Avec OpenBSD

tu auras cette fonctionnalité de réduire au mieux les risques potentiels par rapport à d'autres OS puisque l'intention est porté essentiellement sur la sécurité, la cryptographie et la stabilité.

Vesa BIOS Detected
Vesa VBE Total Mem : 16384 kb
Vesa VBE OEM: ATI ATOMBIOS
Vesa VBE OEM Software Rev: 9.10
Vesa VBE OEM Vendor: 1988 - 2003, ATi Technologies Inc
Vesa VBE OEM Product: M26-P 
...(rev0100)...

Aefron,

j'ai essayé tant bien que mal à forcer l'utilisation des drivers "ati" ou "radeon" mais sans succès! (aucun modeline supporté), le type d'erreur que recois dans /var/log/xorg.0.log:

not using default mode (hsync out of range) (bad mode clock/interlace/doublescan)

le seul mode en phase de test est:

640x480 25,2Mhz 31,5Khz, 60.0Hz
HorizSync: 31.5
VertRefresh: 60
Modes: 640x480
unsuccessful

et j'avais bien une section :

Section "InputDevice"
Identifier  "Keyboard0"
Driver	  "keyboard"
Option		"XkbModel" "pc105"
Option	  "XkbLayout" "fr"
EndSection
Section "Monitor"
Identifier   "Monitor0"
HorizSync	31.5 
VertRefresh  60
EndSection

A quoi correspond:

Write(combining rangs (0x0, 0x1000) was already clear?

il est possible d'optimiser le driver "vesa", de fixer les plages d'entrées et de sorties (I/O) ?

ressources ranges after PreInit
module "int10"
primary BIOS segment is 0xc000.

A priori Opera a générer beaucoup moin de failles de sécurité que Firefox , et de loin! celui que je préfère...je vais pas me limiter à une licence qui est soit disante propriètaire...et je te rappelle qu'il n'est pas préférable de compiler. (don't panic)

Si je peux utiliser les packetages binaires pré-compilés c'est ce qui se fait de mieux. c'est plus simple, plus sur et plus stable que la compile de barbares. Détrompe moi si je me trompe?

Et concernant les drivers ATI, ATI s'ouvre au monde du libre (accès au code source!), tant mieux...On aura très certainement des améliorations tant bien qu'en matière de performances, stabilité et portabilité .

[Compte_supprime_74291]

Pour le mode 640x480 qui semble le seul détecté (très étonnant), il faut bien sûr aussi que tu déclares un mode pour cette résolution dans la sous-section display pour l'utiliser... m'enfin, c'est bizarre que ton LCD ne semble déclarer que cette résolution à ton GPU... tu n'as que le 640x480 dans les modes possibles /var/log/Xorg.log.0? C'est vraiment bizarre...

Sinon, pour ce qui est de compiler ses logiciels, je ne vois rien de mal... certes, c'est beaucoup plus gérable de passer par le système de paquets de la distro, mais certaines sont particulièrement bien foutues pour compiler (notamment OpenBSD ou Gentoo)... après, le risque, c'est d'avoir un compilateur qui va faciliter le boulot d'un éventuel intrus... certes... tu n'es cependant pas obligé d'avoir un compilateur sur une machine qui fait office de serveur...

... m'enfin, ce n'est pas du tout ce dont je parlais... OpenBSD a beau avoir recours a des tas de méthodes de sécurisation (type PIE, par exemple, pour randomiser la pile mémoire et rendre plus difficile l'exploitation des buffer overflows), si tu prends des binaires qui ont été compilés par un tiers (en l'occurence, l'éditeur proprio... proprio par définition, puisqu'on n'a pas les sources, et pas soit-disant, du coup), sans avoir recours à ces optimisations de compilation (a contrario des paquets OpenBSD qui ont, dans la mesure du possible étés compilés avec elles), ces binaires proprios ne bénéficient pas du tout des optimisations de sécurité... là était mon propos... hors de toute considération libriste ou open-sourcienne, les softs proprios ne peuvent pas être optimisés de cette manière... ça la fout mal sur un système fait pour baser une partie de sa sécurité sur ces optimisations, puisque du coup, le soft proprio devient un single weak point qui ruine tout l'effort mis en place... bon, après, c'est ta machine, tu fais comme tu veux... mais c'est incohérent (ou en tout cas, tu fais implicitement abstraction de ce genre de feature de ton OS... c'est un peu dommage de prendre OpenBSD, à ce moment-là)...

Pour les drivers ati, tu as du mal lire... il n'y a pas d'ouverture de fglrx (et franchement, je me demande ce qu'on en fouterait, vu comme il est mauvais), mais la fourniture de spécifications sous NDA, et d'un driver libre 2D très basique (et encore... attendons de voir dans les faits la concrétisation des promesses)... ce qui est déjà très bien, certes, certes... n'en reste pas moins que fglrx est un module noyau (qui n'a aucune chance d'être adapté pour OpenBSD, vu la haine que Theo de Raadt voue aux blobs, m'est avis à raison), qu'il est proprio, et que niveau portabilité et gérabilité (rapport à la grande versatilité des API des noyaux), c'est le niveau zero, quoi qu'il se passe....

[madko]

je vais pas rajouter une couche sur l'incohérence d'utiliser Opera sur openbsd, on est plus à ça pres

pour revenir au sujet, t'es sur de tes horizsync et vertrefresh? ça me parait un peu faiblard alors forcement si tu limite la plage d'utilisation de l'ecran il peut pas monter tres haut en resolution. c'est pour un portable? c'est quoi ça reference?

Et quand jdis que ta carte marche pas, c'est avec les pilotes ati/radeon, c'est pas parceque ça passe en VESA que ça passera forcement avec les pilotes ATI/Radeon. Vesa c'est le truc de base que toute carte video est censé supporté.

Apres je suis d'accord, l'ouverture des spec meme sous NDA va peut etre ameliorer les choses pour ATI, mais bon ya un lourd passif, j'attend de voir d'ici qq mois ce que ça va donner

[H3dy]

madko,

j'ai même augmenter les plages de fréquences en ayant tester les drivers "ati & "radeon" soit:

HorizSync 30.0 - 107.0

VertRefresh 48.0 - 120.0

(et j'ai même essayer l'option "DMPS")

En utilisant le driver "vesa" fonctionnel je n'arrive pas à régler la résolution:

DefaultDepth 24

SubSection "Display"

Depth 24

Modes "1024x768"

Ayant indiquer ceci ou une autre résolution il n'y a pas de différence, j'utilise par défaut 800x600 ce que je ne veux pas.

Que faire?

Si je rajoute:

Section "module"

load "int10"

que cela produit?

[madko]

c'est quoi la ref du portable?

[H3dy]

madko,

un aspire 1692 WLMi ACER

[H3dy]

j'ai fait un recensement des modules que je peux supporter:

Section Modules!
"pcidata"
"bitmap"
"dbe"
"extmod"
"glx" => OpenGL
"GLcore" => OpenGL
"record"
"xtrap"
"freetype"
"type1"
"int10"
"ati"
"radeon"
"mouse"
"kbd"
"vgahw"
"ddc"
"i2c"
"ramdac"
"fb"
"theatre_detect"

http://www.generation-debian.org/wiki/doku.php?id=le_serveur_d_affichage

lesquels choisir?

[Compte_supprime_74291]

Normalement, les modules dont tu as vraiment besoin (à part ceux dont peuvent résulter des instabilités, comme dri, que tu n'as de toute façon pas sous OpenBSD) sont chargés automatiquement...

... ceci dit, vu que ton écran ne semble pas déclarer ses modes à ton GPU, tu peux toujours forcer le chargement de DDC, et éventuellement de i2c (les deux peuvent être liés)...

Edit : Sinon, en googlant un peu sur ton modèle de portable, il semble que l'écran noir au démarrage de X soit récurrent sur ce modèle (carte au bios bizarre?)... apparemment, il est conseillé à plein d'endroits d'utiliser

Option "MonitorLayout" "TMDS, NONE"

ou des fois LVDS à la place de TMDS, voire certaines variantes avec juste TMDS, et pas le NONE...

... voire en plus...

Option "BusType" "PCIE"

(ce qui me paraît encore plus bizarre, vu que ce n'est pas censé avoir d'effet, à en croire la page de manuel... et que je n'en ai jamais eu besoin avec de la carte PCIe... m'enfin, si ton GPU est bizarre, pourquoi pas...)...

[H3dy]

Aefron,

Option "BusType" "PCIE" => option "BusType" is not used..

Option "XkbVariant" "latin9" => is not a valid keyword...

j'ai essayer plusieurs combinaisons, les drivers "ati" & radeon" ne fonctionnent pas...

Comment vais-je pouvoir utiliser une autre résolution avec un modeline non supporté?

ah oui aussi j'avais oublier, j'ai plusieurs unloadmodules à la fin du log, dans ces cas là est ce réellement nécessaire de les utilisés?

à priori non...

[Compte_supprime_74291]

Pour le PCIE, ça ne m'étonne pas... normalement, il est strictement équivalent à PCI (la page de man dit "falls back to PCI at the moment"... donc...)...

Pour le latin9, peut-être a-t-il un autre nom sur OpenBSD... jette un coup d'oeil dans /usr/share/keymaps/i386/azerty ... ou quelque chose du genre... tu devrais y trouver des archives de la forme : fr-latin9.kmap.gz ... ce qui signifie variante latin9 du clavier fr... choisis celle que tu veux avoir...

Sinon, l'idéal serait que tu nous postes ton /var/log/Xorg.log.0 ... au pire, installe un browser sur ton OS, accède à X en vesa, et envoie-le nous de là... ce sera plus simple... ça m'étonne qu'aucun modeline ne soit déclaté, même en forçant le chargement du module ddc...

Sinon, pour les unloadmodules, ce peuvent aussi bien être le fait que, finalement, ils ne servent pas et sont automatiquement déchargés... que le fait qu'ils soient déchargés à la sortie de X.org, tout simplement...

Ah oui... et pas besoin de te prendre la tête à essayer les variantes pour "radeon" et pour "ati"... je te l'ai dit... l'un ou l'autre, ça revient strictement au même... le driver "ati" contient le driver "radeon"... pas de souci là-dessus... au pire, si tu veux être précis, prend "radeon", mais ne t'ennuye pas à essayer l'un, puis l'autre... ça ne change strictement rien...