handling proprietary vendor libs for OpenGL ES [Was: implement gles-alternatives like glx-alternatives]
short summary for debian-x:
It seems that also on embedded systems vendors start shipping proprietary
graphics drivers and OpenGL ES implementations like NVidia and AMD do for x86.
Therefore I talked to Andreas on what would be the best way to implement a
functionality like glx-alternatives for the OpenGL ES libs.
Driver candidates I know off are:
- NVidia Tegra (http://tegradeveloper.nvidia.com/tegra/forum/linux-tegra-
- Omap4 (http://launchpad.net/~tiomap-dev)
and probably more.
Am Montag, 18. Juli 2011, 01:44:09 schrieb Andreas Beckmann:
> On 2011-07-16 22:26, Heiko Stübner wrote:
> > Hi,
> > glx-alternatives provides the means to have more than one libGL and glx
> > implementation on a machine.
> > I'm working on the Toshiba AC100 (NVidia Tegra ARM SoC) which also got a
> > proprietary driver released two weeks ago .
> > Tegra, like Omap, and probably other SoCs support "only" OpenGL ES (1 and
> > 2) wich is also provided by Mesa libs.
> > So I was wondering what would be the best way to realise a diversion
> > system like glx-alternatives for the OpenGL ES stuff.
> I think we should include the MESA packagers to see how they intended to
> make glx/gles and vendor implementations working together (I do know
> nothing about egl/gles).
> Please repost your question (and my comments below and eventual answers
> to them) including email@example.com in the Cc:
> > Possibilities I came up with were:
> > - build a completely separate gles-alternatives source package realising
> > the same functionality like glx-alternatives
> Is there any library (and diversion) overlap between glx and gles?
> yes -> merge with glx-diversions
> no -> separate packages (but eventually still the same source package
> for better code sharing)
there seems to be no overlap library-wise between OpenGL and OpenGL ES (1 and
2) for the ones vendors want to replace.
Therefore my thoughts were on simply letting glx-alternatives also build
packages for handling OpenGL ES stuff (i.e. gles-diversions, gles-alternative-
tegra, ... like the glx-* packages) but sharing the same source package for
the code sharing you mentioned.
> > Libs that need to be diverted most of the time are libEGL.so.1,
> > libGLESv1_CM.so.1 and libGLESv2.so.2 (at least for Tegra and Omap4 ).
> Is libEGL.so.1.0 (from package libegl1-mesa) a "fixed" filename or is it
> expected to be changed regularily? (libGL.so.1.2 from libgl1-mesa-glx is
> "fixed", but libgl1-mesa-swx11 provides libGL.so.5.* which changes with
> each upstream version and is therefore not divertible).
> Same question for the other libraries.
Hopefully one of the mesa-guys can answer this :-)
Libraries in question are: