Dkms

[panthere]

[quote=“panthere”]de memoire le run lui meme passe aussi par module assitant

A ma connaissance non, le .run ne s’installe pas via module-assistant.

Toi tu dis le contraire parce que tu passe par module assitant

C’est pas moi qui passe par module-assistant, c’est sgfxi.

Pour le reste je ne peux pas chercher plus que ça parce que j’utilise Nouveau, mais je pense qu’en gros le script télécharge le .run de nvidia (comme je viens de le faire à l’instant sur le site de nvidia), le décompresse (comme je viens de le faire) :

Ce qui créé un dossier NVIDIA-Linux-x86_64-285.05.09 qui contient ceci :

~/NVIDIA-Linux-x86_64-285.05.09$ ls 32 libnvidia-cfg.so.285.05.09 LICENSE nvidia-settings.desktop glext.h libnvidia-compiler.so.285.05.09 makeself.sh nvidia-settings.png gl.h libnvidia-glcore.so.285.05.09 mkprecompiled nvidia-smi glxext.h libnvidia-ml.so.285.05.09 nvidia-bug-report.sh nvidia-smi.1.gz glx.h libnvidia-tls.so.285.05.09 NVIDIA_Changelog nvidia-xconfig html libnvidia-wfb.so.285.05.09 nvidia-debugdump nvidia-xconfig.1.gz kernel libOpenCL.so.1.0.0 nvidia_drv.so pkg-history.txt libcuda.so.285.05.09 libvdpau_nvidia.so.285.05.09 nvidia.icd README.txt libGL.la libvdpau.so.285.05.09 nvidia-installer tls libGL.so.285.05.09 libvdpau_trace.so.285.05.09 nvidia-installer.1.gz tls_test libglx.so.285.05.09 libXvMCNVIDIA.a nvidia-settings tls_test_dso.so libnvcuvid.so.285.05.09 libXvMCNVIDIA.so.285.05.09 nvidia-settings.1.gz

Je suppose que là dedans y’a tout ce qu’il faut pour compiler le module, comment ça exactement, je n’en sais pas plus. Mais nul doute que module-assistant est utilisé.

Par contre je pense que le .run ne fait qu’installer les librairies extraites là où il faut en les copiant/collant et écrasant celles qui existent déjà sans en informer le système.

Mais une fois de plus si quelqu’un plus doué que moi lis ces lignes et a la réponse, ça m’interesse. Ceci dit, sgfxi est un script libre tu peux le consulter et regarder ce qu’il fait exactement si tu en as le courage et les capacités, ce n’est pas mon cas.[/quote]

interessant les ficher, serai donc copier coller/en ecrasant ceux qui existe ou pas. ce qui est très mauvais.
La question reste a savoir si sgfxi ou le paquet livrer par apt empêche ce risque ? j’ai pas la réponse non plus.
tan que sa n’ecrase pas une librairie c’est limite tolérable mai si sa la remplace la sa peux rendre le système instable.

[Sergio]

Cela va en effet assez loin, puisqu’il y a l’affaire des diversions, ce que fait nvidia-glx. Et là, à mon sens, SGFXI et a fortiori le .run n’ont pas de procédure équivalente et mettent tout en /usr/lib et /usr/lib32. Ceci dit, je pense que Mesa de son côté doit se diversionner toute seule, encore que je n’en sois plus très sûr.

[pitcat]

[quote=“syam”]
C’est sûr que c’est vachement plus pratique (et logique) de réinstaller toute la chaîne de compilation à chaque mise à jour du kernel ou des pilotes, puis de la supprimer à nouveau juste après…
Il suffit que tu aies en plus par exemple VirtualBox (qui a besoin de compiler des modules du kernel lui aussi), et ça devient vite invivable.
Enfin, chacun ses méthodes et ses habitudes. [/quote]
J’utilise DKMS pour nvidia et Virtualbox et c’est pas invivable c’est fait en toute transparence comme l’installation de n’importe quels autres "paquets"
Que se soit sur un kernel stock ou un kernel perso

[syam]

