Vous n'êtes pas identifié(e).
Installé le paquet DKMS depuis Synaptic. Puis :
Jusque là, ça va.
Mais si j'appelle Applications -> Système -> Paramètres du serveur X NVIDIA, j'arrive là :
Et si je saisi la commande que me suggère le message du serveur nvidia, puis reboot, plantage systématique et restauration Acronis indispensable. Plus de redémarrage.
Où est-ce que je me plante ?
Merci :hello:
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Donc, tu ne dois surtout pas installer un driver Nvidia. Il faut tout désinstaller de ce qui concerne Nvidia. Si c’est trop compliqué, tu peux carrément refaire ton installation de Debian pour repartir sur un GNU/Linux propre.
En revanche, tu peux installer le firmware pour les cartes ATI, voir si ça va ainsi. Il n’est pas toujours nécessaire d’installer en plus le driver proprio de AMD. Fais quelques recherches.
Dernière modification par gnulux (24-08-2017 10:31:33)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Hors ligne
et reboot
tout doit etre correct
pour purger le driver nvidia (sans tout réinstaller )
puis
puis
puis pour prendre en compte la modification
donc dans l ordre tu installe le firmware puis tu purge le driver nvidia au reboot du pc tout doit etre bon
nota : si tu a créé un fichier xorg.conf il faut le supprimer avant de reboot (dans /etc/X11/xorg.conf ou dans /etc/X11/xorg.conf.d/monfichier.conf )
ps : "monfichier" a remplacer par le nom que tu lui a donné
Dernière modification par anonyme (24-08-2017 12:21:46)
Hors ligne
Hors ligne
il faut compléter son profil sur le forum pour savoir quelle debian tu a (jessie 8 , stretch 9 etc .... ) et le bureau utilisé (avec son lanceur )
Comment fait-on quand on a plusieurs machines, versions de Debian, environnements de bureau ?
En quoi le lanceur est-il important ?
Dernière modification par raleur (24-08-2017 14:54:17)
Il vaut mieux montrer que raconter.
Hors ligne
Il est même fortement déconseillé d'installer le pilote propriétaire ATI/AMD fglrx.
Merci raleur, de cette précision, c’est une bonne nouvelle.
anonyme, merci pour tes instructions très claires (#6). Juste que le paquet firmware-amd-graphics est disponible dans le dépôt backports de Jessie mais Jessie ne concerne pas Lupa. La doc de wiki.debian.org en anglais est plus à jour que celle en français, comme souvent.
Hors ligne
firmware-linux-nonfree et xserver-xorg-vidéo-ati et libgl1-mesa-dri vont installer ce qu il faut sur jessie et stretch
juste je préfère utiliser les noms des paquets nécessaires dans la commande mais c'est pas vital , la commande ci dessus fonctionne trés bien
sur une installation neuve , a part le firmware amd tout est déja installé
pour le vérifier une simulation (avec l option -s )
ceci suffit
et pour n'installer que ce qui est nécessaire ceci est mieux (pour stretch )
pour éviter une confusion pour la 3D
le noyau initialise les DRM pour le matériel
Mesa initialise la 3D (mesa a besoin que le matériel soit correctement détecté par le noyau pour fonctionner correctement )
Dernière modification par anonyme (25-08-2017 08:25:55)
Hors ligne
ce paquet est un meta-package qui va installer des dépendances ( pas toutes utiles )
le paquet qui est utile pour le gpu amd est celui ci
qui est une des dépendances du méta-paquet firmware-linux-nonfree
je sais pas si je suis très clair
nota : le paquet firmware-amd-graphics doit supporter toutes les cartes AMD , récentes ou anciennes .
la description des paquets va peut etre t'aider a comprendre la nuance
le méta-paquet => https://packages.debian.org/stretch/fir … ux-nonfree
le firmware amd ( tu a la liste des cartes supportées )=> https://packages.debian.org/stretch/fir … d-graphics
Dernière modification par anonyme (25-08-2017 10:16:50)
le lanceur c'est lui qui lance le serveur X , selon que se soit gdm3 ou lightdm
C'est la première fois que je vois gdm ou lightdm appelés "lanceurs". Habituellement on les appelle plutôt gestionnaires de session ou de connexion ("display manager" en anglais, d'où la terminaison en "dm"). Pour moi, un lanceur est plutôt un lanceur d'application à l'intérieur du bureau.
avec plusieurs machines on indique la configuration qui correspond a la question posé tout simplement , le profil est pas statique
Je ne trouve pas cela très pratique. Si le profil évolue et ne correspond plus au sujet, quelqu'un qui lirait la discussion après coup n'y comprendra rien.
Et comment fait-on pour ouvrir deux discussions à propos de deux machines/distributions/versions/GUI différentes ?
Franchement, je pense qu'il est préférable d'indiquer ces éléments dans chaque discussion quand ils sont nécessaires.
Si je comprends bien, le paquet firmware-amd-graphics est inutile pour des cartes AMD anciennes (genre ATI RV 380 Radeon X600)? Ceci (firmware-linux-nonfree) doit suffire?
Les firmwares Radeon non libres sont nécessaires avec tous les GPU Radeon à partir de la série HD 2000 pour que le KMS fonctionne, et probablement bien avant (y compris pour X600) pour que l'accélération 3D fonctionne.
Jusqu'à Jessie, ces firmwares étaient inclus dans le paquet firmware-linux-nonfree. Comme ils commençaient à être volumineux par rapport aux autres firmwares inclus dans le paquet, à partir de Stretch (et donc Jessie-backports) ils ont été déportés dans un paquet spécifique, firmware-amd-graphics. Le paquet firmware-Linux-non-free depend de ce paquet et d'un autre paquet qui contient les autres firmwares non libres. Ainsi en l'installant on aura toujours les firmwares Radeon, mais pas seulement. Si on a besoin des autres firmwares non libres mais pas des firmwares Radeon, on peut installer seulement l'autre paquet (dont j'ai oublié le nom).
Dernière modification par raleur (25-08-2017 14:49:19)
Il vaut mieux montrer que raconter.
Hors ligne
les ressources du gpu ne sont pas les meme
Dernière modification par anonyme (25-08-2017 15:10:01)
l'accélération 3D n'a rien a voir avec le firmware
Possible, je n'en sais rien, mais j'observe que sans firmware, les pilotes Radeon n'ont pas d'accélération 3D.
le firmware met a jour le noyau
Pas du tout. Un firmware est chargé directement sur le périphérique.
KMS n'est pas une obligation
Pourtant, avec les pilotes Radeon, pas de KMS = pas d'accélération matérielle.
tant que les constructeurs ne libéreront pas le code pour leur cartes graphiques , le firmware sera indispensable pour la partie nonfree
Rien à voir. Que le code (quel code ?) soit libéré ou pas, un firmware sera toujours indispensable avec ces GPU parce qu'ils sont conçus ainsi. Le firmware, c'est le programme du GPU. Sans programme, il (du moins certaines de ces fonctionnalités) ne fonctionne pas.
Mesa est en libre ce qu'est OpenGL pour le nonfree
Pas du tout. OpenGL est une spécification d'API, et Mesa est une implémentation libre d'OpenGL.
Il vaut mieux montrer que raconter.
Hors ligne
je me demande pourquoi je discute
Pour échanger du savoir, comme moi ?
le pilote propriétaire fonctionne sans KMS (désactivé ) , nouveau aussi , intel aussi avec le serveur X
Je parlais uniquement du pilote libre radeon, pas du pilote propriétaire, nouveau ni intel.
je suis certain que les anciennes cartes tournent trés bien sans
Testé avec le GPU Radeon X300 Mobility de mon portable :
Sans KMS (radeon.modeset=0), pas de framebuffer haute résolution en console, performances 3D basses ("AIGLX reverting to software rendering")
un matériel a toujours besoin d un bout de programme pour fonctionner , une carte graphique aussi
Non, pas toujours. Certains périphériques simples n'ont pas de firmware. Je te garantis que les cartes VGA d'origine n'en avaient pas, c'est le logiciel du système hôte qui faisait tout.
les .bin du firmware servent a mettre a jour les informations du dit matériel . (qui ne peut etre intégré a debian parce que nonlibre ) et mit a disposition de l'utilisateur pour lui permettre d'utiliser son matériel quand meme.
Je ne vois pas ce que tu veux dire par "mettre à jour les informations du dit matériel". Un firmware, c'est un programme qui est chargé et s'exécute sur le périphérique. C'est différent d'un pilote qui est un programme qui s'exécute sur le processeur du système hôte pour communiquer avec le périphérique.
Le fait d'être libre ou non libre ne change rien à la nature ni au rôle d'un firmware. Il existe des firmwares libres, par exemple dans le paquet firmware-linux-free.
Il vaut mieux montrer que raconter.
Hors ligne
saque eud dun (patois chtimi : fonce dedans)
Hors ligne
pour KMS et AMD on est d'accord qu il est est conseillé de laisser KMS actif pour une meilleure prise en charge
C'est pire que ça : à partir de la série Radeon HD 2000 (c'est déjà très vieux), KMS est obligatoire pour les pilotes radeon.
Je viens de vérifier expérimentalement avec le Radeon HD 2400 : avec nomodeset ou radeon.modeset=0, le module radeon du noyau ne se charge pas et le pilote radeon de X.org non plus, au final c'est le pilote générique VESA qui est utilisé.
nota : la carte du dessus a été testé avec KMS uniquement et avec KMS + le paquet amdgpu (dans le second cas le résultat est meilleur , mais les deux fonctionnent )
Comment ça, avec KMS uniquement ? KMS n'est qu'une fonctionnalité du noyau, pas un pilote graphique.
Est-ce que tu ne serais pas en train de parler du pilote modesetting de X.org ? Si c'est bien le cas, merci de l'appeler par son vrai nom et pas KMS qui désigne autre chose : Kernel Mode-Setting, gestion des modes graphiques par le noyau, fonctionnalité apportée par les modules graphiques du noyau et utilisée par les pilotes graphiques de X.org.
De toute façon c'est hors sujet car le pilote amdgpu est pour des GPU beaucoup plus récents que le Radeon HD 5000 dont il est question dans ce sujet.
toutes les cartes graphiques ont un bios (maintenant un firmware UEFI ) meme les plus simples.
Le firmware BIOS/EFI d'une carte graphique est exécuté par le processeur du système hôte. C'est complètement différent d'un firmware exécuté par le GPU dont il est question ici.
la notion de lag reste subjectif selon la personne et les logiciels utilisées
Je n'ai pas constaté le moindre lag lors de la manipulation des fenêtres.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par anonyme (27-08-2017 12:22:23)
tu désinstalle tous les paquets relatif a AMD (xserver-xorg-video-ati radeon et amdgpu )
Au passage ça désinstalle divers méta-paquets jusqu'à task-desktop qui en dépendent, mais admettons.
KMS va généré un paquet virtuel xserver-xorg-video-radeon qui n'est pas le meme que le paquet physique radeon
Quand tu écris "KMS", de quoi parles-tu exactement ? Je t'ai posé la question plusieurs fois, mais tu n'as jamais répondu, entretenant l'ambiguïté.
Est-ce la fonctionnalité "kernel mode setting" du noyau ?
Est-ce le pilote "modesetting" de X.org ?
Est-ce autre chose ? Car je ne vois pas comment l'un ou l'autre pourrait "générer un paquet virtuel", ce qui nécessite d'interagir avec le système de paquetages de Debian.
si tu teste gnome sur buster
Ce que tu écris plus haut n'est valable qu'à partir de Buster ou bien déjà dans Stretch ?
pour KDE je pense qu il va tourner avec gnome
Pardon ? KDE va tourner avec Gnome ? Qu'est-ce que ça veut dire ? Tu veux dire avec Wayland ?
a partir de Stretch , le paquet modesetting (.so il me semble ) est un paquet virtuel
Il n'y a pas de paquet modesetting ni modesetting.so, réel ou virtuel.
Puisque tu n'arrives pas à être précis, je vais l'être.
modesetting_drv.so est le pilote modesetting de X.org. Jusqu'à Jessie, il était installé par le paquet xserver-xorg-video-modesetting. Depuis Stretch, il est inclus dans le paquet xserver-xorg-core, et le paquet xserver-xorg-video-modesetting est devenu un paquet virtuel fourni par le paquet xserver-xorg-core.
Il vaut mieux montrer que raconter.
Hors ligne
les DRM
je vais tester sans paquet AMD/ATI
Dernière modification par anonyme (27-08-2017 13:02:05)
pour le reste c'est ce que tu a écrit a la fin (tu l'avais déja expliqué ) comment est généré le paquet virtuel modesetting (la description des paquets donnent l'information )
Le paquet virtuel xserver-xorg-video-modesetting de Stretch et suivantes n'est pas généré (par KMS ni quoi que ce soit, et encore moins lors de la désinstallation des autres paquets xserver-xorg-video-*). Il préexiste dans la liste de paquets d'APT en tant que paquet virtuel parce qu'il est fourni (en-tête "Provides") par le paquet xserver-xorg-core.
Du coup, je n'ai pas besoin de désinstaller xserver-xorg-video-radeon et compagnie pour espérer assister à cette miraculeuse génération de paquet virtuel. Ouf.
quand je parle de KMS , c'est en fonction de la version du noyau , c'est un vilain raccourci
C'est bien ce que je te reproche. Essaie d'être plus précis, plus clair.
Et sinon, aurai-je enfin une réponse à ma question : "qu'entends-tu exactement par KMS" ? Et j'ajoute : en quoi cela dépend-il de la version du noyau ?
par contre a partir de grub je n'arrive plus a désactiver modesetting (modeset=0 ou nomodeset=1 ) sur la petite machine avec une carte ATI agp
"modeset=0" ne marche pas en tant que paramètre global, seulement pour un module donné : par exemple radeon.modeset=0.
"nomodeset" (pas besoin d'ajouter "=1") devrait fonctionner, sauf si le paramètre "modeset" du module a été forcé à 1.
je vais tester sans paquet AMD/ATI
Tout ceci étant dans le noyau, la présence des pilotes X.org n'a aucune influence sur l'activation du KMS.
Dernière modification par raleur (27-08-2017 13:54:37)
Il vaut mieux montrer que raconter.
Hors ligne