On Mon, 25 Sep 2017 20:50:53 +0200 Andreas Beckmann <a...@debian.org> wrote:
[ Cc:ing the libglvnd maintainer ]
On 09/25/2017 04:38 PM, Emilio J. Padrón wrote:
> I obtain the same error when trying primusrun (or optirun) in my system:
>
> % primusrun glxinfo
> /usr/bin/primusrun: line 41: warning: command substitution: ignored null byte
in input
> primus: fatal: failed to load any of the libraries:
>
/usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1:/usr/lib/i386-linux-gnu/nvidia/libGL.so.1:/usr/lib/nvidia/libGL.so.1
> /usr/lib/x86_64-linux-gnu/nvidia/libGL.so.1: cannot open shared object file:
No such file or directory
> /usr/lib/i386-linux-gnu/nvidia/libGL.so.1: cannot open shared object file: No
such file or directory
> /usr/lib/nvidia/libGL.so.1: cannot open shared object file: No such file or
directory
>
> The '__GLVND_DISALLOW_PATCHING=1' workaround did not work for me :-?
> (same error messages).
The question is: how should primusrun/optirun work in a GLVND
environment? There is no longer the "vendor" libGL.so.1 that has to be
loaded instead of the system libGL.so.1
As I understand it, GLVND is supposed to provide a better solution to
the underlying problem addressed by primusrun/optirun.
Doesn't it only address part of the problem? Don't see a lot in regards
of turning the dedicated card on/off.
The dispatching to a specific vendor GLX is per x screen? At least thats
how it is described in https://github.com/NVIDIA/libglvnd. Which seems
to mirror the nvidia PRIME way.
So maybe primusrun/optirun will still bring up the card but only "fake"
the context to be nvidia for a specific application and thus forcing the
gldispatch to divert to the nvidia gl.
Note: if libgl1-nvidia-glvnd-glx is used (instead of libgl1-nvidia-glx)
and libgl1 (from src:libglvnd) is installed instead of
libgl1-glvnd-nvidia-glx, there is no longer a nvidia-provided
/usr/lib/*/nvidia/libGL.so.1
(Note for Timo: for the nvidia drivers we still need to divert the
system libGL.so.1 (and much more) since the legacy 304xx, 340xx drivers
don't support GLVND and we therefore still need to use the nested
alternatives, and we want to have them co-installable with the current
drivers)
> By the way, I suppose it is not really related, but I'm not able to install
> nvidia glvnd packages, libgl1-glvnd-nvidia-glx 375.82-4 and
> libglvnd0-nvidia 375.82-4, due to dependency problems. The metapackage
> libgl1-nvidia-glvnd-glx 375.82-4 is installed ok, since the libgl1
> dependency is provided by other packages. Is it also a bug? :-?
That is intentional to allow the nvidia packages into testing which
still has mesa 13.x and no libglvnd. You should be fine with the libgl1,
... packages from src:libglvnd in sid.
Andreas
BTW the workaround I posted still seems to work. But you must not forget
to link the libGL.so.1 into the nvidia subdirectory in addition to the
__GLVND_DISALLOW_PATCHING=1.
