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

[H3dy]

Bonjour,

N'ayant pas paramètrer ma connexion internet lors de la première installation du système d'exploitation et ayant créer un utilisateur-administrateur du groupe wheel

par la commande adduser ($):

Comment paramètrer la variable PKG_PATH et utiliser la commande pkg_add? A savoir que j'ai télécharger mes fichiers compacter et graver sur un DVD directement sans dossiers.

D'après la documentation officielle:

$ export PKG_PATH=/mnt/cdrom/4.1/packetages/`machine -a`/

ne pouvant pas réaliser cette commande et ne voullant pas l'utiliser pour le moment:

$ export PKG_PATH=ftp://your.ftp.mirror/pub/OpenBSD/4.1/packages/`machine -a`/

A quoi correspond /`machine -a`/ ?

/4.1/packetages/ correspond aux sous-dossiers du CDROM si je ne me trompe.

Comment avoir la commande sudo puisque je rencontre l'erreur suivante après la demande du password:

is not in sudoers file...

Exemplairement par:

$ export PKG_PATH=/mnt/cdrom/`machine -a`/ (enter)
$ sudo pkg_add -v fluxbox-0.9.15.1p0 (enter)

Existe il une méthode d'installation par décompactage automatique en créant une image ISO pour les installés? j'en ai tout de même + de 340

Par ligne de commande vais-je en avoir pour longtemps?

[madko]

et ouai c'est long, bienvenu dans le monde d'openBSD

le machine -a doit etre une commande pour trouver la version actuelle de ton openBSD afin de taper dans la bonne url. Tu peux tres bien la remplacer manuellement surtout si tu connais le chemin d'acces de tes packages

pour ton probleme de sudo verifie deja que ton utilisateur est bien dans le groupe wheel avec la commande id

Tu peux en tant que root modifier ton fichier sudo avec la commande visudo

sinon pkg_add marche bien si t'es deja root, pas besoin de faire sudo du coup

[tyrann27]

machine -a sert à te donner l'architecture de la machine (dans mon cas : i386)

[H3dy]

Bonsoir tout le monde!

l'installation de fluxbox a été réussi! je suis hélas confrontrer à un autre problème:

le serveur X!

#fluxbox (enter)

Error: Couldn't connect to Xserver

lancement du serveur X:

#startx (enter)

(écran noir?!)

crtl+alt+backspace

en suivant la documentation, nouvelle configuration:

#X -configure /root/xorg.conf.new (enter)

(écran noir après le lancement de startx)

Que puis-je faire? dois-je utiliser la méthode manuelle ou intérative

Manuelle:

#X -configure (enter)

Intéractive:

#xorgconfig (enter)

Ayant une carte graphique ATI MOBILITY RADEON X700 pci Express

Est-ce que je peux installer ATI Proprietary Linux x86 Display Driver 8.40.4? (pour linux)

file: ati-driver-installer-8.40.4-x86.x86_64.run (extension .run)

en mode root:

#sh ati-driver-installer-8.40.4-x86.x86_64.run

Peut-on faire fonctionner le gestionnaire de fenêtre beryl/xgl sous OpenBSD 4.1? (Compiz Fusion)

[Compte_supprime_74291]

Pour ce qui est des drivers GPU sous OpenBSD, si je me rappelle bien mon passage sous ce magnifique OS (je suis du genre très parano ) de la 3.9 à un peu de 4.0, tu pourras faire marcher tout ce qui concerne OpenGL et cie, mais sans la moindre accélération...

En effet, les devs (notamment Theo... pas le notre... de Raadt) considèrent, à raison, dri (direct rendering interface) comme un risque important pour la sécurité... grosso merdo, dri permet d'accéder directement au GPU et à sa mémoire en bypassant les contrôles classiques du noyau... de ce fait, n'importe quel utilisateur avec les droits sur dri peut ainsi accéder directement au matériel et potentiellement y placer des cochonneries...

Donc, le clickodrome composité, oui, tout à fait... mais sans accélération matérielle: tout en soft...

