handling proprietary vendor libs for OpenGL ES [Was: implement gles-alternatives like glx-alternatives]

[Heiko Stübner]

Hi,

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-
release-12-alpha-1-released)
- Omap4 (http://launchpad.net/~tiomap-dev)
- Omap3
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 [1].
> > 
> > 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 debian-x at lists.debian.org 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[2] ).
> 
> 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:
- libGLESv1_CM.so.1.1.0
- libGLESv2.so.2.0.0
- libEGL.so.1.0


Heiko