Hello hive mind,
I’ve just snapped an application that requires the opengl stack to be available. I declared the plug on snapcraft.yaml file and confirmed (using “snap connections”) that it had been successfully connected. Yet, I couldn’t make the app work correctly until Mesa libraries and drivers have been added into the snap.
So, question is: what does “opengl” interface really expose to snaps? It’s supposed to expose host’s GL stack, isn’t? Am I missing something?
There’s some pieces of the yaml, depicting plugs declaration and needed Mesa libraries:
apps:
curv:
command: usr/local/bin/curv
plugs:
- desktop
- desktop-legacy
- x11
- opengl
- home
part:
...
stage-packages:
...
- libglapi-mesa
- libglu1-mesa
- libglx-mesa0
...
From what I understand, you can divide the OpenGL libraries into distro-specific and hardware-specific libraries. The opengl interface gives you access to the hardware-specific libraries, while you still need to include the distro-specific libraries.
libglu1-mesa, for example, is a client library which sits on top of OpenGL, so it doesn’t talk to the hardware directly, it already uses the OpenGL API. It provides a bunch of high-level utility functions which are not hardware-specific. Technically, you can use OpenGL without this library, but most applications use it. By shipping it with the snap, application developers can choose which version of this library they use.
For a deep-dive; here is the security profile associated with the opengl interface. As you can see, this profile enables the snap to access a bunch of hardware-specific GPU libraries and the kernel interfaces for GPU support.: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/opengl.go
Here is some more general information about the steps required to enable GPU support in a snap: Adding OpenGL/GPU support to a snap
