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

[Christopher James Halse Rogers]

On Mon, 2011-07-18 at 13:50 +0200, Heiko Stübner wrote:
> 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

Filenames which *are* fixed are libGLESv1_CM.so.1, libGLESv2.so.2 and
libEGL.so.1, as those are the SONAMEs of the respective libraries.  I
wouldn't guarantee that the filenames listed above won't change (I'm
somewhat surprised it isn't libEGL.so.1.4, for example).

dpkg-divert should be happy to divert those symlinks, right?

Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.alioth.debian.org/pipermail/pkg-nvidia-devel/attachments/20110721/e795d4ad/attachment.pgp>