Reprise du message précédent :
Ouep, on a un dépôt directement chez eux.
 
Là ça doit être un stagiaire qui package.
 
Le serveur pour nous c'est:
 ftp://download.nvidia.com/opensuse/11.2/

Faut voir ça comme un dépôt de test probablement mis en place par un des devs à usage plus ou moins interne (par ex, si nvidia fait ses tests linux sous opensuse). Ca n'aurait pas de sens pour une boîte commerciale de ne supporter qu'une seule distrib choisie arbitrairement.
Quant à savoir qui package, je dirais un script dont les paquets résultants ne sont pas testés avant mise à dispo.
 
A mon avis, tu serais mieux loti en dégottant un dépôt maintenu par un utilisateur.

kenéni.
C'est bien maintenu par nvidia, et ce n'est pas un bête script qui fait ça automatiquement. si c'était le cas on aurait toujours la dernière version ce qui n'est pas le cas. On a certaines versions clef et la bidouille de hier montre bien qu'il y a une action manuelle. IL faudrait que je cherche précisément comment c'est faiit, mais c'est plus complexe que ce que tu dis. nvidia package bien pour openSuse.
Il y a aussi CUDA etc
On a la même chose chez ati.
 
Dans les dépôts et niveau information sur les paquets j'ai par exemple:

Bah c'est le service de compilation mis à dispo gratuitement par opensuse. Le ftp de nvidia sert de miroir au dépôt d'un utilisateur de ce service.
Après, je ne sais comment construire un rpm mais j'imagine que c'est similaire à debian. Si tu te plantes dans les scripts, tu génères un/des paquets qui ne compilent pas (cas "pas grave" puisque non installable) ou pire, un paquet cassé dans lequel il manque des fichiers (cas "dangereux" car à moins de vérifier des buildlogs kilométriques, tu ne le vois que quand c'est installé).
C'est sans doute ce deuxième cas qui t'arrive.

Heu non ce n'est pas ça qui m'est arrivé.
 
Pour ma part ça a complètement pété un truc vu que j'ai du réinstaller d'autres pasquet avant de pouvoir repartir comme avant.
Si c'était juste un paquet nvidia foiré, en désinstallant et en mettant le binaire c'est bon ça devait repartir.
 
Or là ce n'était pas le cas ça n'a remarché qu'une fois avoir tout réinstallé les paquets concernant xorg et le kernel. donc ça avait du me dégager/foirer des fichiers de conf.
 
 
EDIT: et ce n'est pas un mirroir, c'est la source officiel des drivers nvidia, il n'y en a pas d'autres. (il y a d'autre personnes qui package ces drivers en projet home comme ça pour la communauté pour des cas particulier du style changement de kernel tout ça, mais la source disponible dans la liste des dépôts officiel c'est bien nvidia, idem pour ATI).

Je vais pas m'avancer sur ce terrain. Comme je l'ai dit, je ne sais pas comment sont construit les rpm ni leur contraintes et limites. Si je fais un parallèle avec les .deb, quand les dépendances/exclusions du paquet sont mal remplies tu peux te retrouver avec des fichiers du même nom appartenant à des paquets différents. Ca fait des mélanges malheureux
Pour l'avenir, si ça t'arrive à nouveau, commence par chercher du côté de mesa.

Possédant une GTX280, j'ai suivie depuis le départ le développement de VDPAU. Au départ, j'utilisais le dépôt ppa https://launchpad.net/~nvidia-vdpau.
 
Tout fonctionnait bien mais le codec c'est vu très vite implémenté dans d'autre application et inclue en tant que back-end,  notamment le VAAPI de Intel.
Le VAAPI avec VDPAU en backend semble être la bonne combinaison du moment avec beaucoup d'application supporté, notamment mplayer-vaapi, vlc et gstreamer-vaapi.  
 
L'avenir est au VAAPI depuis qu'il est possible de faire des backend du VDPAU de Nvidia, du XvBA de AMD et du Poulsbo d'Intel !
 
VDPAU avait pas mal de problème avec mplayer avant que je passe au VAAPI et je pense que pas mal d'entre vous sont dans le même cas (encore plus vrai depuis les driver 25x).
 
Pour résumé la manœuvre pour profiter du VAAPI, voici 2 solutions :
1- Soit vous passez pas le PPA https://launchpad.net/~nvidia-vdpau [...] multimedia et https://launchpad.net/~nvidia-vdpau et installez les pilotes, libva, vdpau-video, ffmpeg, vlc et mplayer...
2- Soit vous compilez tout à la main (plus stable) : install driver via ppa https://launchpad.net/~ubuntu-x-swat/+archive/x-updates, compilation de http://www.splitted-desktop.com/~gbeauchesne/libva/,  http://www.splitted-desktop.com/~g [...] pau-video/, http://www.splitted-desktop.com/~g [...] yer-vaapi/ et http://wiki.videolan.org/VLC_VAAPI.

En tout cas je confirme qu'il y a quelque chose dans le paquet nvidia qui me pète toute ma conf. Je viens de retester d'installer ce paquet, et vlam tout en l'air encore, j'ai du pour m'en sortir encore une fois réinstaller tous les paquets de xserver puis réinstaller le driver bin pour qu'enfin ça remarche.
 
Sinon problème avec les 256.35 sur ma 250gts M lors de la sortie de veille ça ne se passe pas tip top au niveau du login xfce à priori. Donc retour aux derniers 19X.XX

 
http://developer.nvidia.com/object/opengl_driver.html

Changelog de la version prerelease 256.44

J'ai des freeze suspects (machine complètement figée) depuis le 256.44 (que je n'avais pas avec le 256.35) => reset forcé,  
 
