[bumblebee] 04/04: Update changelog for #815888

[Luca Boccassi]

On 1 May 2016 at 21:32, Luca Boccassi <luca.boccassi at gmail.com> wrote:
> Also, I noticed I still hit the problem with bumblebee when switching
> driver branch via update-glx --config nvidia: starting on current, all
> works, moving to 340xx, all works, but try to move back to current and
> it breaks because the legacy kernel module is still loaded. Restarting X
> and bumblebeed doesn't solve it.

Andreas,

I finally figured this out! Wore down GDB in the process, but now we
have a root cause :-)

Note that the problem is the opposite of what I said above, ie: the
correct kernel module is loaded, but the wrong libglx is used by Xorg.

The configuration file we ship lists as the Xorg modules path:

XorgModulePath=/usr/lib/nvidia,/usr/lib/xorg/modules

This is correct, as the active driver's libglx.so and nvidia_drv.so
are symlinked by update-alternatives in there.

But the reason the wrong libglx is loaded by Xorg is that the
FindModule and FindModuleInSubdir functions in
hw/xfree86/loader/loadmod.c do a depth-first search. Depending on the
order in which the content of a directory is listed by the readdir
syscall, if a subdirectory is returned, it will follow it instead of
checking all the files in the current directory first.

For whatever reason, legacy-340xx is always listed by readdir -before-
both current and libglx.so, so /usr/lib/nvidia/legacy-340xx/libglx.so
is found before /usr/lib/nvidia/libglx.so.

A quick workaround is to pass /etc/alternatives/nvidia to bumblebee's
XorgModulePath config variable, so that only the active driver
subdirectory is searched, and there's no room for mistakes.

I will try and see if Xorg's upstream would be willing to accept
changing the search to be breadth-first. Given it would change the
current behaviour, I fear such a change might not be accepted.

So, I propose to upload the workaround first so that we fix the bug,
and then if the problem is solved upstream in Xorg we can take it out.
What do you think?

Funnily enough, while searching to see if others had reported this
behaviour before, I found that you were poking in the exact same code
paths a few years back :-)
https://lists.debian.org/debian-x/2011/08/msg00157.html

Kind regards,
Luca Boccassi