> Tous les forums > Forum Linux
 Archlinux - noyau 3.7.5.1 - driver nouveauSujet résolu
Ajouter un message à la discussion
Page : [1] 
Page 1 sur 1
Mimile
  Posté le 04/02/2013 @ 15:40 
Aller en bas de la page 
Astucien

Bonjour,

J'ouvre ce sujet car j'étais intervenu dans un poste qui concernait un autre problème et je souhaiterais mettre à plat ce que j'ai trouvé.

Résumé : Sous Archlinux, jusq'au noyau 3.6.11-1, tout allait bien. Lors du passage au noyau 3.7.4, mes ennuis ont commencé : au démarrage, écran noir avec un message au mileu de mon écran disant "hors de portée", suggérant donc un problème de résolution.

Diverses solutions m'ont été proposées en relation avec cette supputation (merci Paul) mais sans résultat.

Finalement, j'ai contourné le problème de deux manières :

1°) en installant le noyau linux-lts (long time support) 3.0.6 (sur le fallback)

2°) en downgradant mon noyau 3.7.4 vers le 3.6.11-1

Ces manip m'ont permis de retrouver ma Arch mais ne me satisfont qu'à moitié (combien de temps avant une incompatibilité avec un nouveau paquets ?). je me suis mis à la recherche d'une solution propre.

J'ai tout d'abord appris qu'il y avait un bug qui faisait que le driver "nouveau" que j'utilise sur mon vieux PC ne fonctionnait pas avec les noyau 3.7.nnn.

A force de recherches, j'ai vu que je n'étais pas le seul dans ce cas et qu'une solution possible était d'ajouter une option au module "nouveau" (dans /etc/modprobe.d/modprobe.conf appelé par mkinitcpio.conf), savoir : options nouveau config=NvPCIE=0