... d'ailleurs, je me rappelle avoir vu des trucs très bizarres en utilisant dri (sous linux)... notamment des petits bugs avec le double-buffering de conky à son démarrage où, avant qu'il ne s'affiche, j'avais le droit d'avoir des bouts d'images affichées lors d'un précédent démarrage de X.org et même, d'un précédent reboot (moyennement classe, quand ça t'affiche du Pr0n après un reboot )!...

Du coup, a priori, pas la moindre chance de voir dri (et donc l'accélération matérielle GPU) sur OpenBSD... ou en tout cas, pas avec les paquets officiels... je te laisse en déduire ce que tu veux sur les blobs sous ce merveilleux bastion de l'opensource parano

Sinon, normalement, les X700 sont censées fonctionner avec le driver libre radeon...

[madko]

Je me trompe peut etre mais DRM/DRI c'est justement fait pour que ça soit le kernel qui gere les acces au materiel, et non plus directement xorg en tapant dans /dev/mem et autres de manieres à justement eviter le kernel... C'est pour ça d'ailleurs que Xorg est presque concidéré comme un OS, et qu'il doit tourner en tant que root ce qui est pas tres sékioure, et qu'il doit fournir ses propres pilotes...

Moi jprefere DRM/DRI et un kernel qui sait qu'on accede au matos, plutot que X qui tourne en root et qui cause direct au matos...

Bon pour revenir au sujet, H3dy tu devrais peut etre tenter qqchose de plus user friendly pour debuter dans le monde Unix, genre un Linux? Pourquoi OpenBSD tu travaille a la NSA?

sinon le X -configure il t'a pas generer un fichier de conf? il a pas specifier le driver radeon dedans? tu a tenter de lancer X avec ce fichier comme indiqué?

[H3dy]

Aefron,

Si DRI permet l'accès direct en mémoire du GPU, cmos, MOSFETs (ect..) je ne veux pas d'accélaration 3D (pas de buffer overflow non plus => Stack-Smashing Protector!)

puis-je tout de même utiliser compiz fusion (compiz ou beryl) et ses plugins de manière limitative?

ati-driver-installer-8.40.4-x86.x86_64.run peut être installer si je souhaite utiliser xgl?

je galère pour faire marcher le server X, vesa ouvre toi?

[madko]

bon euh, il est tard mais faut pas tout melanger (GPU, cmos, MOFSET..., jpasse le buffer overflow dont tu parle aussi)

Installer un pilote ATI fait pour un kernel linux x86_64 sur un kernel OpenBSD tu peux tenter, ya tres peux de chance que ça passe

Deja que les pilotes ATI sous linux c'est galere (c'est en train de changer) j'imagine meme pas sous openBSD

Aefron à expliquer que normalement tu pourra acceder a toutes les fonction OpenGL, mais ça sera pas acceleré donc bon...

Ensuite c'est pas vesa qu'il faut tenter mais radeon dans ton xorg.conf

[H3dy]

madko,

j'arrive pas à configurer X, j'ai pourtant lu la documentation mais je n'y arrive toujours pas.

Si je réalise la commande:

#startx

ou encore

#xdm

j'ai un écran noir

si je fais:

#X -configure

[...]

Your xorg.conf file /root/xorg.conf.new

To test the server, run 'X -config /root/xorg.conf.new'

puisque j'ai fait:

#X -config /root/xorg.conf.new

[madko]

puisque j'ai fait:

#X -config /root/xorg.cong.new

ça tu l'a bien fait apres ton X -configure ? attention c'est pas la meme commande hein

et dans ce fichier tu a regardé si tu avait bien une ligne Driver "radeon" dans la Section qui parle de ta carte video?

Si ça marche pas, regarde tu dois avoir un fichier de log avec peut etre des info interessantes dans /var/log/Xorg.0.log

[Compte_supprime_74291]

Je ne suis pas spécialiste du tout, mais il me semble que Theo était réticent à implémenter DRI/DRM (qui existe sous FreeBSD et qui devrait, dans une certaine mesure, être portable sous OpenBSD) à cause de problèmes de séparation des registres privilégiés et non privilégiés dans les GPU grand public... il me semble que j'étais tombé sur une mailing list où il considérait qu'il faudrait changer complètement la manière de gérer ça par les systèmes actuels pour que ce soit sécuritairement acceptable...

Je crois que ce n'était pas tant le concept de dri qu'il remettait en cause que la manière dont on peu l'implémenter sur les bus/gpus actuels... et que le risque était, malgré dri, un risque d'escalade à grands coups de DMA du gpu vers le reste... mais je ne suis pas spécialiste du tout, comme je l'ai dit...

Sinon, pour ce qui est du clickodrome composité, je l'ai déjà vu fonctionner sur OpenBSD (pas sur les miens... je suis un accro à FVWM qui n'est pas encore composité de manière stable... il y a bien metisse, mais...)... je ne sais plus ce que c'était, mais de toute façon, ça fonctionnait en software et c'était plutôt lent... bon, de toute façon, pour la 2D, pas besoin d'artillerie lourde...