[quote=“pitcat”][quote=“syam”]
C’est sûr que c’est vachement plus pratique (et logique) de réinstaller toute la chaîne de compilation à chaque mise à jour du kernel ou des pilotes, puis de la supprimer à nouveau juste après…
Il suffit que tu aies en plus par exemple VirtualBox (qui a besoin de compiler des modules du kernel lui aussi), et ça devient vite invivable.
Enfin, chacun ses méthodes et ses habitudes. [/quote]
J’utilise DKMS pour nvidia et Virtualbox et c’est pas invivable c’est fait en toute transparence comme l’installation de n’importe quels autres "paquets"
Que se soit sur un kernel stock ou un kernel perso[/quote]
Une interprétation possible de ton message c’est que tu n’as absolument pas compris ce que je voulais dire : je répondais (de manière un peu ironique, soit) à Sergio qui semblait se plaignait qu’avec DKMS il faut garder gcc et les headers du kernel installés en permanence.

L’autre interprétation possible de ton message c’est que tu supprimes les headers entre chaque installation du kernel et que tu les rajoutes juste avant d’installer un nouveau kernel, ce qui peut difficilement être qualifié de “c’est fait en toute transparence”, le message de wetaskiwin le prouve (il suffit d’un oubli pour que ça se mette à déconner).

[Sergio]

C’est quand même quelque chose à surveiller. La doc /usr/share/doc/nvidia-kernel-dkms, partie Debian, précise bien que c’est un changement, une mise à jour des linux-headers qui déclenche celle de DKMS et tout ce qui s’ensuit, GLX et consorts. Cela signifie donc qu’il faut avoir ces headers installés, et très probablement qu’une mise à jour de linux-image s’accompagne d’une de ces headers. Jusque-là tout va bien, recompilation automatique du driver Nvidia et on n’en parle plus, avec cette précision que pour les kernels 2.6 il faut que la commande gcc pointe au moment de l’opération sur gcc-4.3 et non 4.4.

Seulement, quel driver Nvidia est recompilé par cette opération ? Celui de la distribution correspondant à son sources.list. Je mets de côté le cas où l’on se promène, je suppose que l’on travaille toujours avec un seul. Même là, rien ne prouve que la version proposée du driver n’a pas changé depuis qu’on l’a installé. Fort bien, on en aura une nouvelle. Mais si on avait envie de conserver l’ancienne, qui donnait satisfaction ? Il y a beaucoup de cas, quand même, en matière précisément de drivers Nvidia. A ce moment-là on me dira que le mieux est de ne plus rien mettre à jour du tout ! C’est donc assez délicat…

Des cas où il vaut mieux revenir en arrière s’agissant du driver Nvidia, nous en voyons précisément un actuellement, où nous assistons à un retour en 275 après deux mois en 280. Et pourquoi ? Syam le dit : incompatibilité avec le nouvel Xorg. Mais pourquoi pas aussi avec celui que j’ai dans ma Squeeze ? Cela pourrait expliquer de petits voiles lumineux, a priori sans conséquence mais qui mettent toujours un peu mal à l’aise lorsqu’on est plongé dans la 3D, que j’ai parfois à l’occasion de ladite 3D et seulement là. Donc que faire ? Revenir moi aussi en 275 ? A vrai dire, jeu sais pas…

[panthere]

bon alors 1 problème a la fois

pour tes bug la solution c’est aussi de faire un rapport de bug
contribuer ,c’est aussi permettre de les corriger et d’éviter que sa traine.

Ensuite les header son obligatoire pour les driver nvidia ,c’est pas dkms qui le rend obligatoire mai bien nvidia, essaye de le faire avec le module assitant tu verra qu’il en a aussi besoins.

donc dkms compile les modules et le fait a chaque changement du kernel, t’est pas obliger de l’installer si tu n’en veux pas quand t’en a marre de faire ta compile a la main tu verra que c’est bien pratique:)
le seul inconvenient c’est les header mai bon je pense que sa devrai ce joindre automatiquement dans le future a dkms:)

[syam]

avec cette précision que pour les kernels 2.6 il faut que la commande gcc pointe au moment de l’opération sur gcc-4.3 et non 4.4.

Tu n’as pas à t’en préoccuper, DKMS gère ça comme il faut. Je suis resté longtemps en kernel 2.6 tout en utilisant DKMS, et je n’ai jamais eu besoin de m’occuper de ça.

Seulement, quel driver Nvidia est recompilé par cette opération ? Celui de la distribution correspondant à son sources.list. Je mets de côté le cas où l’on se promène, je suppose que l’on travaille toujours avec un seul. Même là, rien ne prouve que la version proposée du driver n’a pas changé depuis qu’on l’a installé.