Après réinstallation du noyau 3.7. (passé du 3.7.4 au 3.7.5 dans l'intervalle), j'ai lancé Arch et j'ai enfin vu défiler toutes les lignes du boot jusqu'à la dernière (reaching graphical interface) puis plus rien ...

La raison en est qu'au tout début du boot, il y a un message : nouveau: unknown parameter NvPCIE

Le point positif est qu'on peut en déduire que ce n'est pas une question de résolution d'écran qui est en cause et cela confirme que c'est bien le driver "nouveau" qui n'est pas adapté au nouveau noyau.

Apparemment, ce paramètre ne gène que moi car tous les autres sites où il en est question se termine par "résolu".

Au lieu de NvPCIE=0, j'ai aussi essayé "nomodeset" (même résultat : unknown paramater), modeset=0 et modeset=1 et avec ces deux derniers, écran noir et le message "hors de portée".

Je ne sais vraiment plus quelle option il faut passer à "nouveau" pour qu'il s'intègre au nouveau noyau.

Si quelqu'un avait une idée ...

Merci d'avance.

Cordialement,

Publicité
Logicien
 Posté le 04/02/2013 à 17:27 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

Salut Mimile,

je vois que tu progresses. Si Xorg ne démarre pas cela n'est pas nécessairement dû au pilote nouveau du noyau Linux.

Tu peux essayer de fixer la résolution en passant le paramètre video=1024x768 ou tout autre résolution native au noyau Linux. Confirmé par Kernel mode setting or X sets a bad or non-native display mode .

Les paramètres des modules ne sont pas très bien documentés surtout lorsqu'il est question de passer une 'string'. Tu peux quand même voir les paramètres après démarrage par la commande

more /sys/module/nouveau/parameters/*

Peut-être que la chaîne de caractères pour l'option config y est écrite et que tu peux l'utiliser. J'ai lu un de tes messages sur le forum archlinux.fr et on te suggère

options nouveau NvPCIE=0

Je doute que cela fonctionne, mais tu peux essayer.

En ce qui concerne nomodeset , cette option ne te permettra pas d'utiliser le pilote nouveau avec Xorg je crois. À utiliser en dernier recours. Tu est mieux d'utiliser le paramètre nouveau.modeset=0 sur la ligne du noyau ou ajouter modeset=0 dans /etc/modprobe.d/modprobe.conf aux autres options pour le module nouveau et refaire ton initramfs.

Voici les paramètres que tu peux configurer pour le module nouveau:

modinfo -p nouveau

modeset:enable driver (default: auto, 0 = disabled, 1 = enabled, 2 = headless)
noaccel:disable kernel/abi16 acceleration
debug:debug string to pass to driver core
config:option string to pass to driver core
vram_pushbuf:Create DMA push buffers in VRAM
agpmode:AGP mode (0 to disable AGP)
nofbaccel:Disable fbcon acceleration
duallink:Allow dual-link TMDS (default: enabled)
ignorelid:Ignore ACPI lid status
tv_disable:Disable TV-out detection
tv_norm:Default TV norm.
Supported: PAL, PAL-M, PAL-N, PAL-Nc, NTSC-M, NTSC-J,
hd480i, hd480p, hd576i, hd576p, hd720p, hd1080i.
Default: PAL
*NOTE* Ignored for cards with external TV encoders.
perflvl_wr:Allow perflvl changes (warning: dangerous!)
perflvl:Performance level (default: boot)



Modifié par Logicien le 05/02/2013 09:52
IceF0x
 Posté le 07/02/2013 à 06:05 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
Petit astucien

De mon coté aucun souci avec mon kernel

[icef0x@arch ~]$ uname -r
3.7.4-1-pae

Mimile
 Posté le 07/02/2013 à 09:56 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

Bonjour

@ Paul : j'ai essayé à peu près tout ce que tu indiques et je dois avouer qu'à force de faire des essais tous azimuts, je m'y perds.

Ce que je peux dire, c'est que nomodeset est déclaré unknomn parameter

modeset=0 ne signale rien, le boot se poursuit mais coince à la dernière ligne (reaching graphical target)

modeset=1 provoque l'extinction de l'écran avec le message "hors de portée"

Quand je passe l'option nouveau config=NvPCIE0=0 (on m'avait d'abord indiqué nouveau NvPCIE=0, rectifié ensuite), j'ai aussi un "unknown parameter"

Quand j'ouvre une console TTY, j'essaye - à tout hasard - startx qui au bout d'une vingtaine de lignes de protestations finit par me dire "no screen found."

Sur ton conseil, j'ai exécuté modinfo -p nouveau qui donne :

[okapi@Archibald ~]$ modinfo -p nouveau
agpmode:AGP mode (0 to disable AGP) (int)
modeset:Enable kernel modesetting (int)
vbios:Override default VBIOS location (charp)
vram_pushbuf:Force DMA push buffers to be in VRAM (int)
vram_notify:Force DMA notifiers to be in VRAM (int)
vram_type:Override detected VRAM type (charp)
duallink:Allow dual-link TMDS (>=GeForce 8) (int)
uscript_lvds:LVDS output script table ID (>=GeForce 8) (int)
uscript_tmds:TMDS output script table ID (>=GeForce 8) (int)
ignorelid:Ignore ACPI lid status (int)
noaccel:Disable all acceleration (int)
nofbaccel:Disable fbcon acceleration (int)
force_post:Force POST (int)
override_conntype:Ignore DCB connector type (int)
tv_disable:Disable TV-out detection (int)
tv_norm:Default TV norm.
Supported: PAL, PAL-M, PAL-N, PAL-Nc, NTSC-M, NTSC-J,
hd480i, hd480p, hd576i, hd576p, hd720p, hd1080i.
Default: PAL
*NOTE* Ignored for cards with external TV encoders. (charp)
reg_debug:Register access debug bitmask:
0x1 mc, 0x2 video, 0x4 fb, 0x8 extdev,
0x10 crtc, 0x20 ramdac, 0x40 vgacrtc, 0x80 rmvio,
0x100 vgaattr, 0x200 EVO (G80+) (int)
perflvl:Performance level (default: boot) (charp)
perflvl_wr:Allow perflvl changes (warning: dangerous!) (int)
msi:Enable MSI (default: off) (int)
ctxfw:Use external HUB/GPC ucode (fermi) (int)
mxmdcb:Santise DCB table according to MXM-SIS (int)
[okapi@Archibald ~]$

Je ne vois pas trop quel paramètre passer à nouveau pour résoudre mon problème

Pour le surplus, je te cite :

je vois que tu progresses. Si Xorg ne démarre pas cela n'est pas nécessairement dû au pilote nouveau du noyau Linux.

Tu peux essayer de fixer la résolution en passant le paramètre video=1024x768 ou tout autre résolution native au noyau Linux

1024x768 correspond effectivement à la résolution de mon écran, mais elle est déjà définie dans 10-monitor.conf

[okapi@Archibald xorg.conf.d]$ cat 10-monitor.conf
Section "Monitor"
Identifier "Monitor0"
EndSection

Section "Device"
Identifier "Device0"
Driver "nouveau"
EndSection

Section "Screen"
Identifier "Screen0"
Device "Device0"
Monitor "Monitor0"
DefaultDepth 24
SubSection "Display"
Depth 24
Modes "1024x768_60"
EndSubSection
EndSection

Si ça ne suffit, pourrais-tu expliquer comment [passer] le paramètre video=1024x768 ou tout autre résolution native au noyau Linux

Merci d'avance.

@ Icefox : je suis bien content pour toi mais j'ai essayé avec le noyau 3.7.4-1-ARCH puis avec le 3.7.5. sans résultat.

Pour pouvoir malgré tout utiliser ARCH, J'ai installé le noyau LTS (3.0.6) sur le fallback et, sur l'image principale, j'ai downgrader le noyau à la version 3.6.11-1 qui ne me posait pas de problème (en ajoutant "linux" à la ligne IgnorePkg de pacman.conf pour éviter qu'à la prochaine mise à jour, je me retrouve avec le noyau 3.7.5 (ou +) qui générera le problème auquel je suis confronté.

Amicalement,

Logicien
 Posté le 09/02/2013 à 04:38 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

C'est normal que tu t'y perdes Mimile. Il y a les pilotes graphiques du noyau Linux (vesafb, nvdiafb et nouveau) et ceux de Xorg, libres (fbdev, vesa, modesetting, nv et nouveau) et le pilote propriétaire (nvidia) pour ta carte Nvidia.

Quand je parle du paramètre video=1024x768 , c'est un paramètre graphique du noyau Linux et non pas un paramètre pour le pilote de l'interface graphique Xorg. Ce paramètre doit être passé sur la ligne du noyau Linux à l'aide de Grub.

Un exemple à adapter à ta partition racine pour Grub et Linux (paramètres en rouge), en y ajoutant sur la même ligne les autres paramètres du noyau Linux dans /etc/grub.d/40_custom

menuentry "ArchLinux" {
set root=(hd0,3)
linux /boot/vmlinuz-linux root=/dev/sda3 video=1024x768
initrd /boot/initramfs-linux.img
}

Suivi de

grub-mkconfig -o /boot/grub/grub.cfg

Pour le détail, si tu passes l'option nouveau.modedeset=0 ou nomodeset sur la ligne du noyau Linux, cela désactive le pilote nouveau du noyau Linux. Cela a comme conséquence que c'est le pilote vesafb du noyau Linux qui pilotera la carte graphique et que tu ne pourras pas utiliser le pilote nouveau d'Xorg, puisque celui-ci dépend du pilote nouveau du noyau Linux pour fonctionner.

La solution passe d'abord par un fonctionnement correct du pilote nouveau du noyau Linux qui utilise KMS (Kernel Mode Setting) par défaut, comme si tu lui passais le paramètre nouveau.modeset=1 . Pour cela, tu dois passer au noyau Linux les bons paramètres d'affichage (video=1024x768).

Après quoi, tu devrais pouvoir utiliser le pilote nouveau d'Xorg. Le pilote modesetting d'Xorg peut aussi fonctionner avec KMS, alors que le pilote fbdev d'Xorg fonctionne avec tout framebuffer du noyau Linux (vesafb et nouveau par exemples).

S'il n'est pas possibile d'utiliser sans problème le pilote nouveau du noyau linux avec le pilote nouveau d'Xorg, alors, il faut désactiver le pilote nouveau du noyau Linux par nouveau.modeset=0 et te tourner vers le pilote nv d'Xorg pour avoir l'affichage graphique 2D seulement, puisque tu as dit que le pilote propriétaire Nvidia ne fonctionne pas avec ta carte graphique.

Ce qui est compliqué à comprendre, c'est la panoplie de pilotes disponibles du noyau Linux et d'Xorg pour ta carte graphique et la relation entre tous ces pilotes. Si tout ça est encore du chinois pour toi, inutile d'aller plus loin, puisque je ne vois pas de solution simpliste à ton problème.





Modifié par Logicien le 09/02/2013 04:58
Mimile
 Posté le 09/02/2013 à 11:43 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

Bonjour Paul,

J'ai réinstallé le noyau 3.7.5 et j'ai ajouté video=1024x768 à la ligne "linux" de mon grub.cfg (généré par Squeeze) comme indiqué dans ton exemple.

Malheureusement, je me suis directement heurté à mon écran noir et la mention "hors de portée"... A tout hasard, j'ai fait un essai en indiquant 1024x768_60 mais sans plus de succès.

Il n'y a plus de pilote propriétaire adapté à ma carte nVidia et jusque là "nouveau" faisait correctement son travail (ma carte étant reprise dans la liste des cartes gérées par "nouveau").

C'est lors du passage de la version 3.6.11 à la version 3.7.4 du noyau que le problème est apparu sans que je modifie quoi que ce soit aux réglages en places.

Pour l'anecdote, sous WIn7, ma carte n'est même pas reconnue comme étant une nVidia (VGA) alors que sous XP, elle est reconnue et j'ai le driver ad hoc ; j'ai bien tenté de d'installer ce driver sous Seven mais ça n'a rien donné, au contraire ...

Heureusement que j'ai pu récupérer le paquet 3.6.11-1 ce qui m'a permis de downgrader le 3.7.4

Logicien
 Posté le 09/02/2013 à 14:55 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

Ton message d'erreur "Hors de portée" s'affiche-il bien tel que je le pense au début du démarrage, dès que tu as sélectionné l'entrée de Grub à utiliser, avant l'affichage des scripts de démarrage d'ArchLinux? Ce serait bête que ce message ne s'affiche que lorsqu'Xorg essaie de démarrer.

En attendant de trouver une solution, si elle existe, pour le pilote nouveau du noyau, tu peux essayer le pilote vesafb qui lui fait toujours bien son travail côté noyau. Des paramètres tels

menuentry "ArchLinux" {
set root=(hd0,3)
linux /boot/vmlinuz-linux root=/dev/sda3 nouveau.modeset=0 vga=0x318 video=vesafb
initrd /boot/initramfs-linux.img
}

devraient te donner une console utilisable. Tu devras toutefois utiliser un autre pilote que nouveau côté Xorg. Les pilotes fbdev, vesa et nv devraient fonctionner sous X. Je t'ai expliqué comment forcer l'utilisation d'un pilote sous X.



Modifié par Logicien le 09/02/2013 15:05
Mimile
 Posté le 12/02/2013 à 10:08 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

Logicien a écrit :

Ton message d'erreur "Hors de portée" s'affiche-il bien tel que je le pense au début du démarrage, dès que tu as sélectionné l'entrée de Grub à utiliser, avant l'affichage des scripts de démarrage d'ArchLinux? Ce serait bête que ce message ne s'affiche que lorsqu'Xorg essaie de démarrer.

Oui (désolé de réspondre avec retard mais j'ai été malade - grippe - ces derniers jours et je n'étais vraiment pas en état de faire quoi que ce soit)

Cela dit, comme tu le supposes à juste titre, j'ai - parfois - à peine le temps d'entrevoir la toute première ligne du boot qu'aussitôt l'écran passe au noir avec le message "hors de portée".

Si j'indique "modeset=0" dans modprobe.conf, je vois défilier toutes les lignes du boot, mais arrivé à la dernière (reached graphical target interface) plus rien ne se passe;

Je vais tenter ta solution et reviens dire ce qu'elle aura donné dans quelques minutes.

EDIT : me revoici.

Au boot, je vois défiler les lignes du boot comme indiqué ci-dessus avec arrêt complet à la dernière ligne.

Je peux effectivement ouvrir une console TTY, mais je ne sais quoi faire à ce niveau

EDIT : Après avoir modifié mkinitcpio.conf pour remplacer le module "nouveau" par "vesa", j'avais oublié d'exécuter le mkinitcpio -p linux.

Or, pendant l'exécution, j'ai eu un mesage d'erreur : module "vesa" not found

Pourtant, vérification faire, j'obtiens :

extra/xf86-video-vesa 2.3.2-2 (xorg-drivers xorg) [installé]
X.org vesa video driver

Je crois que je vais jeter l'éponge car cela fait au total des heures passées à essayer de résoudre ce problème sans résultat.

Je resterai sur le noyau 3.6.11-1 ou sur le LTS qui ne m'apportent aucun souci.



Modifié par Mimile le 12/02/2013 11:39
Logicien
 Posté le 12/02/2013 à 13:47 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

J'oubliais Mimile, prompt rétablissement si besoin est encore.

C'est correct d'enlever le module nouveau de ton /etc/mkinitcpio.conf et de refaire l'initramfs par mkinitcpio -p linux.

Par contre, tu n'as pas à mettre le pilote vesa dans /etc/mkinitcpio.conf puisqu'il est compilé en dur directement dans le noyau. Le module vesa n'existe pas, mais le pilote vesa prend en charge l'affichage côté Linux parce-que le module nouveau n'est pas dans l'initramfs et que le paramètre options nouveau modeset=0 est indiqué dans /etc/modprobe.d/modprobe.conf.

Il te reste à créer ou modifier un fichier tel /etc/xorg.conf.d/20-pilote-vidéo.conf avec comme lignes

Section "Device"

Identifier "Pilote vidéo d'Xorg"

driver vesa

EndSection

Cela va dire à Xorg d'utiliser le pilote vesa et non pas nouveau.

Note que le pilote nv ou fbdev va fonctionner à la place du pilote vesa. Le pilote nv me semble être le meilleur. Il suffit simplement que ces pilotes soit installés: xf86-video-vesa, xf86-video-fbdev et xf86-video-nv . Tu pourras utiliser les plus recents noyaux Linux avec ArchLinux et avoir un affichage graphique 2D côté noyau et côté Xorg.



Modifié par Logicien le 12/02/2013 16:02
Mimile
 Posté le 14/02/2013 à 16:17 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

Bonjour Paul

Merci de t"intéresser à ma petite santé ; je vais effectivement beaucoup mieux malgré le fait que sur les trois gélules d'antibiotique (à prendre une chaque matin), j'ai oublié de prendre la dernière ... ... tu parles d'un distrait ...

Cela dit, une fois de plus, tu es mon sauveur !!

J'ai fait comme tu me l'as indiqué et maintenant je peux utiliser le noyeau 3.7.6.1

J'ai choisi le driver "nv" que j'ai déjà utilisé sous d'autres OS et qui donne de bons résultats y compris lors du visionnage des vidéos.

Ce qui est bizarre, c'est que, quand j'exécute lsmod, "nv" n'apparaît nulle part et en revanche "nouveau" est présent en de nombreux endroits alors qu'a priori, il est complètement désactivé (supprimé dans mkinitcpio.conf, section MODULES) :

Module Size Used by
nouveau 810616 0
mxm_wmi 1136 1 nouveau
wmi 7196 2 mxm_wmi,nouveau
video 9932 1 nouveau
ttm 47020 1 nouveau
drm_kms_helper 29071 1 nouveau
drm 181744 3 ttm,drm_kms_helper,nouveau
i2c_algo_bit 4584 1 nouveau
snd_intel8x0 22958 2
snd_ac97_codec 90105 1 snd_intel8x0
ac97_bus 875 1 snd_ac97_codec
snd_pcm 63698 2 snd_ac97_codec,snd_intel8x0
snd_page_alloc 6039 2 snd_intel8x0,snd_pcm
snd_timer 14903 1 snd_pcm
snd 45066 8 snd_ac97_codec,snd_intel8x0,snd_timer,snd_pcm
shpchp 22294 0
forcedeth 51270 0
ppdev 6127 0
soundcore 4379 1 snd
pci_hotplug 20183 1 shpchp
nvidia_agp 4161 1
agpgart 21936 3 drm,ttm,nvidia_agp
parport_pc 26474 0
parport 26032 2 ppdev,parport_pc
i2c_amd756 4969 0
i2c_core 19184 5 drm,i2c_amd756,drm_kms_helper,i2c_algo_bit,nouveau
psmouse 76851 0
pcspkr 1456 0
evdev 7657 9
button 3718 1 nouveau
serio_raw 4066 0
processor 24552 0
reiserfs 225860 2
fuse 60511 13
ext4 409085 4
crc16 1092 1 ext4
jbd2 66480 1 ext4
mbcache 4387 1 ext4
sr_mod 13149 0
cdrom 30345 1 sr_mod
sd_mod 28499 14
ohci_hcd 23761 0
ata_generic 2435 0
pata_acpi 2400 0
pata_amd 8199 12
libata 147808 3 pata_acpi,pata_amd,ata_generic
ehci_hcd 46061 0
scsi_mod 110426 3 libata,sd_mod,sr_mod
usbcore 148406 2 ohci_hcd,ehci_hcd
usb_common 623 1 usbcore
floppy 48488 0

Mais le principal, c'est que le problème soit enfin résolu de manière propre.

Encore merci et à bientôt.

Amicalement



Modifié par Mimile le 14/02/2013 16:18
Logicien
 Posté le 14/02/2013 à 17:27 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

Heureux que cette saga soit terminée. Si tu veux y comprendre quelque chose, tu ne dois pas confondre les pilotes graphiques du noyau Linux, nouveau, vesafb et d'autres avec les pilotes graphiques d'Xorg tels nouveau (aussi), nv, vesa, fbdev et d'autres encore.

C'est certain que la commande lsmod qui liste les pilotes chargés du noyau Linux ne listera pas le pilote nv qui est un pilote d'Xorg.

Quant au pilote nouveau du noyau Linux, s'il apparaît avec la commande lsmod, c'est parce-que le noyau Linux a détecté une carte graphique comptible avec le module nouveau et l'a chargé, mais avec l'option modeset=0. Cette option permet d'utiliser un autre pilote framebuffer que nouveau tel vesafb.

Si tu tiens à ce que le pilote nouveau du noyau Linux ne se charge pas du tout, alors, tu ajoutes la ligne

install nouveau /bin/true

au fichier /etc/modprobe.d/modprobe.conf et tu refais l'initramfs (mkinitcpio -p linux). Quand viendra le temps pour le noyau de charger le pilote nouveau, il exécutera une commande factice à la place qui lui dit simplement que le module nouveau a été chargé sans erreur, ce qui est faux, mais évite les problèmes liés à une erreur de chargement du module.

La commande 'install nouveau /bin/true' met en fait le module nouveau du noyau Linux sur une liste noire (blacklist) encore plus difficile à contourner que la commande blacklist nouveau .



Modifié par Logicien le 14/02/2013 18:06
Mimile
 Posté le 15/02/2013 à 11:47 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

Merci pour ces explications complémentaires.

Je vais encore t'ennuyer mais aurais-tu une explication au fait que manifestement, le noyau 3.7.n.n. ne digère pas "nouveau" alors que les versions 3.6.n.n. et antérieures ne posaient pas de problème ?

Accessoirement, j'ai constaté ceci :

Avec le noyau 3.6.11-1 (qui ne posait aucun problème), quand je lançais glxgears, 9 fois sur 10, j'avais un message signalant en substance un manque de ressources avec retour immédiat au prompt ; parfois, les 3 roues dentées apparaissaient mais ne tournaient que de manière saccadée et très lente (une avance d'un cran toutes les une ou deux secondes).

En revanche, depuis que j'ai appliqué ta solution, donc en bridant le chargement de nouveau et en utilisant le driver nv, glxgears m'affiche maintenant les 3 roues dentées qui tournent rapidement et de manière fluide.

J'en viens à ma demander si mon problème initial ne serait pas lié à nouveau-dri qui est sensé fournir la 3D à nouveau et qui demande des ressources que mon vieux PC n'est pas (plus ?) capable de fournir.

A ton avis ?

Logicien
 Posté le 15/02/2013 à 14:52 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

Je n'ai pas beaucoup d'idées Mimile. Je n'ai jamais eu à utiliser le pilote nouveau côté noyau ni côté Xorg. Le seuls pilotes que je me souviens d'avoir utilisés pour cartes Nvidia sont nvidia (propriétaire) et nv pour Xorg.

Il est probable qu'un pilote 2D comme nv offre de meilleures performances qu'un pilote 3D comme nouveau avec des cartes graphiques anciennes. Je te donne le lien vers l'aide d'ArchLinux pour le pilote nouveau côté noyau et Xorg. Ce lien inclue un lien vers l'aide d'Xorg pour le pilote nouveau.

Nouveau - ArchWiki



Modifié par Logicien le 15/02/2013 14:56
Mimile
 Posté le 15/02/2013 à 16:35 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

Tu ne m'en voudras pas si je te dis que j'avais aussi posté sur le forum Arch pour résoudre mon problème "hors de portée".

A noter que tu es le seul à avoir trouvé la solution

Ceci dit, au cours de la conversation, on m'a renseigné ce poste (clic) dont il semble résulter que le module/pilote nouveau avait été re-travaillé ...

Il y a dès lors fort à parier que ce sont les modifications apportées qui perturbent le bon fonctionnement de "nouveau" (à tout le moins chez moi vu l'âge de ma carte graphique).

Espérons que les développeurs s'en rendront compte et rectifieront le tir.

Amicalement

Mimile

Logicien
 Posté le 16/02/2013 à 14:31 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

Utiliser le pilote framebuffer vesafb au lieu du pilote framebuffer nouveau côté noyau et utiliser le pilote 2D nv au lieu du pilote 3D nouveau côté Xorg n'est qu'une manoeuvre de contournement du problème du pilote nouveau avec ta carte graphique en général. Ce n'est pas une solution à ce problème à proprement parlé.

Il est fort possible que ton Compaq soit déjà au recyclage avant que le pilote nouveau supporte ta carte graphique. Je pense que les développeurs ont suffisamment à faire pour prendre en charge le matériel récent qui sort à tout moment sur le marché, ce qui les forcent à laisser tomber le support pour le matériel le plus ancien.

D'un autre côté, la solution existe peut-être présentement sur le Net. Si oui, je pense qu'un autre problème pourrait réapparaître tôt ou tard avec l'évolution du code du pilote nouveau. Il faut mettre son matériel à jour si on veut utiliser les technologies logicielles les plus récentes.

Mimile
 Posté le 18/02/2013 à 14:13 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

Eh oui, il est évident que les développeurs sont en permanence confrontés à l'apparition de nouveaux matériels pour lesquels ils doivent se malmener les méninges, ce qui impliquent que les matériels pré-historiques ne peuvent plus faire l'objet de leurs attentions.

Je pressens le moment où, de manière définitive, mon PC ne m'affichera plus qu'un écran noir, sauf à renoncer aux mises à jour et figer le PC dans sa dernière configuration fonctionnelle (ce que j'avais fait, somme toute, en downgradant du noyau 3.7.1 qui posait le problème "hors de portée" vers le 3.6.11-1 qui fonctionnait bien avec le pilote nouveau).

Mais évidemment, en procédant ainsi, on renonçe ipso facto à la notion de rolling release qui fait le charme d'Arch et son intérêt.

De toute façon, il viendra certainement un moment où mon PC rendra l'âme (je suis d'ailleurs assez étonné de sa longévité eu égard à l'usage intensif que j'en fait (il tourne au moins 20 heures sur 24 - il m'arrive la plupart du temps d'aller me coucher en oubliant de l'éteindre - et ce, 7 jours sur 7).

A ce moment-là, je serais bien obligé de m'acheter un nouveau PC.

Encore merci et à bientôt.

Mimile



Modifié par Mimile le 18/02/2013 14:16
Logicien
 Posté le 18/02/2013 à 18:58 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

Je n'avais pas dit Mimile que je suis quelque peu flatté d'être le seul à avoir trouvé une 'solution' à ton problème.

Ceci dit, comme ta carte graphique est compatible VESA comme la plupart des cartes graphiques, tant qu'un des pilotes vesafb, uvesafb, voir nvdiafb sera compilé côté noyau et qu'un des pilotes vesa ou fbdev sera disponible côté Xorg, tu auras à ta disposition les résolutions, profondeurs et fréquences supportés par ces pilotes.

Il faudrait que la Video Electronics Standards Association cesse 'de définir des standards vidéo et de normaliser certains composants en la matière.' pour qu'il ne te reste que des pilotes spécifiques aux cartes Nvidia comme nvidia et nouveau qui eux, ne fonctionnent présentement pas et ne devraient pas plus fonctionner avec le temps avec ta carte graphique.

Je pense qu'on a traité le message original de manière assez exhaustive.

Bonne journée.



Modifié par Logicien le 18/02/2013 19:01
Mimile
 Posté le 19/02/2013 à 13:49 
Aller en bas de la page Revenir au message précédent Revenir en haut de la page
  Astucien

Bah, du moment que vesa associé à nv fonctionnent, je suis satisfait d'autant que je me passe très bien de la 3D.

Clôturons donc ce sujet.

Amicalement

Page : [1] 
Page 1 sur 1

Vous devez être connecté pour participer à la discussion.
Cliquez ici pour vous identifier.

Vous n'avez pas de compte ? Créez-en un gratuitement !
Recevoir PC Astuces par e-mail


La Lettre quotidienne +226 000 inscrits
Avec l'actu, des logiciels, des applis, des astuces, des bons plans, ...

Les bonnes affaires
Une fois par semaine, un récap des meilleurs offres.

Les fonds d'écran
De jolies photos pour personnaliser votre bureau. Une fois par semaine.

Les nouveaux Bons Plans
Des notifications pour ne pas rater les bons plans publiés sur le site.

Les bons plans du moment PC Astuces

Tous les Bons Plans
39,95 €Casque audio bluetooth JBL Tune 700 BT à 39,95 €
Valable jusqu'au 25 Janvier

Auchan solde le casque audio sans fil bluetooth JBL Tune 700BT qui passe à 39,95 € alors qu'on le trouve ailleurs à partir de 49 €. Léger, moderne et connecté, le casque sans fil JBL TUNE 700BT est un formidable allié pour savourer vos morceaux préférés. Idéalement posé sur vos oreilles, il délivre un son JBL de qualité tout en se connectant sans le moindre fil à votre appareil mobile via Bluetooth. Appréciez une belle autonomie de 24 heures, un contrôle pratique depuis les commandes sur l'oreillette ainsi qu'un port confortable.


> Voir l'offre
1349,99 €Acer Predator (15,6 pouces IPS 144 Hz, Core i7, 16Go/512 Go, RTX 3070) à 1349,99 €
Valable jusqu'au 30 Janvier

Cdiscount fait une belle vente flash sur l'ordinateur portable Acer Predator PH315-53-785U qui passe à 1349,99 €. Ce portable dédié aux joueurs dispose d'un écran 15,6 pouces IPS FHD 1920 x 1080 IPS 144 Hz, d'un processeur Intel Core i7 10750H, de 16 Go de mémoire RAM, d'un SSD de 512 Go (+ emplacements M.2 et SATA libres) et surtout d'une carte graphique Nvidia GeForce RTX 3070 qui vous permettra de profiter de vos jeux de manière fluide en haute résolution. Le tout tourne sous Windows 10 que vous pourrez passer gratuitement à Windows 11.


> Voir l'offre
69,90 €Boîtier PC ATX Fractal Design Meshify C avec vitre en verre trempé à 69,90 €
Valable jusqu'au 26 Janvier

Cdiscount solde le très bon boîter moyen tour Fractal Design Meshify C avec panneau latéral en verre trempé à 69,90 € alors qu'on le trouve ailleurs à plus de 95 €. Intelligemment conçu, le boîtier Meshify C de Fractal Design s'adresse avant tout à toutes les personnes recherchant un boîtier silencieux prêt à recevoir un système puissant et expansible de refroidissement par air ou par liquide mais également à ceux qui recherche un boîtier au look ravageur. 

Combinant design, espace et aération, le Meshify C peut accueillir jusqu'à jusqu’à 2 disques durs 3.5" HDD/SSD (et 3 x 2.5" SSD), une alimentation ATX, une carte graphique de plus de 315 mm et des possibilités de refroidissement allant de 7 ventilateurs de 120 mm ou 140 mm à du watercooling (240 mm au dessus, 360 mm en façade).


> Voir l'offre

Sujets relatifs
Archlinux : passage au noyau 3.4 en officiel
Driver Nvidia et nouveau kernel sur FC14
Nouveau driver NVIDIA
Ajouter "nouveau document" au menu
Nouveau membre
Archlinux : l'activation du pavé numérique ne se fait plus
Archlinux : mise à jour foireuse - merci chroot !
Installation du noyau 4.0.X sur Ubuntu 12.04.2
KDE4 : ou est passée l'option "nouveau" ?
Problème son qui grésille depuis installation nouveau kernel Debian
Plus de sujets relatifs à Archlinux - noyau 3.7.5.1 - driver nouveau
 > Tous les forums > Forum Linux