Dropped several dependencies because the "distribution tarball has been renamed
and now contains all the generated sources."
http://lists.freedesktop.org/archives/mesa-announce/2015-March/000145.html
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Some OpenGL/EGL/GLES/VG providers do not provide the corresponding
headers, and rely on using "the headers provided by the distribution".
In our case, we can not rely on such headers, because we are not a
distribution, and we have no way to provide those headers (not even
speaking about relying on the headers provided by hte host distribution,
because they might well not be installed at all).
Also, we can not rely on another package to provide those headers,
because we can only have one provider enabled in any configuration.
The Khronos group provides such headers, and they are the reference
headers, but we can not realy use them:
- most of them are not packaged: they are not versioned and not
provided in a tarball, but as separately downloadable files;
- those headers are anyway incomplete: there are headers not provided
by Khronos, like GL.h
Instead, we rely on mesa3d to provide those headers: mesa3d has all the
headers we need.
Modifying the existing mesa3d package would not be easy; we'd have to
differentiate whther we need only the headers or the full package. The
meas3d Config.in and .mk are already quite non-trivial that adding such
a feature would render them even more illegible.
So, we introduce mea3d-headers as a new package, that is in fact just
mesa3d with a much simplified Config.in and .mk, that other OpenXXX
providers may select if they do not provide the OpenXXX headers.
Note: we're not installing GLES3 headers, because what Buildroot
currently calls libgles is in fact libgles2; we have no way to specify
that we have libgles3. So, we just install headers for GLES and GLES2.
[Thomas:
- Wrap Config.in help text to a reasonable length.
- Don't rely on mesa3d to provide mesa3d-headers: they should be
mutually exclusive. Instead, error out if both packages are
selected.
- Take into account the update of mesa3d to 10.4.5.
- Don't copy each header file individually, use a cp -dpfr call to
copy entires header files directories.]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
--
v2: - rebased patch from micro1183: http://patchwork.ozlabs.org/patch/398858/
- removed support for r300 & radeonsi because they need llvm support
which is not provided by buildroot
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thanks to commit 2dde40081c
("package/mesa3d: Refactor XA support to prepare support for ATI
drivers"), we now have the blind option BR2_PACKAGE_MESA3D_NEEDS_XA
that indicates whether XA support is needed. This allows to switch to
use positive logic in the test for XA in mesa3d.mk, which this commit
does.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
[Thomas:
- move the new blind option next to the other existing blind options
in the package.
- edit the commit log to remove the changelog.]
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Since a while, the semantic of BR2_PREFER_STATIC_LIB has been changed
from "prefer static libraries when possible" to "use only static
libraries". The former semantic didn't make much sense, since the user
had absolutely no control/idea of which package would use static
libraries, and which packages would not. Therefore, for quite some
time, we have been starting to enforce that BR2_PREFER_STATIC_LIB
should really build everything with static libraries.
As a consequence, this patch renames BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS, and adjust the Config.in option accordingly.
This also helps preparing the addition of other options to select
shared, shared+static or just static.
Note that we have verified that this commit can be reproduced by
simply doing a global rename of BR2_PREFER_STATIC_LIB to
BR2_STATIC_LIBS plus adding BR2_PREFER_STATIC_LIB to Config.in.legacy.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
To be consistent with the recent change of FOO_MAKE_OPT into FOO_MAKE_OPTS,
make the same change for FOO_CONF_OPT.
Sed command used:
find * -type f | xargs sed -i 's#_CONF_OPT\>#&S#g'
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
If no dri drivers are enabled, then mesa shouldn't get built with dri
support.
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Acked-by: Bernd Kuhls <bernd.kuhls@t-online.de>
xlib_libXxf86vm is an optional dependency for the DRI drivers,
quote from mesa3d/configure.ac:
# add xf86vidmode if available
PKG_CHECK_MODULES([XF86VIDMODE], [xxf86vm], HAVE_XF86VIDMODE=yes, HAVE_XF86VIDMODE=no)
if test "$HAVE_XF86VIDMODE" = yes ; then
dri_modules="$dri_modules xxf86vm"
fi
Add the package as an optional dependency to have reproducable builds.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The help entry for the i965 DRI driver states that it supports alll
Intel GPUs. That's not true, as at least the i915 series is not handled
by this driver, but by a separate one.
Fix the help text accordingly; remove the useless second part of the
help text (which does not mean much for Buildroot.)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
mesa3d does not depend on the xorg server as such, only on X libraries.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
DRI3 support is optional in mesa3d, but mesa3d expects it by default,
so add configure options to disable it when necessary and add the
needed dependencies for DRI3 support. Fixes:
===============================
checking for DRI3PROTO... no
configure: error: Package requirements (dri3proto >= 1.0) were not met:
checking for PRESENTPROTO... no
configure: error: Package requirements (presentproto >= 1.0) were not met:
configure: error: Package requirements (x11 xext xdamage xfixes x11-xcb xcb-glx >= 1.8.1
xcb-dri2 >= 1.8 xcb-dri3 xcb-present xcb-sync xshmfence >= 1.1) were not met:
Package xshmfence was not found in the pkg-config search path.
===============================
This defconfig was broken and fixed by this patch:
BR2_TOOLCHAIN_EXTERNAL=y
BR2_ROOTFS_DEVICE_CREATION_DYNAMIC_EUDEV=y
BR2_PACKAGE_MESA3D=y
BR2_PACKAGE_MESA3D_DRI_DRIVER_I965=y
BR2_PACKAGE_XORG7=y
BR2_PACKAGE_XSERVER_XORG_SERVER=y
BR2_PACKAGE_XSERVER_XORG_SERVER_MODULAR=y
BR2_PACKAGE_XPROTO_DRI3PROTO=y
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Rename the prompt for mesa3d so that it matches what we usually do
for prompts of packages: just name the package in lower case.
This will help generate nicer tables in the generated packages list,
both in existing tables, and in the upcoming table of virtual packages.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Reviewed-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Strictly speaking, linuxthreads (new) should be enough, since it includes
pthread_barrier_* implementation. However, we currently have no clean way to
distinguish between LT and LT.old.
Fixes:
http://autobuild.buildroot.net/results/66a/66a9d2c664e0a9b2b0c51b998c72c2ceda90ff9b/
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, we only pass --enable-opengl is at least one DRI driver is
enabled, since full OpenGL is only possible with a DRI driver (and the
X.Org stack). Otherwise, we pass --disable-opengl on the assumption that
OpenGL is not possible.
But mesa3d's ./configure is a bit weird: enabling OpenGL-ES and diabling
full OpenGL is an error (see autobuild failure below).
It turns out that, if there is no DRI driver enabled, but --enable-opengl
is passed, ./configure will behave properly wrt OpenGL-ES, and will not
build the full OpenGL libgl.
Thanks to Paul for explaining this.
Fixes:
http://autobuild.buildroot.net/results/61c/61c1c566dc0e829cb663ca30b1fd6cf9cc6cd931/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Make mesa3d a provider for full OpenGL, as soon as a DRI driver is enabled.
Full OpenGL is only possible when:
- a DRI driver is enabled,
- and X.Org is enabled
Since DRI driver in fact depend on X.Org being enabled in the first place,
we can safely declare mesa3d as a full openGL provider as soon as at least
one DRI driver is enabled.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Bernd Kuhls <berndkuhls@hotmail.com>
Cc: Paul Cercueil <paul@crapouillou.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Full OpenGL is only provided when:
- a DRI driver is enabled,
- and X.Org is enabled
Since DRI driver depend on X.Org being selected, this means that we
can (have to) enable full OpenGL as soon as a DRI driver is enabled.
On the other hand, Gallium drivers, which currently do enable full
OpenGL, only really provide OpenGL EGL and GLES, not full OpenGL.
So we exclude Gallium drivers when checking whether to enable full
OpenGL in mesa3d.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: Bernd Kuhls <berndkuhls@hotmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Currently, full-OpenGL is enabled by checking that at least one driver
is enabled. This is done by checking that the just-constructed lists of
drivers are not empty.
But we already have a variable that is set to 'y' as soon as a driver
is selected:
- DRI drivers select BR2_PACKAGE_MESA3D_DRI_DRIVER
- Gallium drivers select BR2_PACKAGE_MESA3D_GALLIUM_DRIVER
- both BR2_PACKAGE_MESA3D_DRI_DRIVER and BR2_PACKAGE_MESA3D_GALLIUM_DRIVER
select BR2_PACKAGE_MESA3D_DRIVER
So, BR2_PACKAGE_MESA3D_DRIVER is set to 'y' as soon as at least one
driver is selected. We can use that variable rather than comparing the
lists of drivers.
Also, rearrange the code in a more logical way, by moving the code that
enables OpenGL nearer to the code enabling EGL and GLES.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: Bernd Kuhls <berndkuhls@hotmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
OpenGL EGL needs udev support, so add a comment stating so.
Also, reword the OpenGL EGL prompt to be in the same format as the
OpenGL ES prompt (and like the full OpenGL prompt that will shortly
be added, too.)
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: Bernd Kuhls <berndkuhls@hotmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
It does not make sense to build DRI drivers without X.org.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Paul Cercueil <paul@crapouillou.net>
Cc: Bernd Kuhls <berndkuhls@hotmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>