[H3dy]

madko,

si je peux utiliser le driver opensource mit à disposition, c'est good!

je voullais notamment connaitre la différence entre le driver générique d'openBSD et celui d'ATI? (correctif de bug, améliorations, ect..)

Je refuse de mettre en oeuvre un kernel en standby (si je peux éviter les complications ca m'arrange!)

et comment je fais pour vérifier en ligne de commande le fichier /var/log/Xorg.0.log?

[madko]

ah oui merci Aefron pour ton explication jcomprend un peu mieux qu'il soit reticent vis a vis de DRM/DRI, vu comme ça. Parceque etre contre le concept là ça me paraissait bizare

Par contre H3dy ça doit etre l'heure tardive mais je comprend rien a ce que tu dis, je savais pas qu'ATI faisait des pilotes pour OpenBSD

[Compte_supprime_74291]

Le driver radeon dont on parle est le driver développé par freedesktop (ceux qui font X.org): il marche bien sur les radeon jusqu'au R400 (<= X850, excepté pour certaines cartes aux bios trafiqués par certains assembleurs de cartes, et pour certaines mobility qui sont en fait des R500 renommés en X300 ou X600... le support des R500 arrive ceci dit bientôt et semble déjà basiquement fonctionnel en 2D pour la version CVS)... il te permet: grandes résolutions (4096x4096 pour les cartes à partir du R300, 2048x2048 pour les R200), multi-écran en pseudo-xinerama sur un seul buffer mémoire (mergedfb... beaucoup beaucoup plus rapide que xinerama... mais je ne l'ai pas testé sous OpenBSD), la sortie Xv (pour les videos), double buffering (par contre, sans dri, j'ai eu un peu de mal avec) et des choses du genres... il marche aussi en 3D, mais pour ça, il faut dri/drm (donc, a priori, pas sous OpenBSD)...

Pour le driver proprio, à voir... il faudrait déjà porter les librairies dri dans l'OS et les modules dans le kernel OpenBSD, puis, voir si le driver passe (il est censé fonctionner sous FreeBSD, mais bon... déjà qu'un upgrade de kernel le casse souvent... alors un changement de branche de kernel, n'en parlons pas)... et puis c'est un blob... sous OpenBSD, en plus... hérétique! ... m'enfin, vu la bouse lambinante et hautement explosive qu'est fglrx, et étant donné que ta carte est supportée par le driver libre et que tu n'auras de tout façon très probablement pas de 3D acélérée en hard sous OpenBSD...

[H3dy]

madko,

ATI réalise bien des pilotes pour linux...

[H3dy]

Aefron ,

j'utiliserai le driver RADEON dont tu parles si cela fonctionne...Et comment puis-je savoir si ma carte graphique (vidéo) est traffiqué? ont'ils le droit de proposer des fakes?

j'en conclu donc pas de compiz fusion sans DRM/DRI...

je n'aurai pas besoin d'accélaration 3D (OpenGL)

[Compte_supprime_74291]

ATI réalise bien des pilotes pour linux...

Bah oui... mais c'est un blob... avec tout ce que ça implique: cassage de la compatibilité dès que les API bougent (bon, tu me diras, sous OpenBSD, en général, c'est infiniment plus stable que sous linux... mais vu comme Theo parle des blobs, ce n'est pas demain la veille qu'ils se feront des bisous ati et lui ), pas de compatiblité inter-architecture, impossibilité d'adapter comme on veut...

