[Dev] libglvnd: OK or not?

Luke Shumaker lukeshu at lukeshu.com
Fri Mar 31 04:59:16 GMT 2017


Parabola recently blacklisted Arch's `libglvnd` for freedom reasons;
instead opting to build `mesa-libgl`, which had been disabled in Arch's
mesa build when `libglvnd` was introduced.

When I say that "Parabola" did that, I mean that one Parabola
developer did that, without discussing it with anyone else, or
documenting any justification.  So I'd like to bring it before the
wider community, if only to document reasoning.

So, the situation, as I understand it:

  The technicals:

    libGL (any implementation) provides a stable ABI across any number
    of implementations for different graphics devices.

    If you want to have multiple OpenGL drivers installed at once
    (perhaps you have multiple graphics cards in one desktop), then
    you must separate libGL from the driver implementations; libGL
    becomes a simple wrapper that dispatches to the appropriate driver
    library based on the GL context.

    Mesa, a free software OpenGL implementation, provides a libGL
    implementation does this, sort-of: Mesa includes drivers for many
    graphics devices, and Mesa's libGL implementation can dispatch to
    any of them.  However, it can *only* dispatch to drivers that are
    part of Mesa.  So you won't be able to have a Mesa-supported card
    and a non-Mesa-supported card in the same box together.

    So, someone wrote libglvnd, a libGL implementation that should be
    able to dispatch to any OpenGL driver, regardless of if the vendor
    is Mesa or someone else.  That is; libglvnd is merely a more
    general version of Mesa's dispatch (and indeed, borrowed much code
    from it).  libglvnd works by looking for shared libraries with the
    named "lib${ABI}_${VENDOR}.so" for whichever ABI it is trying to
    shim out (currently just EGL and GLX, but I think it will
    eventually in the future I expect GLES et c.), and a wildcard for
    the ${VENDOR}, discovering vendors at runtime.

  The politics:
    libglvnd has been received favorably by at least some of the Mesa
    team; Matt Turner (one of the Mesa developers), even wrote[0]
    "Hopefully [libglvnd] will allow us to get rid of our API dispatch
    code in Mesa."  For now, Mesa still contains API dispatch code, so
    when built with libglvnd support, some calls go through 2 layers
    of indirection, libglvnd, and then Mesa's own dispatch.

    [0]: https://bugs.freedesktop.org/show_bug.cgi?id=92877#c0

    The objection to libglvnd is the motivation: the "someone" that
    wrote it is NVIDIA, and the implicit goal is to be able to install
    the non-free NVIDIA drivers alongside Mesa.  Most, if not all,
    free OpenGL implementations are part of Mesa[1]; so the primary
    beneficiaries of libglvnd's existence are non-free OpenGL

    [1]: If any free OpenGL implementations exist outside of Mesa,
         they are not packaged by Arch or Parabola.

So, is it acceptable for FSDG distros to ship libglvnd instead of
Mesa's dispatch library?

My opinion is that libglvnd is fine.  It includes no references to
non-free drivers (it won't complain about missing "nonfree.bin" or
anything like the Linux kernel will).  I expect that in the future,
upstream Mesa will have it has a hard dependency.  While its existence
is of primary use to those using non-free drivers, its use doesn't
infringe on the freedom of those using purely free drivers.

Happy hacking,
~ Luke Shumaker

More information about the Dev mailing list