GLX not recognised after MESA update?

Running NixOS unstable, sweethome3d (a Java application using JOGL) no longer starts, but produces the error:

➜  ~ nix-shell -p sweethome3d.application --run sweethome3d
these paths will be fetched (32.34 MiB download, 33.37 MiB unpacked):
copying path '/nix/store/anmqbk92bcpyhsjaq5v2h7wvfam6g8fi-sweethome3d-application-6.2' from ''...
Exception in thread "main" java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(
	at java.lang.reflect.Method.invoke(
	at com.eteks.sweethome3d.SweetHome3DBootstrap.main(Unknown Source)
Caused by: java.lang.ExceptionInInitializerError
	at com.eteks.sweethome3d.j3d.Component3DManager.createGraphicsConfigurationTemplate3D(Unknown Source)
	at com.eteks.sweethome3d.j3d.Component3DManager.<init>(Unknown Source)
	at com.eteks.sweethome3d.j3d.Component3DManager.getInstance(Unknown Source)
	at com.eteks.sweethome3d.SweetHome3D.addComponent3DRenderingErrorObserver(Unknown Source)
	at com.eteks.sweethome3d.SweetHome3D.init(Unknown Source)
	at com.eteks.sweethome3d.SweetHome3D.main(Unknown Source)
	... 5 more
Caused by: com.jogamp.opengl.GLException: Profiles [GL4bc, GL3bc, GL2, GLES1] not available on device null
	at com.jogamp.opengl.GLProfile.get(
	at com.jogamp.opengl.GLProfile.get(
	at com.jogamp.opengl.GLProfile.getMaxFixedFunc(
	... 12 more

Getting sweethome3d from another nixpkgs revision doesn’t help, it appears something changed on my system that causes the problem.

I have not fully bisected this yet, but it seems it started failing between ae6bdcc53584aaf20211ce1814bea97ece08a248 and 39247f8d04c04b3ee629a1f85aeedd582bf41cac. A notable change is the update from MESA 19.3.3 to 20.0.2.

What would be the way to further diagnose this?

That seems a very likely candidate.

You can use hardware.opengl.package (internal option) to override the Mesa version for /run/opengl-driver/lib without having to rebuild almost all packages. I lost my snippet but from looking at the module something like this should work (disclaimer: didn’t test it :o):

hardware.opengl.package = pkgs.buildEnv {
  name = "mesa-drivers+txc-${pkgs.mesa2.version}";
  paths = [
      (if hardware.opengl.s3tcSupport then pkgs.libtxc_dxtn else pkgs.libtxc_dxtn_s2tc)

And then add mesa2 to pkgs/top-level/all-packages.nix. You can test if this broke due to the Mesa update by checking out version 19.3.3 and moving it to another path or worktree (and use that as mesa2). If it’s due to Mesa you could also test if 20.0.4 fixes it.

That is very cool.

I can confirm rolling back to 19.3.3 makes sweethome3d work for me again, but updating to 20.0.4 doesn’t fix it.

I looked into this some more, and also got sweethome3d to work with 20.0.4 by using the other startup script shipped with sweethome3d.

I haven’t had the time to properly package that up, though. I’m not sure if this is a system-dependent problem, so I’m not sure if it’s OK to switch to the other startup script for all sweethome3d users or that it should be an option.

1 Like

For what it’s worth, and even though I don’t understand all this driver and opengl matter, I managed to get sweethome3d working by setting the environment variable: MESA_GL_VERSION_OVERRIDE=2.1

Cool, that works for me as well and sounds like something we could add to the derivation.

First executing export MESA_GL_VERSION_OVERRIDE=2.1 and then sweethome3d indeed works, thanks. But then, I suffer from the problem that all items of the menu bar are not visible. I am not sure if this behavior is caused by the same problem. Does it work for you guys?

This works for me (I’m on on nixos-unstable).

Anything interesting in the console?

Unfortunately not. But I went through my configuration.nix file and found the activated picom compositor. Deactivating this solved the problem with the empty menus. I actually do not remember why I put the compositor in my settings, so now hopefully everything is fine. Thanks for your fast reply.

Since I also ran into this today and lost some time on it, is anything preventing this to be included in the derivation?

No, it’s actually part of sweethome3d: 6.3 -> 6.4.2 by raboof · Pull Request #97129 · NixOS/nixpkgs · GitHub but that needs a review

1 Like

I am running into the issue again (nixpkgs 057f9aecfb71c4437d2b27d3323df7f93c010b7e).

Mesa updated again (23.1.9), would there be a way to infer the value for MESA_GL_VERSION_OVERRIDE from the mesa top level package in nixpkgs?

(edit: didn’t see how old the issue was, sorry for the bump from the depth)