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 Heiko -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201107181350.39923.he...@sntech.de
