Forum

Bonjours à tous,

Pour ceux qui comme moi aiment avoir la Cauldron mais ne dispose que d'une carte NVIDIA un peu ancienne (personnellement c'est une GTX 660 TI) et donc peuvent utiliser le pilote proprio 440.82 même si il n'ets pas dispo dans les dépots[/url]

Actually I've got an nvidia-current 440.82 package working. Also thanks to the attempts/test by Pierre Jarillon, Elliot, and Nicholas, it works without native glvnd. To resume, in current core/release mesa nonglvnd state.

I tested the driver on a native hardware with mga7 (64bit only).

If you agree, I'll push the current 440.82 working version, so it can be tested too, and if martin agrees it can be tested in the alpha1. Unfortunately this would revert the Elliot commits on the nvidia-current spec for a while. Then later we can introduce a conditional building flag so that it could exploit an glvnd-ready system, without loosing the compatibility in the package (we have to consider also that there is nvidia-current-cuda) for old stuff. For the impatients, I include here the spec file diffs. Actually I tested also the version 450.36.06 (beta) and it is actually working in the same way.

Indeed while testing while packaging I hit an automatic flipping of the xorg.conf configuration to nouveau, a couple of times the bug #24436 and #25204, and some debris of kernel modules sometimes left, that I cleaned manually. Also the initrd images sometimes contains the extra nvidia firmware (beyond nvidia kernel modules) and sometimes don't (I wonder what triggers this inclusion?).

BTW, where is in XFdrake the code/steps it executes to swap to nvidia, and enforce updates-alternatives? Thanks.

Once the nvidia 440.82 package is uploaded, the nvidia-current-cuda, could be upgraded to 10.2 too as it requires the 440 drivers. This is a big package, 2.5GB just source, so the BS system may hit a "filesystem full". Before this, how much free space there is now on the BS? Can it sustain a couple of nvidia-current-cuda building? Is there a way to check this ourselves?

An OT question. I noticed the system seems now very sensitive to systemd for desktop stuff. How is it possible to deal with it these steps:

- go in console mode (3) play with kernel modules, inserting module version V.1, rmmoding version V.0, start X with startx. Doesn't work? -> manually fix xorg.conf, rmmod, rebuild other modules, remodprobe, re-startx, without interference in xorg.conf, etc.

but actually the system no longer seems working with this, e.g. if I boot with 3 in boot cmdline and then startx manually, it fails with X, like if console tty was busy. Instead it would work while doing the right steps: let build modules, reconfigure, and reboot, but would also takes a lot of time on rebooting all the times when things are not building correctly. There should be certainly a better way to speed up this.

Bye
Giuseppe.

on attend que la alpha1 soit validée avant de pousser de grosses modifs