nVidia:
./glarea0
CTor !
CTor finished !
Realize !
glarea0: ../libepoxy/src/dispatch_common.c:872: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.
Rebooting to AMD:
./glarea0
CTor !
CTor finished !
Realize !
glarea0: ../libepoxy/src/dispatch_common.c:872: epoxy_get_proc_address: Assertion `0 && "Couldn't find current GLX or EGL context.\n"' failed.
But both run, got a feeling the message is a red herring.
As a re-test, I re-installed Endeavour last night (Neo and then Nova). Both yielded the same problem. This morning, I installed Manjaro and that seems to be working (no epoxy error reported and the tools all run as they do under Pop_OS and similar). The 525.89.02 nVidia drivers are in use there under the 6.1.19 kernel (I have the 6.2.6 kernel installed, pending reboot).
So, I’m somewhat at a loss to explain why Endeavour is having trouble. Will keep experimenting as I finish setting up this install to be ~equivalent to what Endeavour was like, in case something breaks there.
Under manjaro, with the hybrid graphics active :
inxi -G
Graphics:
Device-1: NVIDIA GA104M [GeForce RTX 3070 Mobile / Max-Q] driver: nvidia
v: 525.89.02
Device-2: AMD Cezanne [Radeon Vega Series / Radeon Mobile Series]
driver: amdgpu v: kernel
Display: x11 server: X.Org v: 21.1.7 with: Xwayland v: 22.1.8 driver: X:
loaded: amdgpu,nvidia unloaded: modesetting,nouveau dri: radeonsi
gpu: amdgpu resolution: 2560x1600~60Hz
API: OpenGL v: 4.6 Mesa 22.3.5 renderer: AMD Radeon Graphics (renoir LLVM
15.0.7 DRM 3.49 6.1.19-1-MANJARO)
glxinfo | grep -i opengl
OpenGL vendor string: AMD
OpenGL renderer string: AMD Radeon Graphics (renoir, LLVM 15.0.7, DRM 3.49, 6.1.19-1-MANJARO)
OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.3.5
OpenGL core profile shading language version string: 4.60
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
OpenGL version string: 4.6 (Compatibility Profile) Mesa 22.3.5
OpenGL shading language version string: 4.60
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile
OpenGL extensions:
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.3.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
OpenGL ES profile extensions:
OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.3.5
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.3.5
vs
OpenGL core profile version string: 4.6 (Core Profile) Mesa 22.3.6
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 22.3.6
Yes, I did try rolling back the mesa version under Endeavour, but it didn’t seem to help, and I suspect Neo was running an older version (and maybe also Nova) when I re-installed those last night for the sake of testing. I can boot the live versions up to check later today. All in all, it’s rather odd. If I can break Manjaro the same way, that would be interesting.
So I tried almost every Arch derivative that I could find. Some only brought nouveau drivers with them, but the others that had nVidia drivers (which seem to be 525.89 or thereabouts), all had the same trouble with GL or the test tool would load and then immediately crash if the cursor touched the application window. So far, manjaro seems unique in not failing.
I’ll be watching Endeavour with interest and will re-test with any new release; I liked the system design and would like to run it to avoid the grub/LUKS pain with manjaro (forcing separate /boot and /boot/efi to avoid huge delays when decrypting the boot volume).
I wish I could pin down what was causing this different behavior, but nothing seems to stand out up to now.
If you use systemd boot with liuks there is no huge delay in unlocking luks.
So, Endeavour Artemis Nova works, but updating from that to Cassini Nova breaks things again. That’s really peculiar. I noticed that Artemis has amdgpu, nouveau and nvidia drivers all in the mix. Cassini has no nouveau listing. Still, it does seem that something relevant changed since September.
Out of curiosity, I wondered if there was a way to downgrade all libraries in an installation of Cassini to match a prior formal release (e.g. Artemis Nova). I’m wondering if something is hiding in a configuration file - manually downgrading various libraries hasn’t allowed me to allow libexpoxy to find the libraries, and as Artemis works, I begin to think a configuration file has changed somewhere. I understand that config files are left untouched with downgrades, so if I could downgrade all of the libraries, I was trying to check that theory.
Is there a way to perhaps do this?