Par ailleurs, toujours avec le 256.44, je ne peux plus utiliser d'application accélérée tant que les effets de compositions de KDE4 sont activés (même glxgears foire), dès que je les désactive, ça remarche. Ce pb disparait en repassant au 256.35 ...
 
D'autres témoignages ?

Pour le moment, ras avec les 256.44 chez moi.

 
J'ai des freeze aussi avec KDE4 + effets, mais avec le 256.35

Je suis pas 100% sûr mais j'ai l'impression que l'hibernation (tuxonice) est cassée avec les 256.44. Enfin, je suis sûr que le driver nvidia se vautre au réveille, mais je ne suis pas certain que ce soit la faute de nvidia (je viens de réinstaller et j'ai encore des problèmes à régler).
J'ai déjà de gros soupçons par rapport au freeze de xorg qui m'a coûté 2 partitions (/ et /home - rien de grave), c'est décidé, je retourne aux 256.35.
 
EDIT: j'ai rien dit pour tuxonice. Les 256.44 se vautrent aussi alors qu'ils fonctionnaient parfaitement avant ma résinstallation.

Même problème avec les 256.44: freeze sous xfce + compiz en scroll sous firefox.
 
Et en plus ils se votrent si on redémarre le serveur X (en gros ça ne marche qu'une fois).
 
Je n'arrive plus à trouver de drivers correcte chez nvidia...

Apparemment, les devs nvidia ont identifié la cause des freezes de xorg dans les 256.44. Ils ont promis une version corrigée dans les ~10jours.

Ah ouf, parce que moi c'est sur du xorg 1.6.5 donc pas de xserver tout récent tout ça....  
D'ailleurs depuis récemment impossible de faire du suspend, avec les 195.36.31 qui sont les plus stables que j'ai trouvé pour l'instant, le suspend marche, mais lors de la sortie je perds le curseur???.
 
Pour la série des 256.XX c'est pire, c'est soit écran figé à la sortie de veille soit ça ram à donf c'est inutilisable jusqu'au prochain reboot...
 
ENfin espérons que les prochains drivers seront enfin bien stable...

Perso, j'ai abandonné l'idée que les fonctions natives de mise en veille du kernel fonctionnent un jour sur ma config - ça plante la machine et c'est tout.  
Depuis que j'ai patché avec tuxonice, j'ai zéro problème d'hibernation; un vrai bonheur.  
Du coup, je commence à me dire que la réponse aux problèmes de suspend est d'avantage dans l'implémentation foireuse qui en est fait dans le kernel que dans le code de nvidia.

Ben de mon côté avec cette machine tout fonctionné bien. (du moins à un moment). Mais avec les derniers drivers y a toujours un petit quelque choses qui cloche et c'est la seule change qui a bougé...

A te lire, le dernier fonctionnement correcte remonte à assez loin pour que tu ne retrouves plus la bonne version. T'aurais pas changé de kernel entre temps ?

Non ça remonte précisément à la dernière maj des drivers nvidia dans les dépôts, depuis ce moment là il m'est impossible de les réutiliser, je suis sur les bin et le seul bin correcte qui marche est un 195.XX.XX le dernier de cette série.
 
(avec le bug du pointeur en sortie de veille que je n'avais pas sur le précédent par contre...)

Tiens, ça ressemble aux symptômes que tu décris:
http://www.nvnews.net/vbulletin/sh [...] p?t=154326

Merci, il faut désactiver la synchro.... Vraiment bizarre quand même!
 
Enfin de toute façon vu que je ne fais pas de suspend ce n'est pas vraiment grâve, mais j'espèrerais avoir un drivers 256.XX qui fonctionne totalement... Et sans freeze. (car là moi je suis toujours en 195.XX)

Changelog de la version prerelease 256.52

Des retours dessus ou pas déjà?

Sur nvnews ca parle de freeze et grosse régression sous vdpau
 
Perso, je n'ai plus de machines avec du chip nvidia, j'attend la fin du moi pour investir à nouveau (alim peut être, si ce n'est pas pire )

mais non thana54, ce n'est pas la fin de toi à moins que je me trompe

Je vais finir par être heureux d'être encore en 195.30 vu la stabilité des derniers drivers...

J'ai
Je les devais réinstaller mes drivers pour un bug et j'en ai profité pour test cette version qui corrige le --Ignore-ABI chose
Rien à déclarer, ça marche

J'ai pas vdpau donc m'en tape si ça freeze/régresse à mort de ce côté.
Pour l'instant RAS avec les 256.52. Ni mieux ni pire que les 256.35.

Je testerais tout ça tien dès que j'ai un creux.

256.53 out qui reprend les 256.52 et "certifié".

Je me demande quelle grosse boulette ils ont laissée dans les 256.52 pour sortir une nouvelle version 24h plus tard

Petite mise à jour du 1er post, ca me soulais un peu de copier coller les mêmes lignes à chaque fois:

 
Donc ce paté ne sera plus présent, je ne conserverais que les mises à jour/fix des changelog, et je remonte les liens au début de post à coté des versions. Ca me parait plus clair et moins chiant que de chercher le bon pavé de quote pour sa version.
 
En ce moment:
 
 

Version actuelle
stable : 256.53 parue le 31.08.2010 (x86, x86_64)
OpenGL : 256.38.03 parue le 18.03.2010 (x86, x86_64)
 
 
Legacy GPU version (173.14.xx series):
stable : 173.14.27 parue le 15.07.2010 (x86, x86_64)
 
 
Legacy GPU version (96.43.xx series):
stable : 96.43.18 parue le 15.07.2010 (x86, x86_64)
 
 
Legacy GPU version (71.86.xx series):
stable : 71.86.14 (x86, x86_64)

Peut-être pourrais-tu préciser OpenGL 4.1.
 
Je me suis posé des questions, là.

En tout cas, j'ai eu un beau freeze avec le 52 sous KDE + effets / openGL + firefox
 
Vais voir si c'est mieux avec XRender.

Je les tests dessuite.

Bon ça marche mieux, mais toujours pas ça à la sortie de veille:
C'est figé, en fait tout continue à réagir mais plus que très lentement. Si je kill le serveur x via le double ctrl alt backspace tout repart comme avant....
 
 
Ce n'est toujours plus ça pour la mise en veille c'est fou...

Changelog de la version beta
Beta : 260.19.04 parue le 08.09.2010 (x86, x86_64)

nvcuvid

Bon, ben les 256.53 ont résolu mes pb de freeze et de ramage en compositing sous kde4 .... c'est donc la première version 256.xx utilisable sur ma Mandriva 2010.1