DKMS compile le pilote installé par les paquets provenant du dépôt (cf. la liste de paquets que j’ai donné plus haut). Si tu ne mets pas à jour ces paquets, tu garderas le même pilote qu’actuellement, il sera simplement recompilé pour s’adapter au nouveau noyau. C’est aussi simple que ça.

Quant à la mise à jour des headers en même temps que le kernel, c’est bien simple : il suffit d’installer les métapaquets linux-image-amd64 (ou -686 selon ton architecture) et linux-headers-amd64/686. Dès qu’un nouveau noyau est disponible, il installera les headers avec.

nous en voyons précisément un actuellement, où nous assistons à un retour en 275 après deux mois en 280. Et pourquoi ? Syam le dit : incompatibilité avec le nouvel Xorg. Mais pourquoi pas aussi avec celui que j’ai dans ma Squeeze ?

Parce que le nouvel XOrg a changé son ABI (Application Binary Interface, en version 11 maintenant) ce qui pose des problèmes avec le blob binaire de NVidia qui lui ne gère pas encore la nouvelle ABI. Le XOrg de ta Squeeze n’est pas concerné car il utilise toujours l’ABI version 10 qui elle est bien gérée par le pilote NVidia.

[Sergio]

faire un rapport de bug

C’est pas assez net quand même pour le moment. Et si cela venait aussi du soft ? Il faut déjà que j’essaie avec un driver Nvidia qui n’a pas été retiré de la circulation. Ou alors le tout dernier (l’actuel, donc) me tenterait bien, justement il y a quelque chose contre les clignotements, mais là c’est le .run ou SGFXI, cela m’ennuie pour la cohérence de mon installation ciselée au couteau…

C’est moyennement préoccupant, disons. Il faut dire que je sors d’un an d’artefacts, de vrais, cette fois, avec une Quadro FX 5800, donc je suis un peu ombrageux sur le sujet…

J’ajoute que j’ai laissé passer deux ou trois mises à jour de linux-image sans, justement, réinstaller le driver… Tout cela fait quand même pas mal de paramètres.

[Sergio]

[quote]DKMS compile le pilote installé par les paquets provenant du dépôt (cf. la liste de paquets que j’ai donné plus haut). Si tu ne mets pas à jour ces paquets, tu garderas le même pilote qu’actuellement, il sera simplement recompilé pour s’adapter au nouveau noyau. C’est aussi simple que ça.

Quant à la mise à jour des headers en même temps que le kernel, c’est bien simple : il suffit d’installer les métapaquets linux-image-amd64 (ou -686 selon ton architecture) et linux-headers-amd64/686. Dès qu’un nouveau noyau est disponible, il installera les headers avec.
[/quote]
Pour le 2, j’ai bien pigé, mais pour le 1, justement, c’était le 180.13.1, le vrai : donc il a disparu ! Et moi, comme un âne, maintenant je m’en souviens, j’ai enlevé les headers et le kernel-source proprement, par Synaptic, mais le reste dans le /usr/src, donc le driver, gaillardement à la mano…

Enfin c’est pas bien grave, j’ai presque envie de tourner comme cela jusqu’à ce qu’on voie réapparaître du vrai 285 ou plus. Ensuite, continuer comme tu dis par DKMS automatique. De toutes manières ma toute première question était sur l’essence même de DKMS, j’imaginais naïvement qu’il pouvait y avoir une différence de fonctionnement et de réactions du driver avec les autres méthodes.

[Sergio]

Bon finalement comme la situation risque de s’éterniser avec le 275, je l’ai installé, en DKMS, en lieu et place du 180.13, de manière à avoir une station propre (accord kernel et Nvidia) et “DKMS ready”. Impossible pour le moment de voir si mes “voiles lumineux” sous Ayam3D continuent, même si c’est parfois presque spectaculaire, il faut quand même être collé devant éventuellement une heure ou deux.

La seule chose, c’est que lorsque les drivers récents reviendront dans les distributions, ils seront certes compatibles avec l’ABI de l’Xorg de la Wheezy, mais y aura-t-il compatibilité ascendante avec celui de la Squeeze ? Enfin bon, je pourrai toujours monter mon Xorg, à ce que j’ai pu voir durant mes essais de juillet cela semble sans problème.