Hello all,

I just noticed that xf86-video-nouveau-1.0.2 can be downloaded from the tarballs repository since September 12: it's no more necessary to pull it from git. Should we infer that it is deemed stable? I must admit I didn't try it yet, I will tomorrow.

Also, maybe xf86-video-modesetting-0.5.0, also available on the repository, could be useful for some of us, see here.

The new nouveau driver has a new API, using that tarball would require the new libdrm as well and possibly a recompile of libmesa.

Well, i wouldn't have bet 1 million € on its inclusion in Slackware 14, anyway

Still I will try it, just for fun.

The newer Nouveau driver would require the updated LibMesa unless it already supports it.

Is Nouveau still using Gallium3D?

Which updated mesa? Slackware in current shortly to be 14 already has the latest v8.0.4

Mesa 8.0.4 is the latest released stable update, but 9.0 (if not 9.1) with OpenGL 3 support will be out very soon.
I wonder if Pat will put it in testing/, if Slackware 14 will be out just after Mesa hits version 9...

If the nouveau 1.0.2 driver was built around libmesa 8.0.4, then it will not need a recompile unless the driver is NOT using Gallium3D as it's base API.

I'm running xf86-video-nouveau-1.0.2 on Slackware 14-RC5

I just had to upgrade libdrm to the latest version (2.6.39 at time of writing) before building it and mv the specific configure file for xf86-video-nouveau out of the way as of course running autogen.sh is no more needed.

I just ran the stock slackbuilds included in Slackware 14 RC5 unmodified.

@ReaperX7: no need to upgrade mesa and yes, Gallium is still used.

PS As a consequence, the script xf86-video-nouveau in source/x/x11/configure/ is no more needed, neither the script get-xf86-video-nouveau.sh as pulling the files from git is no more necessary.

This confirm that the build system of Slackware is really awesome, thanks to Patrick and the Slackware team.

On current, i have compiled the xf86-video-ati-6.14.6 with libdrm-2.4.39, and it work perfectly here, don't work, if it is compiled with libdrm-2.4.33.

1 members found this post helpful.

Well, maybe some of you have already read the ChangeLog.txt updated on Sat Sep 22. Slackware will include this version.

Paraphrasing my son: "This Slackware is going to be epic"... full of updated and stable goodies...

Didier can you confirm if the openGL stuff works properly eg glxinfo?

I'm having issues but I'm not sure I've cleaned out the nvidia driver fully.

EDIT Found the culprit, a part of nvidia as I thought. Now it seems to be working ok

Yes, I can.

Probably you haven't, as I have had the same problem...

To solve it this is what I did IIRC (not sure all steps were needed but it worked):
(1) I checked this page and made sure that I had the symlinks created by the proprietary driver removed.

(2) It was not enough so I removed then installed again libdrm and mesa packages.
While removing I saw some warnings as some directories did contain new files. I removed these directories manually after checking their content.
Tip : you can do e.g. "removepkg <package name> 2>&1 | tee /home/user/removelog" then check removelog to be sure you didn't miss a warning.

(3) As this was not enough I did suppose that some files installed by the proprietary driver were still lying around.
To find out I did "ls -ltr /usr/lib/libG*" and checked that the files in the output came from a Slackware package.
You can do that with "grep <filename> /var/log/{packages,scripts}/*"
If that command returns nothing (and you checked you typing) you may delete that file as it was neither included in a Slackware package nor created by a script bundled in the package.
In fact it was easy to spot that I had several files installed at the same time (which was the time I installed the proprietary driver) and remove it.
To make sure you didn't miss anything you can enlarge the scope of the search typing "ls -ltr /usr/lib" and check that no other libraries or symlinks were installed at the very same time.

Sorry English is not my native language, I hope that what I wrote is understandable though.

haha as I edit to say I fixed it your typing out a long post.

As it would happen I found the problem by checking the Xorg log and it showed an error when loading the glx extension (it was linked to another nvidia lib that I had already removed)

Replaced the nvidia version of the glx extension and it's back working fully

@wildwizard: I am happy you succeeded.

I will let the _long_post_ as it is though, as it could help others.