Frank Griffin wrote:
> So you're saying that nvidia libGL only works in conjunction with the
> nvidia proprietary driver.

Yes.

> Is it also true that no other libGL works
> with the nvidia proprietary driver ?

The Mesa libGL works as well, but without 3D acceleration. We want to
use the NVIDIA one.

> Because if that's true, then all
> users of libGL on an nvidia proprietary system must also use the nvidia
> proprietary libGL, no ? And if it's not true, then why use alternatives
> to make them use it ?
>
> If the only thing that *needs* the nvidia proprietary libGL is the
> nvidia driver, why doesn't it provide a package which provides
> libGLNVidia.so.1, and require that instead ?

The applications need to use the NVIDIA libGL.so.1 as well, in order to
have 3D hardware acceleration.

>
>>
>>> But I have two cooker systems, one with an nvidia card and one
>>> without. Mesa is installed on both. On the nvidia system,
>>> /etc/alternatives/gl_conf is symlinked to /etc/nvidia-current/ld.so.conf
>>> and on the other it is symlinked to
>>> /etc/ld.so.conf.d/GL/standard.conf. So how is mesa expected to work
>>> on both ?
>>>  
>>
>> Mesa libGL only works on the non-nvidia system. On the NVIDIA system the
>> NVIDIA-provided libGL is used instead.
>>  
>
> I understand that, but my question is why we use alternatives to force
> mesa on the nvidia system to use the nvidia-provided libGL. If the mesa
> libGL truly does not work with the nvidia card, the the statement that
> "everyone using libGL *has* to be using the same version as the video
> driver" is true. If not, then forcing mesa (or anything else) to use
> nvidia's libGL via alternatives runs the risk of breaking something if
> nvidia *doesn't* keep in synch with the "standard" libGL, no ?

The risk is there in either case. But so far AFAIK the NVIDIA libGL has
been in sync or ahead of the Mesa libGL.

--
Anssi Hannula