I am not sure. Did you try to run chimerax with the workaround?
On Mon, Oct 25, 2021 at 8:57 PM Eric Shell <eshell@ucsc.edu> wrote:
>
> Hi Ulrich,
>
> Thank you for continuing to look into this.
>
> I ran into another problem with GLX today, with a tool called chimerax which requires GLX 1.4 or greater. I read the page on getting GLX 1.4 working on the wiki (https://wiki.x2go.org/doku.php/wiki:development:glx-xlib-workaround) and I was wondering if it meant that the wrappers do not work with the NVIDIA drivers. I take it that means that if an application won't run with the
>
> __GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 <your application>
>
> workaround, there's not much else to try?
>
>
>
> On Sat, Oct 23, 2021 at 10:49 AM Ulrich Sibiller <uli42@gmx.de> wrote:
>>
>> Well, as said before I do not have any Nvidia hardware. But today I
>> played a bit with that stuff with Firefox 78.7.0-esr on Debian wiht
>> Intel graphics and I see the same errors you see inside NX. So maybe
>> this is not all linked to nvidia but simply firefox failing some
>> checks in an NX session. firefox does not even load libGL here.
>> Investigating further...
>> Uli
>>
>> On Thu, Oct 21, 2021 at 5:54 PM Eric Shell <eshell@ucsc.edu> wrote:
>> >>
>> >> Did you reinstall the same nvidia drivers or a newer version?
>> >
>> >
>> > Right now I'm again running the original drivers (460.73.01) installed from the .run file.
>> >
>> >>
>> >> IIRC there once was the necessity to chmod /dev/nvidia or similar to
>> >> make it available to all users. Not sure if that's still required.
>> >
>> >
>> > The permissions look correct. There are /dev/nvidia0 and /dev/nvidia1 devices for the 2 GPUs:
>> >
>> > # ll /dev/nvidia*
>> > crw-rw-rw-. 1 root root 195, 0 Oct 19 09:58 /dev/nvidia0
>> >
>> >>
>> >> Just to be sure: are you connecting to the local X server (a so called
>> >> shadow session) or are you starting a NEW mate desktop in addition to
>> >> X server?
>> >
>> >
>> > I don't think so but how can I tell? I am not connecting with X2Go/X11 Desktop Sharing if that's what opens a shadow session, but rather starting a MATE session.
>> >
>> >> > WebGL creation failed:
>> >> > * Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_OPENGL_1
>> >> > * Exhausted GL driver options.
>> >> >
>> >> > Running "__GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 firefox" didn't get WebGL working, either, but did change the about:support output:
>> >> >
>> >> > WebGL creation failed:
>> >> > * Refused to create native OpenGL context because of blacklist entry: FEATURE_FAILURE_GLXTEST_FAILED
>> >> > * Exhausted GL driver options.
>> >>
>> >> Does this call work with glxinfo/glxgears?
>> >
>> >
>> > Yes, it does. glxgears runs without crashing the session and glxinfo reports it is using direct rendering. It appears to be using my client's (a VM) X server for OpenGL rendering, is that right?
>> >
>> > $ __GLX_VENDOR_LIBRARY_NAME=mesa LIBGL_ALWAYS_SOFTWARE=1 glxinfo
>> > ...
>> > OpenGL vendor string: VMware, Inc.
>> > OpenGL renderer string: llvmpipe (LLVM 7.0, 256 bits)
>> > OpenGL version string: 2.1 Mesa 18.3.4
>> > OpenGL shading language version string: 1.20
>> >
>> >>
>> >>
>> >> > Any idea how I can get WebGL rendered in an X2Go session again? I would assume that there wasn't a solution using X2Go if I hadn't used it successfully myself mere days ago. I intend not to use VNC if at all possible.
>> >>
>> >> I am a bit puzzled about that blacklist entry. Maybe that is
>> >> modifiable in about:config. I have checked my firefox88 and it does
>> >> NOT seem to have this blacklist entry in about:config.
>> >>
>> >> Also check/disable the hardware acceleration setting in firefox.
>> >
>> >
>> > I tried setting webgl.force-enabled to true and got different output from about:support:
>> >
>> > WebGL creation failed:
>> > * tryNativeGL
>> > * Exhausted GL driver options.
>> >
>> > I've tried toggling hardware acceleration on/off but it doesn't seem to make a difference.
>> >
>> >>
>> >>
>> >> Uli
>> >
>> >
>> >
>> > --
>> > Eric Shell
>> > PBSci Technical Staff
>> > eshell@ucsc.edu
>> > 831 459 4919
>
>
>
> --
> Eric Shell
> PBSci Technical Staff
> eshell@ucsc.edu
> 831 459 4919