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@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
signature.asc
Description: This is a digitally signed message part