... déjà sous linux, le fonctionnement de fglrx est très limité... alors, penser à l'adapter ailleurs, quand on ne connaît pas le code source et qu'on ne peut pas le recompiler, et qu'en plus, on parle d'un os sans dri... ouch...

Aefron ,

j'utiliserai le driver RADEON dont tu parles si cela fonctionne...Et comment puis-je savoir si ma carte graphique (vidéo) est traffiqué? ont'ils le droit de proposer des fakes?

j'en conclu donc pas de compiz fusion sans DRM/DRI...

je n'aurai pas besoin d'accélaration 3D (OpenGL)

Poste-nous ton xorg.conf... m'enfin, si tu as déjà trifouillé ce fichier, ce n'est vraiment pas dur... tu as sûrement une section screen (éventuellement appelée par une section serverlayout), qui fait mention d'un "device"... va dans la section device correspondante, et remplace le probable "vesa" par "radeon"... à moins qu'il n'y ait des couilles évidentes sur ce fichier et/ou que tu n'aies pas les droits pour exécuter X, ça devrait aller... gaffe aux lcd... des fois, ils ne supportent pas les résolutions par défaut trop basses...

... bon, d'un autre côté, même avec une carte non supportée par un driver correct, ça devrait au moins marcher avec vesa... donc il doit y avoir un autre problème quelque part...

Sinon, je plussoie Madko... le /var/log/Xorg.0.log est une mine d'informations...

Edit: plein d'edits...

[H3dy]

Aefron,

donc je ne peux pas utiliser ati-driver-installer-8.40.4-x86.x86_64.run...

je suis sur mon PC portable avec un liveCD qui dessus est installer OpenBSD 4.1 (sur le HDD), c'est la seule manière pour moi de communiquer avec vous.

par file manager j'ai été dans /ect/X11/XF86Config à partir du liveCD? est ce le bon?

Section "ServerLayout"
Identifier	 "Layout0"
Screen	  0  "Screen0" 0 0
InputDevice	"Keyboard0" "CoreKeyboard"
InputDevice	"Mouse0" "CorePointer"
EndSection

Section "Files"
	RgbPath	  "/usr/X11R6/lib/X11/rgb"
	ModulePath   "/usr/X11R6/lib/modules"
	FontPath	 "/usr/X11R6/lib/X11/fonts/misc/"
	FontPath	 "/usr/X11R6/lib/X11/fonts/Type1/"
	FontPath	 "/usr/X11R6/lib/X11/fonts/75dpi/"
	FontPath	 "/usr/X11R6/lib/X11/fonts/100dpi/"
	FontPath	 "/usr/X11R6/lib/X11/fonts/bitstream-vera/"
EndSection

Section "Module"
Load  "extmod"
EndSection

Section "InputDevice"
Identifier  "Mouse0"
Driver	  "mouse"
Option		"Protocol" "Auto"
Option		"Device" "/dev/sysmouse"
Option	  "ZAxisMapping" "4 5"
EndSection

Section "InputDevice"
Identifier  "Keyboard0"
Driver	  "keyboard"
Option		"XkbModel" "pc105"
Option	  "XkbLayout" "fr"
EndSection

Section "Monitor"
Identifier   "Monitor0"
HorizSync	31.5 - 48.5
VertRefresh  50.0 - 90.0
EndSection

Section "Device"
Identifier  "Card0"
Driver	  "vesa"
EndSection

Section "Screen"
Identifier "Screen0"
Device	 "Card0"
Monitor	"Monitor0"
DefaultDepth	 16
SubSection "Display"
	   Depth 16
		Modes	"1024x768"
EndSubSection
EndSection

[Compte_supprime_74291]

donc je ne peux pas utiliser ati-driver-installer-8.40.4-x86.x86_64.run...

