new drivers for sid!

Andreas Beckmann anbe at
Sat Jan 23 19:38:01 UTC 2016

On 2016-01-23 19:24, Luca Boccassi wrote:
> I have given more thought to libglvnd. Both AMD and Mesa have committed
> to (eventually) use libglvnd as a dispatcher, and it is released under
> an MIT-like license on Github.

Good to know.

There is this decription of what the individual libraries do:
hmm, where is that libGLX?

can you draw a graph of the dependencies between the libraries? Or does
something like this exist already?

> A possible solution would be to package libglvnd from sources, and add a

> new glx-alternative-glvnd that can take over libGL, libGLESv1/2 and
isn't the purpose to have one for all vendors?

> (when it will be implemented) libEGL. We can then stop shipping those
> libraries from the Nvidia proprietary installer, and also stop adding
> the *nvidia slave for those .so files in glx-alternative-nvidia.

> When mesa and fglrx get around to add support, we can drop the slaves
> from those glx-alternative-* packages too and add a dependency.
> I've already done the packaging for libglvnd,
Good, we cn start putting that under pkg-nvidia for now, but in the end
this should probably live under the hands of the X/MESA maintainers.
We should talk to them about this, you mentioned that earlier ... if you
want, you can start that discussion (making sure that pkg-nvidia-devel
stays Cc:ed).

> and I've also created the
> glx-alternative-glvnd.
I don't want that  :-)

> Tomorrow I'll finish working on 361 and then I'll
> test everything together and see how it works.
Nice, but maybe wait with committing until I have 352 in sid and
everything merged through to 358. (Only waiting for 349.16-2 to pass the

> I'll also take out
> libglvnd-nvidia from 355/358.
NACK. For the beginning I want to ship nvidia's version of these
libraries, this seems to be too much work in progress. There aren't any
tags, yet, so do we know what commit should correspond to the shipped
binaries ...
And I want ship them directly in /usr/lib without any redirecting
alternatives. :-)
Once someone else starts to adopt them we should switch to the
separately packaged versions.

Trying to understand the "new" libEGL works ...
* nothing seems to use libOpenGL right now
* is a stub and depends on libGLdispatch
* libGLdispatch is used by libEGL, libOpenGL
* the we have and
* is used by and
* contains the strings "__EGL_VENDOR_LIBRARY_NAME",
  "nvidia", ""
* uses symbol __egl_Main from
* there is also a string "libGLdispatch ABI version is incompatible with
libEGL.", so libGLdispatch and the libEGL stub somehow need to be in sync

=> we need a separate libegl-nvidia0 package, and that actually needs to
use alternatives
that package may get legacy variants, maybe called

libegl1-nvidia will probably go away in the future (if someone else
(MESA) provides a stub


More information about the pkg-nvidia-devel mailing list