Enhanced OpenGL driver support in flatpak

Alexander Larsson alexl at redhat.com
Mon Feb 6 10:36:11 UTC 2017

Last week I spent some time looking into the GL driver situation for
flatpak. This is a tricky area, but it is important that we make this
work out of the box, even if you're using e.g. the proprietary nvidia

The future of GL on linux lies with the new libglvnd[1] GL dispatch
library. This is a single implementation of the GL library that then
dispatches to one or more vendor-provided driver implementations. This
makes shipping GL implementation much saner, since we don't need to
replace the basic library.

So, I've added libglnvnd to the freedesktop runtime and updated mesa o
13.0.3 built with libglvnd support. This is a good base for things, as
we can assume going forward that new drivers should work in this. Of
course, we still have to support old drivers (like legacy nvidia) that
don't support libglvnd.

Additionally I have done some changes in flatpak to make GL work:

 * We now support extra-data uris for runtime extensions, which means
   we can ship nvidia driver wrappers without redistributing the
   actual binaries.

 * flatpak-builder got support for building runtime extensions
   (which is used for e.g. gl drivers) in a simple way.

 * The extension support in flatpak grew some features that makes
   it possible for the GL extension point to support many drivers
   at the same time, and add all the required directories to
   LD_LIBRARY_PATH. That way we can support libglvnd even
   for complex multi-driver things like optimus.

 * The extension now also supports marking an extension as
   download/enable only if it matches the active gl driver.

The last part is a bit complex. Basically, the idea is to mark all the
GL extensions as "don't automatically download" and then only download
them if they match the current active driver. Additionally even if you
did download a non-matching driver (say you changed the host driver)
we only activate it if its still matching the current one.

The current implementation of detecting the driver only has special
code for the nvidia binary driver, where it looks up
/sys/module/nvidia/version and generates a driver name like
nvidia-375-26. It also always adds the names "default" and "host" to
the list, which is supposed to be used for updating the default mesa
driver and for re-packaging the host driver as a flatpak driver.
Alternatively if the FLATPAK_GL_DRIVERS env var is set this overrides
the driver used.

I've also added a build of the nvidia 375.26 driver to the freedesktop

The result here is that with the host nvidia drivers running, if i
install the freedesktop runtime I automatically get the matching
nvidia driver, as long as we've build a wrapper for the nvidia driver

For now this is not published on the official gnome runtime repo,
because its somewhat of a WIP, so if you want to try this, you need
flatpak from master, and the runtimes from:

I plan to work further on this this week, doing:

 * Wrapping more nvidia drivers
 * Building unstable mesa as an experimental flatpak driver.
 * Make sure gnome-software properly picks up the gl drivers
   (by using the existing libflatpak api for this).
 * Backport the required features to use this to the
   stable flatpak branch (0.8.x). Note: Not the
   build-part, just for consuming the builds.
 * Publish the final runtime builds on sdk.gnome.org

I would be interested in some help though:

 * Does anyone run the AMD proprietary driver. It would be nice
   to package it too, and automatically pick it up.
 * Are there any other drivers we want to package up?
 * Any kind of testing help would be appreciated.

[1] https://github.com/NVIDIA/libglvnd

 Alexander Larsson                                            Red Hat, Inc 
       alexl at redhat.com            alexander.larsson at gmail.com 
He's a Nobel prize-winning alcoholic firefighter possessed of the uncanny 
powers of an insect. She's a plucky insomniac advertising executive with 
a birthmark shaped like Liberty's torch. They fight crime! 

More information about the xdg-app mailing list