Bug#900248: nvidia-driver: update to 390.59 breaks direct rendering

[Peter De Wachter]

On Wed, May 30, 2018 at 10:54 PM, Luca Boccassi <bluca at debian.org> wrote:
> Given there have been multiple reports, I'll upload a new version of
> glx-alternatives that moves the module redirection from modules/linux
> to modules/drivers (where there is no clash).
>
> Before I do that, given you had the issue and moving the module fixes
> it, could you please double check that moving the symlink from
> modules/linux to modules/drivers (NOT modules/extensions, and putting
> back what was there) doesn't cause more problems?
>
> Still not sure why my Sid installation was working just fine...

No, that doesn't work for me.

Check xorg-server-1.20.0/hw/xfree86/loader/loadmod.c. It's some very
confused code. There's a friendly-looking array:

/* Standard set of module subdirectories to search, in order of preference */
static const char *stdSubdirs[] = {
    "",
    "input/",
    "drivers/",
    "extensions/",
    NULL
};

But that comment is a lie. The FindModulesInSubDir() function recurses
in subdirectories! So the loader will start with the first entry of
that array, but it will search recursively and find either
extensions/libglx.so or linux/libglx.so depending on readdir()
order... This is why this bug occurred only on some systems and not on
others. It also means that your proposed fix won't work.

In xserver 1.19, the linux/ subdir was _prepended_ to the subdir list,
so there the nvidia libglx.so was reliably selected.

I don't know how to fix this without patching the xserver code. Maybe
it's possible to manipulate the search path with an xorg.conf
fragment?

Best regards,
Peter