Re: Bug#634100: ITP: tegra-linux -- Binary X11 and EGL drivers for NVIDIA Tegra chipset

[Heiko Stübner <heiko@sntech.de>]

Am Montag 18 Juli 2011, 18:04:00 schrieb Julian Andres Klode:
> On Mon, Jul 18, 2011 at 01:55:49PM +0200, Heiko Stübner wrote:
> > Am Samstag, 16. Juli 2011, 22:13:25 schrieb Julian Andres Klode:
> > > * Package name    : tegra-linux
> > > 
> > >   Version         : 12.0~alpha1
> > >   Upstream Author : NVIDIA Corporation
> > > 
> > > * URL             : http://developer.nvidia.com/tegra/
> > > * License         : NVIDIA Software License (non-free)
> > > 
> > >   Description     : Binary-only X11 and EGL drivers for NVIDIA Tegra
> > > 
> > > chipset
> > > 
> > > Description: NVIDIA Tegra binary Xorg driver
> > > 
> > >  This package provides the driver for the graphical unit of
> > >  NVIDIA's Tegra chipset.
> > 
> > very cool :-). I had the same thought and started talking to Andreas
> > Beckmann about having some sort of glx-alternatives equivalent for the
> > three OpenGL ES libraries that would need to be diverted [1].
> 
> Great. The problem here being that you actually have libegl1, libgles1,
> and libgles2 to divert. But all libraries depend on each other, so I
> currently have one package for them:
> 
>   Package: tegra-libraries
>   Provides: libegl1-tegra, libgles1-tegra, libgles2-tegra
The glx-alternatives package also diverts libGL and libglx and from what I 
gathered all vendor libs seem to provide libegl1, libgles1 and libgles2 
alltogether (at least for tegra, omap3 and omap4). I would guess systems only 
supporting GL ES 1are rare these days and won't get new Debian support in the 
future.

Looking at fglrx the one-package style also seems to be normal, i.e. they have 
fglrx-driver which contains the xorg-driver and fglrx-glx which provides libgl 
and libglx via the glx-alternatives mechanism.


> In the mean-time, while you're discussing, should I upload a package
> that simply diverts the library (It's almost finished now)?
As this was the way the fglrx and nvidia drivers handled this it until some 
weeks ago I would say - go ahead :-)

From what I gathered, the glx-alternatives mechanism is more a means to 
support switching between differend implementations without having to hard-
remove the relevant packages and let different vendor implementations play nice 
together on the same filesystem.


Heiko