Ah, bah, pour faire une cartmanerie, ça me trouerait le fondement

... à la limite, copie ton xorg.conf (apparemment /root/xorg.conf.new... qui ne doit être qu'un fichier de test... le vrai qui est utilisé quand tu fais un bête startx ou gdm doit être quelque part dans /etc... bien que je ne me rappelle plus exactement d'où c'est sur OpenBSD) sur une clé usb ou google du "man xorg.conf" et "man radeon", et envoie-en le contenu sur le forum, et on essaiera de te suggérer des manières de le changer pour que ça passe... enfin, demain... parce que là, je tombe... bonne nuit et bonne chance si tu continues ce soir...

Edit: et en changeant

Section "Device"
Identifier  "Card0"
Driver	  "vesa"
EndSection

par :

Section "Device"
Identifier  "Card0"
Driver	  "radeon"
EndSection

?

Sinon, essaie en changeant les profondeurs de couleurs de 16 à 24... voire en commentant les fréquences de rafraîchissement (HorizSync et VertRefresh) mais sinon, il me paraît propre (enfin, en tout cas, il semble que ce soit celui utilisé quand tu fais un startx, mais il est différent de celui qui sera utilisé si tu fais un "X -config /root/xorg.conf.new"... ou si tu veux absolument essayer X-config avec celui-là, fais un "X-config /etc/X11/XF86Config")...

[H3dy]

A partir du livecd dans /root/ je n'ai pas "xorg.conf.new"

[Compte_supprime_74291]

Bon, sinon, le fichier xF86Config me paraît bizarre, quand même... enfin, surtout son nom... il me semble que le fichier lancé par un startx devrait être /etc/X11/xorg.conf sous OpenBSD (comme dans plein d'autres endroits)...

Sinon, c'est tout autant bizarre que tu n'aies pas de /root/xorg.conf.new ... tu as bien lancé X -configure en tant que root?

Autrement, je suis tombé sur Configurer X sur i386 et amd64... apparemment, /root/xorg.conf.new sert bien à tester si un nouveau xorg.conf marche sans devoir écraser le /etc/X11/xorg.conf (qu'il ne faut écraser qu'une fois que tu as la mire et plus l'écran noir avec "X -configure")... ils recommandent aussi de changer la profondeur de couleurs, la résolution et les rafraîchissements, comme je te l'ai dit (et essaie aussi avec le driver radeon plutôt que vesa, ce ne sera pas du luxe)...

En espérant être assez clair (X.org relève quand même souvent de l'incantation vaudou )...

[H3dy]

j'ai tester en changant "vesa" par "radeon", c'est celui du livecd puisque même après un saving il est redevu "vesa" suivi d'un reboot!

sinon en mode root j'ai ceci sans le liveCD:

#startfluxbox
Abort trap (core dumped)
Error: Coulndn't connect to XServer

je n'ai accès qu'au liveCD et à mes phériphériques externe en faite...

[madko]

normalement ta section correspondant a ta carte video doit ressembler à ça:

Section "Device"
    Identifier     "Videocard0"
    Driver     "radeon"
    VendorName     "Videocard vendor"
    BoardName     "ATI Technologies Inc Radeon Mobility X700 (PCIE)"
    Option     "MonitorLayout" "LVDS, NONE"
EndSection

Apres c'est pas la peine de vouloir lancer fluxbox si tu n'a pas X qui tourne.

[H3dy]

#cp xorg.conf.new /ect/X11/xorg.conf
cp: /etc/X11/xorg.conf: No such file or directory

#xrandr
Can't open display (null)

#xdpyinfo
xdpyinfo: unable to open display " ".

Comment je fais pour jeter un coup d'oeil sur le fichier /etc/X11/xorg.conf?

[madko]

vi /etc/X11/xorg.conf

man vi (ou alors cherche un tuto sur le net, si tu connais pas vi)

mais attention, t'a tapé /ext c'est pour ça qu'il veut pas le copier (vu que le chemin c'est /etc)

mais bon pas besoin de le copier pour le tester X -config <ton fichier> ça revient au meme