* [meta-fsl-arm][PATCH v4 1/9] gpu-viv-bin-mx6q: Upgrade to 1.1.0
2013-02-12 21:58 [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade Otavio Salvador
@ 2013-02-12 21:58 ` Otavio Salvador
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 2/9] xf86-video-imxfb-vivante: " Otavio Salvador
` (8 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Otavio Salvador @ 2013-02-12 21:58 UTC (permalink / raw)
To: meta-freescale Mailing List; +Cc: Otavio Salvador
This drops the DirectFB files while we do not have support for it and
ensure all packages need to choose the proper backend to link to as we
remove the generic link pointing to a default backend.
Change-Id: I6f1fa9b4426b0855b5d5ea6f04979081506e0d41
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
.../gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc | 31 +++++++++++-----------
| 19 ++++++-------
...-mx6q_12.09.01.bb => gpu-viv-bin-mx6q_1.1.0.bb} | 5 ++--
3 files changed, 27 insertions(+), 28 deletions(-)
rename recipes-graphics/gpu-viv-bin-mx6q/{gpu-viv-bin-mx6q_12.09.01.bb => gpu-viv-bin-mx6q_1.1.0.bb} (51%)
diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
index c7e3eab..8239697 100644
--- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
+++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
@@ -4,7 +4,7 @@
DESCRIPTION = "GPU driver and apps for imx6"
SECTION = "libs"
LICENSE = "Proprietary"
-LIC_FILES_CHKSUM = "file://usr/include/gc_vdk.h;endline=11;md5=092bc28e13d678ceaebe1a40559275fb"
+LIC_FILES_CHKSUM = "file://usr/include/gc_vdk.h;endline=11;md5=c831981a5cbb2673318b77fb2f07014c"
PROVIDES += "virtual/libgal-x11 virtual/egl virtual/libgles1 virtual/libgles2 libvivante-dri-mx6"
INC_PR = "r2"
@@ -40,6 +40,7 @@ INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
# FIXME: The provided binary doesn't provide soname. If in future BSP
# release the libraries are fixed, we can drop this hack.
+REALSOLIBS := "${SOLIBS}"
SOLIBS = "${SOLIBSDEV}"
# FIXME: All binaries lack GNU_HASH in elf binary but as we don't have
@@ -54,16 +55,22 @@ do_install () {
install -d ${D}${libdir}/dri
install -d ${D}${includedir}
- cp ${S}/usr/lib/*.so ${D}${libdir}
- cp -axr ${S}/usr/include/* ${D}${includedir}
-
- cp -axr ${S}/opt ${D}
-
- # Move DRI library to proper path
- mv ${D}${libdir}/vivante_dri.so ${D}${libdir}/dri
+ cp -rP ${S}/usr/lib/* ${D}${libdir}
+ cp -rP ${S}/usr/include/* ${D}${includedir}
+ cp -rP ${S}/opt ${D}
find ${D}${libdir} -type f -exec chmod 644 {} \;
find ${D}${includedir} -type f -exec chmod 644 {} \;
+
+ # FIXME: Drop default library as we need to explicit link to one
+ # of supported backends
+ rm ${D}${libdir}/libEGL.so \
+ ${D}${libdir}/libGAL.so \
+ ${D}${libdir}/libVIVANTE.so
+
+ # FIXME: Drop directfb backport as 1.4 version is not supported in Yocto
+ rm -r ${D}${libdir}/directfb-1.4-0 \
+ ${D}${libdir}/*-dfb.so
}
S = "${WORKDIR}/${PN}-${PV}"
@@ -77,9 +84,7 @@ FILES_libclc-mx6 = "${libdir}/libCLC${SOLIBS}"
FILES_libclc-mx6-dev = "${includedir}/CL ${libdir}/libCLC${SOLIBSDEV}"
FILES_libclc-mx6-dbg = "${libdir}/.debug/libCLC${SOLIBS}"
-FILES_libegl-common-mx6 = "${libdir}/libEGL${SOLIBS}"
FILES_libegl-common-mx6-dev = "${includedir}/EGL ${libdir}/libEGL${SOLIBSDEV}"
-FILES_libegl-common-mx6-dbg = "${libdir}/.debug/libEGL${SOLIBS}"
FILES_libegl-fb-mx6 = "${libdir}/libEGL-fb${SOLIBS}"
FILES_libegl-fb-mx6-dev = "${libdir}/libEGL-fb${SOLIBSDEV}"
@@ -89,9 +94,7 @@ FILES_libegl-x11-mx6 = "${libdir}/libEGL-x11${SOLIBS}"
FILES_libegl-x11-mx6-dev = "${libdir}/libEGL-x11${SOLIBSDEV}"
FILES_libegl-x11-mx6-dbg = "${libdir}/.debug/libEGL-x11${SOLIBS}"
-FILES_libgal-common-mx6 = "${libdir}/libGAL${SOLIBS}"
FILES_libgal-common-mx6-dev = "${includedir}/HAL ${libdir}/libGAL${SOLIBSDEV}"
-FILES_libgal-common-mx6-dbg = "${libdir}/.debug/libGAL${SOLIBS}"
FILES_libgal-fb-mx6 = "${libdir}/libGAL-fb${SOLIBS}"
FILES_libgal-fb-mx6-dev = "${libdir}/libGAL-fb${SOLIBSDEV}"
@@ -109,7 +112,7 @@ FILES_libgles2-mx6 = "${libdir}/libGLESv2${SOLIBS}"
FILES_libgles2-mx6-dev = "${includedir}/GLES2 ${libdir}/libGLESv2${SOLIBSDEV}"
FILES_libgles2-mx6-dbg = "${libdir}/.debug/libGLESv2${SOLIBS}"
-FILES_libgl-mx6 = "${libdir}/libGL${SOLIBS}"
+FILES_libgl-mx6 = "${libdir}/libGL${REALSOLIBS}"
FILES_libgl-mx6-dev = "${includedir}/GL ${libdir}/libGL${SOLIBSDEV}"
FILES_libgl-mx6-dbg = "${libdir}/.debug/libGL${SOLIBS}"
@@ -129,9 +132,7 @@ FILES_libvdk-mx6 = "${libdir}/libVDK${SOLIBS}"
FILES_libvdk-mx6-dev = "${includedir}/*vdk.h ${libdir}/libVDK${SOLIBSDEV}"
FILES_libvdk-mx6-dbg = "${libdir}/.debug/libVDK${SOLIBS}"
-FILES_libvivante-common-mx6 = "${libdir}/libVIVANTE${SOLIBS}"
FILES_libvivante-common-mx6-dev = "${includedir}/HAL ${libdir}/libVIVANTE${SOLIBSDEV}"
-FILES_libvivante-common-mx6-dbg = "${libdir}/.debug/libVIVANTE${SOLIBS}"
FILES_libvivante-fb-mx6 = "${libdir}/libVIVANTE-fb${SOLIBS}"
FILES_libvivante-fb-mx6-dev = "${libdir}/libVIVANTE-fb${SOLIBSDEV}"
--git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q/0001-change-header-path-to-HAL.patch b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q/0001-change-header-path-to-HAL.patch
index 31fad1e..dc91d7c 100644
--- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q/0001-change-header-path-to-HAL.patch
+++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q/0001-change-header-path-to-HAL.patch
@@ -15,19 +15,16 @@ Signed-off-by: Jeremy Stashluk <jstashluk@dekaresearch.com>
usr/include/gc_vdk_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
-diff --git a/usr/include/gc_vdk_types.h b/usr/include/gc_vdk_types.h
-index 11514f9..8e3dfe4 100644
---- a/usr/include/gc_vdk_types.h
-+++ b/usr/include/gc_vdk_types.h
-@@ -26,7 +26,7 @@ extern "C" {
+Index: gpu-viv-bin-mx6q-1.1.0/usr/include/gc_vdk_types.h
+===================================================================
+--- gpu-viv-bin-mx6q-1.1.0.orig/usr/include/gc_vdk_types.h
++++ gpu-viv-bin-mx6q-1.1.0/usr/include/gc_vdk_types.h
+@@ -39,7 +39,7 @@ extern "C" {
#endif
#include <EGL/egl.h>
--#include "gc_hal_eglplatform.h"
-+#include <HAL/gc_hal_eglplatform.h>
+-#include "gc_hal_eglplatform_type.h"
++#include <HAL/gc_hal_eglplatform_type.h>
+
/*******************************************************************************
- ** vdkPrivate. *****************************************************************
---
-1.7.9.5
-
diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_12.09.01.bb b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_1.1.0.bb
similarity index 51%
rename from recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_12.09.01.bb
rename to recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_1.1.0.bb
index c54ad19..3de9555 100644
--- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_12.09.01.bb
+++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_1.1.0.bb
@@ -2,8 +2,9 @@
# Released under the MIT license (see COPYING.MIT for the terms)
PR = "${INC_PR}.0"
+PE = "1"
include gpu-viv-bin-mx6q.inc
-SRC_URI[md5sum] = "9f2c43b6eae468df6cc6fd75efd00bc5"
-SRC_URI[sha256sum] = "2cec10c1d69bce75a7c2a4482eb3ed29b171578c3b01c5b4ef2cc868ca327330"
+SRC_URI[md5sum] = "60f4ba65f557fc63fde6dacfeef205a8"
+SRC_URI[sha256sum] = "4238b72a6dad2d075d159bb1e86fb68bbed7c27894ce82c546a8e7c58ae5d683"
--
1.8.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [meta-fsl-arm][PATCH v4 2/9] xf86-video-imxfb-vivante: Upgrade to 1.1.0
2013-02-12 21:58 [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade Otavio Salvador
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 1/9] gpu-viv-bin-mx6q: Upgrade to 1.1.0 Otavio Salvador
@ 2013-02-12 21:58 ` Otavio Salvador
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 3/9] gpu-viv-bin-mx6q: remove xlib undef macros Otavio Salvador
` (7 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Otavio Salvador @ 2013-02-12 21:58 UTC (permalink / raw)
To: meta-freescale Mailing List; +Cc: Otavio Salvador
The new version packages Xorg driver and DRI source in same source
package however for our use case this is worse so we workaround this
packaging both separate.
Change-Id: I66fdd5cd5e8b1b860bc065dd7f5f2a3cc87a43ed
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
.../Makefile.am-remove-prefixed-include-path.patch | 2 +
.../fix-vivante-compile.patch | 86 ++++++++++------------
....09.01.bb => xf86-video-imxfb-vivante_1.1.0.bb} | 12 +--
3 files changed, 48 insertions(+), 52 deletions(-)
rename recipes-graphics/xorg-driver/{xf86-video-imxfb-vivante_12.09.01.bb => xf86-video-imxfb-vivante_1.1.0.bb} (74%)
diff --git a/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/Makefile.am-remove-prefixed-include-path.patch b/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/Makefile.am-remove-prefixed-include-path.patch
index 4354ae4..c44f01a 100644
--- a/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/Makefile.am-remove-prefixed-include-path.patch
+++ b/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/Makefile.am-remove-prefixed-include-path.patch
@@ -6,6 +6,8 @@ Subject: [PATCH] Makefile.am remove prefixed include path
* Remove prefixed include path, use ${STAGING_INCDIR}
to locate drm headers.
+Upstream-Status: Pending
+
Signed-off-by: Adrian Alonso <aalonso00@gmail.com>
---
src/Makefile.am | 2 +-
diff --git a/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/fix-vivante-compile.patch b/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/fix-vivante-compile.patch
index d92acce..bdbd2eb 100644
--- a/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/fix-vivante-compile.patch
+++ b/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante/fix-vivante-compile.patch
@@ -4,10 +4,10 @@ versions of the X server.
Upstream-Status: Pending
-Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_dri.h
+Index: xserver-xorg-video-imx-viv-1.1.0/src/vivante_fbdev/vivante_dri.h
===================================================================
---- xserver-xorg-video-imx-viv-12.09.01.orig/src/vivante_fbdev/vivante_dri.h
-+++ xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_dri.h
+--- xserver-xorg-video-imx-viv-1.1.0.orig/src/vivante_fbdev/vivante_dri.h
++++ xserver-xorg-video-imx-viv-1.1.0/src/vivante_fbdev/vivante_dri.h
@@ -67,7 +67,7 @@ typedef struct _vvtDeviceInfoRec {
} vvtDeviceInfo;
@@ -17,19 +17,11 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_dri.h
Bool VivDRIFinishScreenInit(ScreenPtr pScreen);
#endif /* _VIVANTE_DRI_H_ */
-Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_driver.c
+Index: xserver-xorg-video-imx-viv-1.1.0/src/vivante_fbdev/vivante_fbdev_driver.c
===================================================================
---- xserver-xorg-video-imx-viv-12.09.01.orig/src/vivante_fbdev/vivante_fbdev_driver.c
-+++ xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_driver.c
-@@ -19,7 +19,6 @@
- *****************************************************************************/
-
-
--
- #include "vivante_common.h"
- #include "vivante.h"
- #include "vivante_exa.h"
-@@ -54,9 +53,8 @@ static const OptionInfoRec *VivAvailable
+--- xserver-xorg-video-imx-viv-1.1.0.orig/src/vivante_fbdev/vivante_fbdev_driver.c
++++ xserver-xorg-video-imx-viv-1.1.0/src/vivante_fbdev/vivante_fbdev_driver.c
+@@ -53,9 +53,8 @@ static const OptionInfoRec *VivAvailable
static void VivIdentify(int flags);
static Bool VivProbe(DriverPtr drv, int flags);
static Bool VivPreInit(ScrnInfoPtr pScrn, int flags);
@@ -41,7 +33,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
static Bool VivDriverFunc(ScrnInfoPtr pScrn, xorgDriverFuncOp op,
pointer ptr);
-@@ -178,7 +176,7 @@ VivSetup(pointer module, pointer opts, i
+@@ -175,7 +174,7 @@ VivSetup(pointer module, pointer opts, i
static Bool InitExaLayer(ScreenPtr pScreen) {
ExaDriverPtr pExa;
@@ -50,7 +42,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
VivPtr pViv = GET_VIV_PTR(pScrn);
TRACE_ENTER();
-@@ -274,7 +272,7 @@ static Bool InitExaLayer(ScreenPtr pScre
+@@ -258,7 +257,7 @@ static Bool InitExaLayer(ScreenPtr pScre
}
static Bool DestroyExaLayer(ScreenPtr pScreen) {
@@ -59,7 +51,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
VivPtr pViv = GET_VIV_PTR(pScrn);
TRACE_ENTER();
xf86DrvMsg(pScreen->myNum, X_INFO, "Shutdown EXA\n");
-@@ -590,7 +588,7 @@ VivPreInit(ScrnInfoPtr pScrn, int flags)
+@@ -570,7 +569,7 @@ VivPreInit(ScrnInfoPtr pScrn, int flags)
static Bool
VivCreateScreenResources(ScreenPtr pScreen) {
PixmapPtr pPixmap;
@@ -68,7 +60,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
VivPtr fPtr = GET_VIV_PTR(pScrn);
Bool ret;
-@@ -612,8 +610,8 @@ VivCreateScreenResources(ScreenPtr pScre
+@@ -592,8 +591,8 @@ VivCreateScreenResources(ScreenPtr pScre
}
static Bool
@@ -79,7 +71,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
VivPtr fPtr = GET_VIV_PTR(pScrn);
VisualPtr visual;
int init_picture = 0;
-@@ -631,7 +629,7 @@ VivScreenInit(int scrnIndex, ScreenPtr p
+@@ -611,7 +610,7 @@ VivScreenInit(int scrnIndex, ScreenPtr p
/*Mapping the Video memory*/
if (NULL == (fPtr->mFB.mFBMemory = fbdevHWMapVidmem(pScrn))) {
@@ -88,7 +80,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
" failed\n");
TRACE_EXIT(FALSE);
}
-@@ -647,11 +645,11 @@ VivScreenInit(int scrnIndex, ScreenPtr p
+@@ -626,17 +625,17 @@ VivScreenInit(int scrnIndex, ScreenPtr p
/*Init the hardware in current mode*/
if (!fbdevHWModeInit(pScrn, pScrn->currentMode)) {
@@ -100,9 +92,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
- fbdevHWAdjustFrame(scrnIndex, 0, 0, 0);
+ fbdevHWAdjustFrame(FBDEVHWADJUSTFRAME_ARGS(0, 0));
-
-
-@@ -659,7 +657,7 @@ VivScreenInit(int scrnIndex, ScreenPtr p
+ /* mi layer */
miClearVisualTypes();
if (pScrn->bitsPerPixel > 8) {
if (!miSetVisualTypes(pScrn->depth, TrueColorMask, pScrn->rgbBits, TrueColor)) {
@@ -111,7 +101,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
" for %d bits per pixel [1]\n",
pScrn->bitsPerPixel);
TRACE_EXIT(FALSE);
-@@ -668,14 +666,14 @@ VivScreenInit(int scrnIndex, ScreenPtr p
+@@ -645,14 +644,14 @@ VivScreenInit(int scrnIndex, ScreenPtr p
if (!miSetVisualTypes(pScrn->depth,
miGetDefaultVisualMask(pScrn->depth),
pScrn->rgbBits, pScrn->defaultVisual)) {
@@ -128,7 +118,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
return FALSE;
}
-@@ -684,14 +682,14 @@ VivScreenInit(int scrnIndex, ScreenPtr p
+@@ -660,14 +659,14 @@ VivScreenInit(int scrnIndex, ScreenPtr p
pScrn->displayWidth = fbdevHWGetLineLength(pScrn) /
(pScrn->bitsPerPixel / 8);
if (pScrn->displayWidth != pScrn->virtualX) {
@@ -145,7 +135,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
"FB Start = %p FB Base = %p FB Offset = %p\n",
fPtr->mFB.mFBStart, fPtr->mFB.mFBMemory, fPtr->mFB.mFBOffset);
-@@ -708,7 +706,7 @@ VivScreenInit(int scrnIndex, ScreenPtr p
+@@ -684,7 +683,7 @@ VivScreenInit(int scrnIndex, ScreenPtr p
init_picture = 1;
break;
default:
@@ -154,7 +144,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
"internal error: invalid number of bits per"
" pixel (%d) encountered in"
" VivScreenInit()\n", pScrn->bitsPerPixel);
-@@ -740,7 +738,7 @@ VivScreenInit(int scrnIndex, ScreenPtr p
+@@ -716,7 +715,7 @@ VivScreenInit(int scrnIndex, ScreenPtr p
if (fPtr->mFakeExa.mUseExaFlag) {
TRACE_INFO("Loading EXA");
if (!InitExaLayer(pScreen)) {
@@ -163,7 +153,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
"internal error: initExaLayer failed "
"in VivScreenInit()\n");
}
-@@ -759,7 +757,7 @@ VivScreenInit(int scrnIndex, ScreenPtr p
+@@ -733,7 +732,7 @@ VivScreenInit(int scrnIndex, ScreenPtr p
/* colormap */
if (!miCreateDefColormap(pScreen)) {
@@ -172,7 +162,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
"internal error: miCreateDefColormap failed "
"in VivScreenInit()\n");
TRACE_EXIT(FALSE);
-@@ -799,18 +797,18 @@ VivScreenInit(int scrnIndex, ScreenPtr p
+@@ -775,20 +774,20 @@ VivScreenInit(int scrnIndex, ScreenPtr p
}
static Bool
@@ -184,8 +174,10 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
Bool ret = FALSE;
TRACE_ENTER();
+ #ifndef DISABLE_VIVANTE_DRI
- VivDRICloseScreen(pScreen);
+ VivDRICloseScreen(CLOSE_SCREEN_ARGS);
+ #endif
if (fPtr->mFakeExa.mUseExaFlag) {
DEBUGP("UnLoading EXA");
@@ -195,7 +187,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
"internal error: DestroyExaLayer failed "
"in VivCloseScreen()\n");
}
-@@ -823,7 +821,7 @@ VivCloseScreen(int scrnIndex, ScreenPtr
+@@ -801,7 +800,7 @@ VivCloseScreen(int scrnIndex, ScreenPtr
pScreen->CreateScreenResources = fPtr->CreateScreenResources;
pScreen->CloseScreen = fPtr->CloseScreen;
@@ -204,10 +196,10 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_fbdev_drive
TRACE_EXIT(ret);
}
-Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_util/compat-api.h
+Index: xserver-xorg-video-imx-viv-1.1.0/src/vivante_util/compat-api.h
===================================================================
--- /dev/null
-+++ xserver-xorg-video-imx-viv-12.09.01/src/vivante_util/compat-api.h
++++ xserver-xorg-video-imx-viv-1.1.0/src/vivante_util/compat-api.h
@@ -0,0 +1,106 @@
+/*
+ * Copyright 2012 Red Hat, Inc.
@@ -315,11 +307,11 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_util/compat-api.h
+#endif
+
+#endif
-Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_util/vivante_common.h
+Index: xserver-xorg-video-imx-viv-1.1.0/src/vivante_util/vivante_common.h
===================================================================
---- xserver-xorg-video-imx-viv-12.09.01.orig/src/vivante_util/vivante_common.h
-+++ xserver-xorg-video-imx-viv-12.09.01/src/vivante_util/vivante_common.h
-@@ -76,6 +76,9 @@ extern "C" {
+--- xserver-xorg-video-imx-viv-1.1.0.orig/src/vivante_util/vivante_common.h
++++ xserver-xorg-video-imx-viv-1.1.0/src/vivante_util/vivante_common.h
+@@ -69,6 +69,9 @@ extern "C" {
#include "xf86Crtc.h"
#include "cursorstr.h"
@@ -329,11 +321,11 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_util/vivante_common.h
/*Debug*/
#include "vivante_debug.h"
-Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante.h
+Index: xserver-xorg-video-imx-viv-1.1.0/src/vivante_fbdev/vivante.h
===================================================================
---- xserver-xorg-video-imx-viv-12.09.01.orig/src/vivante_fbdev/vivante.h
-+++ xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante.h
-@@ -99,11 +99,11 @@ extern "C" {
+--- xserver-xorg-video-imx-viv-1.1.0.orig/src/vivante_fbdev/vivante.h
++++ xserver-xorg-video-imx-viv-1.1.0/src/vivante_fbdev/vivante.h
+@@ -92,11 +92,11 @@ extern "C" {
#define GET_VIV_PTR(p) ((VivPtr)((p)->driverPrivate))
#define VIVPTR_FROM_PIXMAP(x) \
@@ -348,11 +340,11 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante.h
/********************************************************************************
*
-Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_dri.c
+Index: xserver-xorg-video-imx-viv-1.1.0/src/vivante_fbdev/vivante_dri.c
===================================================================
---- xserver-xorg-video-imx-viv-12.09.01.orig/src/vivante_fbdev/vivante_dri.c
-+++ xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_dri.c
-@@ -49,7 +49,7 @@ VivDestroyContext(ScreenPtr pScreen, drm
+--- xserver-xorg-video-imx-viv-1.1.0.orig/src/vivante_fbdev/vivante_dri.c
++++ xserver-xorg-video-imx-viv-1.1.0/src/vivante_fbdev/vivante_dri.c
+@@ -51,7 +51,7 @@ VivDestroyContext(ScreenPtr pScreen, drm
Bool
VivDRIFinishScreenInit(ScreenPtr pScreen) {
@@ -361,7 +353,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_dri.c
VivPtr pViv = GET_VIV_PTR(pScrn);
DRIInfoPtr pDRIInfo = (DRIInfoPtr) pViv->pDRIInfo;
-@@ -79,7 +79,7 @@ VivDRIMoveBuffers(WindowPtr pParent, DDX
+@@ -81,7 +81,7 @@ VivDRIMoveBuffers(WindowPtr pParent, DDX
}
Bool VivDRIScreenInit(ScreenPtr pScreen) {
@@ -370,7 +362,7 @@ Index: xserver-xorg-video-imx-viv-12.09.01/src/vivante_fbdev/vivante_dri.c
DRIInfoPtr pDRIInfo;
VivPtr pViv = GET_VIV_PTR(pScrn);
-@@ -185,7 +185,7 @@ Bool VivDRIScreenInit(ScreenPtr pScreen)
+@@ -187,7 +187,7 @@ Bool VivDRIScreenInit(ScreenPtr pScreen)
}
void VivDRICloseScreen(ScreenPtr pScreen) {
diff --git a/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_12.09.01.bb b/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_1.1.0.bb
similarity index 74%
rename from recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_12.09.01.bb
rename to recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_1.1.0.bb
index e35080f..96fa745 100644
--- a/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_12.09.01.bb
+++ b/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_1.1.0.bb
@@ -1,9 +1,11 @@
-# Copyright (C) 2012 Freescale Semiconductor
+# Copyright (C) 2012-2013 Freescale Semiconductor
+# Copyright (C) 2012-2013 O.S. Systems Software LTDA.
# Released under the MIT license (see COPYING.MIT for the terms)
require recipes-graphics/xorg-driver/xorg-driver-video.inc
-PR = "${INC_PR}.2"
+PE = "3"
+PR = "${INC_PR}.0"
DEPENDS += "virtual/libx11 virtual/libgal-x11 gpu-viv-bin-mx6q"
@@ -12,14 +14,14 @@ LIC_FILES_CHKSUM = "file://src/vivante_fbdev/vivante.h;endline=19;md5=93a322f91e
SRC_URI = "${FSL_MIRROR}/xserver-xorg-video-imx-viv-${PV}.tar.gz \
file://fix-vivante-compile.patch \
file://Makefile.am-remove-prefixed-include-path.patch"
-SRC_URI[md5sum] = "1948119717aa01bed1f630be9ee7a708"
-SRC_URI[sha256sum] = "5b3be4b426d2d2803554df9e4d8919d1f9d17659c3153c71c6529f43c37e6ed1"
+SRC_URI[md5sum] = "d872365c046738628a7016343ffdb79a"
+SRC_URI[sha256sum] = "d53216d5f9e3f7803983ac1577d83985dfda33145e4711300f4ad5cbbe28e32d"
EXTRA_OECONF_armv7a = " --enable-neon --disable-static"
CFLAGS += " -I${STAGING_INCDIR}/xorg -I${STAGING_INCDIR}/drm"
LDFLAGS += "-lm -ldl -lX11 -lGAL-x11"
-S = "${WORKDIR}/xserver-xorg-video-imx-viv-${PV}"
+S = "${WORKDIR}/xserver-xorg-video-imx-viv-${PV}/EXA/"
do_install_append () {
install -d ${D}${includedir}
--
1.8.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [meta-fsl-arm][PATCH v4 3/9] gpu-viv-bin-mx6q: remove xlib undef macros
2013-02-12 21:58 [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade Otavio Salvador
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 1/9] gpu-viv-bin-mx6q: Upgrade to 1.1.0 Otavio Salvador
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 2/9] xf86-video-imxfb-vivante: " Otavio Salvador
@ 2013-02-12 21:58 ` Otavio Salvador
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 4/9] gpu-viv-bin-mx6q: group libs based on backend Otavio Salvador
` (6 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Otavio Salvador @ 2013-02-12 21:58 UTC (permalink / raw)
To: meta-freescale Mailing List
From: Adrian Alonso <aalonso00@gmail.com>
* Remove xlib udef macros
* Distrubuted header files rename some badly named X defines
but this breaks compilation on programs that expect this
macros.
* Bump PR
Change-Id: Iaedbb4506be5f4a641411d9888aa5338b574b7a4
Signed-off-by: Adrian Alonso <aalonso00@gmail.com>
---
.../gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc | 3 +-
.../gc_hal_eglplatform-remove-xlib-undefs.patch | 34 ++++++++++++++++++++++
2 files changed, 36 insertions(+), 1 deletion(-)
create mode 100644 recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q/gc_hal_eglplatform-remove-xlib-undefs.patch
diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
index 8239697..3105a60 100644
--- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
+++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
@@ -7,12 +7,13 @@ LICENSE = "Proprietary"
LIC_FILES_CHKSUM = "file://usr/include/gc_vdk.h;endline=11;md5=c831981a5cbb2673318b77fb2f07014c"
PROVIDES += "virtual/libgal-x11 virtual/egl virtual/libgles1 virtual/libgles2 libvivante-dri-mx6"
-INC_PR = "r2"
+INC_PR = "r3"
inherit fsl-eula-unpack
SRC_URI = "${FSL_MIRROR}/${PN}-${PV}.bin;fsl-eula=true \
file://0001-change-header-path-to-HAL.patch \
+ file://gc_hal_eglplatform-remove-xlib-undefs.patch \
"
PACKAGES =+ "libclc-mx6 libclc-mx6-dev libclc-mx6-dbg \
diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q/gc_hal_eglplatform-remove-xlib-undefs.patch b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q/gc_hal_eglplatform-remove-xlib-undefs.patch
new file mode 100644
index 0000000..732a073
--- /dev/null
+++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q/gc_hal_eglplatform-remove-xlib-undefs.patch
@@ -0,0 +1,34 @@
+From c59f9640d185759208f9d55a93b6602936dcb5e8 Mon Sep 17 00:00:00 2001
+From: Adrian Alonso <aalonso00@gmail.com>
+Date: Sat, 26 Jan 2013 17:52:04 -0600
+Subject: [PATCH 2/2] gc_hal_eglplatform: remove xlib undefs
+
+* Remove header undefs for Always and Status definitions
+
+Signed-off-by: Adrian Alonso <aalonso00@gmail.com>
+---
+ usr/include/HAL/gc_hal_eglplatform.h | 3 ---
+ 1 file changed, 3 deletions(-)
+
+diff --git a/usr/include/HAL/gc_hal_eglplatform.h b/usr/include/HAL/gc_hal_eglplatform.h
+index a968fe7..e80c65a 100644
+--- a/usr/include/HAL/gc_hal_eglplatform.h
++++ b/usr/include/HAL/gc_hal_eglplatform.h
+@@ -341,14 +341,11 @@ typedef Pixmap HALNativePixmapType;
+ /* Rename some badly named X defines. */
+ #ifdef Status
+ # define XStatus int
+-# undef Status
+ #endif
+ #ifdef Always
+ # define XAlways 2
+-# undef Always
+ #endif
+ #ifdef CurrentTime
+-# undef CurrentTime
+ # define XCurrentTime 0
+ #endif
+
+--
+1.8.1
+
--
1.8.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [meta-fsl-arm][PATCH v4 4/9] gpu-viv-bin-mx6q: group libs based on backend
2013-02-12 21:58 [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade Otavio Salvador
` (2 preceding siblings ...)
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 3/9] gpu-viv-bin-mx6q: remove xlib undef macros Otavio Salvador
@ 2013-02-12 21:58 ` Otavio Salvador
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 5/9] gpu-viv-bin-mx6q: Add dri.pc Otavio Salvador
` (5 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Otavio Salvador @ 2013-02-12 21:58 UTC (permalink / raw)
To: meta-freescale Mailing List; +Cc: Otavio Salvador
From: Adrian Alonso <aalonso00@gmail.com>
* Group GPU libs based on backend
* Add GPU libs to packages depending on DISTRO_FEATURES
* Bump PR
Change-Id: I08aaee593cc18cb7cf6f3f0ef9a3aff046d87edd
Signed-off-by: Adrian Alonso <aalonso00@gmail.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
.../gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc | 71 ++++++++++++++--------
1 file changed, 46 insertions(+), 25 deletions(-)
diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
index 3105a60..7c52810 100644
--- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
+++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
@@ -5,9 +5,9 @@ DESCRIPTION = "GPU driver and apps for imx6"
SECTION = "libs"
LICENSE = "Proprietary"
LIC_FILES_CHKSUM = "file://usr/include/gc_vdk.h;endline=11;md5=c831981a5cbb2673318b77fb2f07014c"
-PROVIDES += "virtual/libgal-x11 virtual/egl virtual/libgles1 virtual/libgles2 libvivante-dri-mx6"
+PROVIDES += "virtual/libgal-x11 virtual/egl virtual/libgles1 virtual/libgles2 virtual/dri"
-INC_PR = "r3"
+INC_PR = "r5"
inherit fsl-eula-unpack
@@ -16,13 +16,18 @@ SRC_URI = "${FSL_MIRROR}/${PN}-${PV}.bin;fsl-eula=true \
file://gc_hal_eglplatform-remove-xlib-undefs.patch \
"
-PACKAGES =+ "libclc-mx6 libclc-mx6-dev libclc-mx6-dbg \
- libegl-fb-mx6 libegl-fb-mx6-dev libegl-fb-mx6-dbg \
- libegl-x11-mx6 libegl-x11-mx6-dev libegl-x11-mx6-dbg \
- libegl-common-mx6 libegl-common-mx6-dev libegl-common-mx6-dbg \
- libgal-fb-mx6 libgal-fb-mx6-dev libgal-fb-mx6-dbg \
+GPU_XLIBS = "libegl-x11-mx6 libegl-x11-mx6-dev libegl-x11-mx6-dbg \
libgal-x11-mx6 libgal-x11-mx6-dev libgal-x11-mx6-dbg \
- libgal-common-mx6 libgal-common-mx6-dev libgal-common-mx6-dbg \
+ libvivante-x11-mx6 libvivante-x11-mx6-dev libvivante-x11-mx6-dbg \
+ libvivante-dri-mx6 libvivante-dri-mx6-dev libvivante-dri-mx6-dbg \
+ "
+
+GPU_DFBLIBS = "libegl-dfb-mx6 libegl-dfb-mx6-dev libegl-dfb-mx6-dbg \
+ libgal-dfb-mx6 libgal-dfb-mx6-dev libgal-dfb-mx6-dbg \
+ libvivante-dfb-mx6 libvivante-dfb-mx6-dev libvivante-dfb-mx6-dbg \
+ "
+
+PACKAGES =+ "libclc-mx6 libclc-mx6-dev libclc-mx6-dbg \
libgles-mx6 libgles-mx6-dev libgles-mx6-dbg \
libgles2-mx6 libgles2-mx6-dev libgles2-mx6-dbg \
libgl-mx6 libgl-mx6-dev libgl-mx6-dbg \
@@ -30,12 +35,16 @@ PACKAGES =+ "libclc-mx6 libclc-mx6-dev libclc-mx6-dbg \
libopencl-mx6 libopencl-mx6-dev libopencl-mx6-dbg \
libopenvg-mx6 libopenvg-mx6-dev libopenvg-mx6-dbg \
libvdk-mx6 libvdk-mx6-dev libvdk-mx6-dbg \
- libvivante-x11-mx6 libvivante-x11-mx6-dev libvivante-x11-mx6-dbg \
+ libegl-fb-mx6 libegl-fb-mx6-dev libegl-fb-mx6-dbg \
+ libgal-fb-mx6 libgal-fb-mx6-dev libgal-fb-mx6-dbg \
libvivante-fb-mx6 libvivante-fb-mx6-dev libvivante-fb-mx6-dbg \
- libvivante-dri-mx6 libvivante-dri-mx6-dev libvivante-dri-mx6-dbg \
- libvivante-common-mx6 libvivante-common-mx6-dev libvivante-common-mx6-dbg \
+ ${@base_contains("DISTRO_FEATURES", "x11", "${GPU_XLIBS}", "", d)} \
+ ${@base_contains("DISTRO_FEATURES", "directfb", "${GPU_DFBLIBS}", "", d)} \
"
+KEEP_XLIBS = "${@base_contains("DISTRO_FEATURES", "x11", "yes", "no", d)}"
+KEEP_DFBLIBS = "${@base_contains("DISTRO_FEATURES", "directfb", "yes", "no", d)}"
+
# Inhibit warnings about files being stripped.
INHIBIT_PACKAGE_DEBUG_SPLIT = "1"
@@ -53,15 +62,22 @@ python __anonymous() {
}
do_install () {
- install -d ${D}${libdir}/dri
+ install -d ${D}${libdir}
install -d ${D}${includedir}
- cp -rP ${S}/usr/lib/* ${D}${libdir}
- cp -rP ${S}/usr/include/* ${D}${includedir}
- cp -rP ${S}/opt ${D}
+ cp ${S}/usr/lib/*.so ${D}${libdir}
+ cp -axr ${S}/usr/include/* ${D}${includedir}
+ cp -axr ${S}/opt ${D}
- find ${D}${libdir} -type f -exec chmod 644 {} \;
- find ${D}${includedir} -type f -exec chmod 644 {} \;
+ if [ "${KEEP_XLIBS}" = "no" ]; then
+ rm ${D}${libdir}/*-x11.so
+ else
+ install -d ${D}${libdir}/dri
+ cp -ax ${S}/usr/lib/dri/* ${D}${libdir}/dri
+ fi
+ if [ "${KEEP_DFBLIBS}" = "no" ]; then
+ rm ${D}${libdir}/*-dfb.so
+ fi
# FIXME: Drop default library as we need to explicit link to one
# of supported backends
@@ -69,9 +85,8 @@ do_install () {
${D}${libdir}/libGAL.so \
${D}${libdir}/libVIVANTE.so
- # FIXME: Drop directfb backport as 1.4 version is not supported in Yocto
- rm -r ${D}${libdir}/directfb-1.4-0 \
- ${D}${libdir}/*-dfb.so
+ find ${D}${libdir} -type f -exec chmod 644 {} \;
+ find ${D}${includedir} -type f -exec chmod 644 {} \;
}
S = "${WORKDIR}/${PN}-${PV}"
@@ -85,8 +100,6 @@ FILES_libclc-mx6 = "${libdir}/libCLC${SOLIBS}"
FILES_libclc-mx6-dev = "${includedir}/CL ${libdir}/libCLC${SOLIBSDEV}"
FILES_libclc-mx6-dbg = "${libdir}/.debug/libCLC${SOLIBS}"
-FILES_libegl-common-mx6-dev = "${includedir}/EGL ${libdir}/libEGL${SOLIBSDEV}"
-
FILES_libegl-fb-mx6 = "${libdir}/libEGL-fb${SOLIBS}"
FILES_libegl-fb-mx6-dev = "${libdir}/libEGL-fb${SOLIBSDEV}"
FILES_libegl-fb-mx6-dbg = "${libdir}/.debug/libEGL-fb${SOLIBS}"
@@ -95,7 +108,9 @@ FILES_libegl-x11-mx6 = "${libdir}/libEGL-x11${SOLIBS}"
FILES_libegl-x11-mx6-dev = "${libdir}/libEGL-x11${SOLIBSDEV}"
FILES_libegl-x11-mx6-dbg = "${libdir}/.debug/libEGL-x11${SOLIBS}"
-FILES_libgal-common-mx6-dev = "${includedir}/HAL ${libdir}/libGAL${SOLIBSDEV}"
+FILES_libegl-dfb-mx6 = "${libdir}/libEGL-dfb${SOLIBS}"
+FILES_libegl-dfb-mx6-dev = "${libdir}/libEGL-dfb${SOLIBSDEV}"
+FILES_libegl-dfb-mx6-dbg = "${libdir}/.debug/libEGL-dfb${SOLIBS}"
FILES_libgal-fb-mx6 = "${libdir}/libGAL-fb${SOLIBS}"
FILES_libgal-fb-mx6-dev = "${libdir}/libGAL-fb${SOLIBSDEV}"
@@ -105,6 +120,10 @@ FILES_libgal-x11-mx6 = "${libdir}/libGAL-x11${SOLIBS}"
FILES_libgal-x11-mx6-dev = "${libdir}/libGAL-x11${SOLIBSDEV}"
FILES_libgal-x11-mx6-dbg = "${libdir}/.debug/libGAL-x11${SOLIBS}"
+FILES_libgal-dfb-mx6 = "${libdir}/libGAL-dfb${SOLIBS}"
+FILES_libgal-dfb-mx6-dev = "${libdir}/libGAL-dfb${SOLIBSDEV}"
+FILES_libgal-dfb-mx6-dbg = "${libdir}/.debug/libGAL-dfb${SOLIBS}"
+
FILES_libgles-mx6 = "${libdir}/libGLESv1*${SOLIBS} ${libdir}/libGLES_*${SOLIBS}"
FILES_libgles-mx6-dev = "${includedir}/GLES ${libdir}/libGLESv1*${SOLIBS} ${libdir}/libGLES_*${SOLIBSDEV}"
FILES_libgles-mx6-dbg = "${libdir}/.debug/libGLESv1*${SOLIBS} ${libdir}/.debug/libGLES_*${SOLIBS}"
@@ -133,8 +152,6 @@ FILES_libvdk-mx6 = "${libdir}/libVDK${SOLIBS}"
FILES_libvdk-mx6-dev = "${includedir}/*vdk.h ${libdir}/libVDK${SOLIBSDEV}"
FILES_libvdk-mx6-dbg = "${libdir}/.debug/libVDK${SOLIBS}"
-FILES_libvivante-common-mx6-dev = "${includedir}/HAL ${libdir}/libVIVANTE${SOLIBSDEV}"
-
FILES_libvivante-fb-mx6 = "${libdir}/libVIVANTE-fb${SOLIBS}"
FILES_libvivante-fb-mx6-dev = "${libdir}/libVIVANTE-fb${SOLIBSDEV}"
FILES_libvivante-fb-mx6-dbg = "${libdir}/.debug/libVIVANTE-fb${SOLIBS}"
@@ -143,6 +160,10 @@ FILES_libvivante-x11-mx6 = "${libdir}/libVIVANTE-x11${SOLIBS}"
FILES_libvivante-x11-mx6-dev = "${libdir}/libVIVANTE-x11${SOLIBSDEV}"
FILES_libvivante-x11-mx6-dbg = "${libdir}/.debug/libVIVANTE-x11${SOLIBS}"
+FILES_libvivante-dfb-mx6 = "${libdir}/libVIVANTE-dfb${SOLIBS}"
+FILES_libvivante-dfb-mx6-dev = "${libdir}/libVIVANTE-dfb${SOLIBSDEV}"
+FILES_libvivante-dfb-mx6-dbg = "${libdir}/.debug/libVIVANTE-dfb${SOLIBS}"
+
FILES_libvivante-dri-mx6 = "${libdir}/dri/vivante_dri${SOLIBS}"
FILES_libvivante-dri-mx6-dev = ""
FILES_libvivante-dri-mx6-dbg = "${libdir}/dri/.debug/vivante_dri${SOLIBS}"
--
1.8.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [meta-fsl-arm][PATCH v4 5/9] gpu-viv-bin-mx6q: Add dri.pc
2013-02-12 21:58 [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade Otavio Salvador
` (3 preceding siblings ...)
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 4/9] gpu-viv-bin-mx6q: group libs based on backend Otavio Salvador
@ 2013-02-12 21:58 ` Otavio Salvador
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 6/9] xserver-xorg: Override PACKAGECONFIG for i.MX6 to enable DRI support Otavio Salvador
` (4 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Otavio Salvador @ 2013-02-12 21:58 UTC (permalink / raw)
To: meta-freescale Mailing List; +Cc: Andrei Gherzan
From: Andrei Gherzan <andrei.gherzan@windriver.com>
This is need when compiling packages like xserver-xorg with dri support.
Change-Id: I538c5139cd21ebed9da3061645bac6a63388af0a
Signed-off-by: Andrei Gherzan <andrei.gherzan@windriver.com>
---
recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc | 7 ++++++-
recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q/dri.pc | 11 +++++++++++
2 files changed, 17 insertions(+), 1 deletion(-)
create mode 100644 recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q/dri.pc
diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
index 7c52810..4831cbd 100644
--- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
+++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
@@ -14,6 +14,7 @@ inherit fsl-eula-unpack
SRC_URI = "${FSL_MIRROR}/${PN}-${PV}.bin;fsl-eula=true \
file://0001-change-header-path-to-HAL.patch \
file://gc_hal_eglplatform-remove-xlib-undefs.patch \
+ file://dri.pc \
"
GPU_XLIBS = "libegl-x11-mx6 libegl-x11-mx6-dev libegl-x11-mx6-dbg \
@@ -74,6 +75,10 @@ do_install () {
else
install -d ${D}${libdir}/dri
cp -ax ${S}/usr/lib/dri/* ${D}${libdir}/dri
+
+ # FIXME: Install a dri.pc file
+ install -d ${D}${libdir}/pkgconfig
+ cp -ax ${WORKDIR}/dri.pc ${D}${libdir}/pkgconfig
fi
if [ "${KEEP_DFBLIBS}" = "no" ]; then
rm ${D}${libdir}/*-dfb.so
@@ -165,7 +170,7 @@ FILES_libvivante-dfb-mx6-dev = "${libdir}/libVIVANTE-dfb${SOLIBSDEV}"
FILES_libvivante-dfb-mx6-dbg = "${libdir}/.debug/libVIVANTE-dfb${SOLIBS}"
FILES_libvivante-dri-mx6 = "${libdir}/dri/vivante_dri${SOLIBS}"
-FILES_libvivante-dri-mx6-dev = ""
+FILES_libvivante-dri-mx6-dev = "${libdir}/pkgconfig"
FILES_libvivante-dri-mx6-dbg = "${libdir}/dri/.debug/vivante_dri${SOLIBS}"
PACKAGE_ARCH = "${MACHINE_ARCH}"
diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q/dri.pc b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q/dri.pc
new file mode 100644
index 0000000..537c533
--- /dev/null
+++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q/dri.pc
@@ -0,0 +1,11 @@
+prefix=/usr
+exec_prefix=${prefix}
+libdir=/usr/lib
+includedir=/usr/include
+dridriverdir=${libdir}/dri
+
+Name: dri
+Description: Vivante Direct Rendering Infrastructure
+Version: 8.0.0
+Requires.private: libdrm >= 2.4.24
+Cflags: -I${includedir}
--
1.8.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [meta-fsl-arm][PATCH v4 6/9] xserver-xorg: Override PACKAGECONFIG for i.MX6 to enable DRI support
2013-02-12 21:58 [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade Otavio Salvador
` (4 preceding siblings ...)
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 5/9] gpu-viv-bin-mx6q: Add dri.pc Otavio Salvador
@ 2013-02-12 21:58 ` Otavio Salvador
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 7/9] xf86-dri-vivante: Upgrade to 1.1.0 Otavio Salvador
` (3 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Otavio Salvador @ 2013-02-12 21:58 UTC (permalink / raw)
To: meta-freescale Mailing List; +Cc: Otavio Salvador
Change-Id: I5f9bafbe788e08aa14a59b5d0b5ee8fc9d9f0720
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
recipes-graphics/xorg-xserver/xserver-xorg_1.13.1.bbappend | 4 ++++
1 file changed, 4 insertions(+)
create mode 100644 recipes-graphics/xorg-xserver/xserver-xorg_1.13.1.bbappend
diff --git a/recipes-graphics/xorg-xserver/xserver-xorg_1.13.1.bbappend b/recipes-graphics/xorg-xserver/xserver-xorg_1.13.1.bbappend
new file mode 100644
index 0000000..2528031
--- /dev/null
+++ b/recipes-graphics/xorg-xserver/xserver-xorg_1.13.1.bbappend
@@ -0,0 +1,4 @@
+PRINC := "${@int(PRINC) + 1}"
+
+PACKAGECONFIG_mx6 = "udev dri"
+PACKAGE_ARCH_mx6 = "${MACHINE_ARCH}"
--
1.8.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [meta-fsl-arm][PATCH v4 7/9] xf86-dri-vivante: Upgrade to 1.1.0
2013-02-12 21:58 [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade Otavio Salvador
` (5 preceding siblings ...)
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 6/9] xserver-xorg: Override PACKAGECONFIG for i.MX6 to enable DRI support Otavio Salvador
@ 2013-02-12 21:58 ` Otavio Salvador
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 8/9] xf86-video-imxfb-vivante: Add depends/rdepends for DRI support Otavio Salvador
` (2 subsequent siblings)
9 siblings, 0 replies; 22+ messages in thread
From: Otavio Salvador @ 2013-02-12 21:58 UTC (permalink / raw)
To: meta-freescale Mailing List; +Cc: Andrei Gherzan, Otavio Salvador
This upgrades to the 1.1.0 version and also include the build fix for
newer Xorg API done by Andrei Gherzan.
Change-Id: I8935341e3513bcf845478a5a54a723b96c8cdcbf
Signed-off-by: Andrei Gherzan <andrei.gherzan@windriver.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
.../xf86-dri-vivante/fix-with-xorg-1-13.patch | 141 +++++++++++++++++++++
.../xorg-driver/xf86-dri-vivante_1.1.0.bb | 45 +++++++
.../xorg-driver/xf86-dri-vivante_12.09.01.bb | 36 ------
3 files changed, 186 insertions(+), 36 deletions(-)
create mode 100644 recipes-graphics/xorg-driver/xf86-dri-vivante/fix-with-xorg-1-13.patch
create mode 100644 recipes-graphics/xorg-driver/xf86-dri-vivante_1.1.0.bb
delete mode 100644 recipes-graphics/xorg-driver/xf86-dri-vivante_12.09.01.bb
diff --git a/recipes-graphics/xorg-driver/xf86-dri-vivante/fix-with-xorg-1-13.patch b/recipes-graphics/xorg-driver/xf86-dri-vivante/fix-with-xorg-1-13.patch
new file mode 100644
index 0000000..0f138e9
--- /dev/null
+++ b/recipes-graphics/xorg-driver/xf86-dri-vivante/fix-with-xorg-1-13.patch
@@ -0,0 +1,141 @@
+Fix module for Xorg 1.13.
+
+Upstream-Status: Pending
+Signed-off-by: Andrei Gherzan <andrei.gherzan@windriver.com>
+
+Index: dri-xorg-graphic-imx-viv-12.09.01/src/dri.c
+===================================================================
+--- dri-xorg-graphic-imx-viv-12.09.01.orig/src/dri.c 2012-07-02 05:25:06.000000000 +0300
++++ dri-xorg-graphic-imx-viv-12.09.01/src/dri.c 2012-12-21 11:42:09.000000000 +0200
+@@ -1675,7 +1675,7 @@
+
+ if (pDRIPriv &&
+ pDRIPriv->pDriverInfo->wrap.WakeupHandler)
+- (*pDRIPriv->pDriverInfo->wrap.WakeupHandler)(i, wakeupData,
++ (*pDRIPriv->pDriverInfo->wrap.WakeupHandler)(pScreen,
+ result, pReadmask);
+ }
+ }
+@@ -1691,16 +1691,15 @@
+
+ if (pDRIPriv &&
+ pDRIPriv->pDriverInfo->wrap.BlockHandler)
+- (*pDRIPriv->pDriverInfo->wrap.BlockHandler)(i, blockData,
++ (*pDRIPriv->pDriverInfo->wrap.BlockHandler)(pScreen,
+ pTimeout, pReadmask);
+ }
+ }
+
+ void
+-DRIDoWakeupHandler(int screenNum, pointer wakeupData,
++DRIDoWakeupHandler(ScreenPtr pScreen,
+ unsigned long result, pointer pReadmask)
+ {
+- ScreenPtr pScreen = screenInfo.screens[screenNum];
+ DRIScreenPrivPtr pDRIPriv = DRI_SCREEN_PRIV(pScreen);
+
+ DRILock(pScreen, 0);
+@@ -2383,7 +2382,7 @@
+ /* unwrap */
+ pScrn->AdjustFrame = pDRIPriv->wrap.AdjustFrame;
+ /* call lower layers */
+- (*pScrn->AdjustFrame)(scrnIndex, x, y, flags);
++ (*pScrn->AdjustFrame)(pScrn, x, y);
+ /* rewrap */
+ pDRIPriv->wrap.AdjustFrame = pScrn->AdjustFrame;
+ pScrn->AdjustFrame = DRIAdjustFrame;
+Index: dri-xorg-graphic-imx-viv-12.09.01/src/dri.h
+===================================================================
+--- dri-xorg-graphic-imx-viv-12.09.01.orig/src/dri.h 2012-07-02 05:25:06.000000000 +0300
++++ dri-xorg-graphic-imx-viv-12.09.01/src/dri.h 2012-12-21 11:42:15.000000000 +0200
+@@ -372,16 +372,14 @@
+
+ extern _X_EXPORT Bool DRIFinishScreenInit(ScreenPtr pScreen);
+
+-extern _X_EXPORT void DRIWakeupHandler(pointer wakeupData,
+- int result,
++extern _X_EXPORT void DRIWakeupHandler(pointer wakeupData, int result,
+ pointer pReadmask);
+
+ extern _X_EXPORT void DRIBlockHandler(pointer blockData,
+ OSTimePtr pTimeout,
+ pointer pReadmask);
+
+-extern _X_EXPORT void DRIDoWakeupHandler(int screenNum,
+- pointer wakeupData,
++extern _X_EXPORT void DRIDoWakeupHandler(ScreenPtr pScreen,
+ unsigned long result,
+ pointer pReadmask);
+
+Index: dri-xorg-graphic-imx-viv-12.09.01/src/xf86dri.c
+===================================================================
+--- dri-xorg-graphic-imx-viv-12.09.01.orig/src/xf86dri.c 2012-07-02 05:25:06.000000000 +0300
++++ dri-xorg-graphic-imx-viv-12.09.01/src/xf86dri.c 2012-12-21 10:27:32.000000000 +0200
+@@ -102,7 +102,6 @@
+ )
+ {
+ xXF86DRIQueryVersionReply rep;
+- register int n;
+
+ REQUEST_SIZE_MATCH(xXF86DRIQueryVersionReq);
+ rep.type = X_Reply;
+@@ -112,11 +111,11 @@
+ rep.minorVersion = SERVER_XF86DRI_MINOR_VERSION;
+ rep.patchVersion = SERVER_XF86DRI_PATCH_VERSION;
+ if (client->swapped) {
+- swaps(&rep.sequenceNumber, n);
+- swapl(&rep.length, n);
+- swaps(&rep.majorVersion, n);
+- swaps(&rep.minorVersion, n);
+- swapl(&rep.patchVersion, n);
++ swaps(&rep.sequenceNumber);
++ swapl(&rep.length);
++ swaps(&rep.majorVersion);
++ swaps(&rep.minorVersion);
++ swapl(&rep.patchVersion);
+ }
+ WriteToClient(client, sizeof(xXF86DRIQueryVersionReply), (char *)&rep);
+ return Success;
+@@ -129,7 +128,6 @@
+ {
+ xXF86DRIQueryDirectRenderingCapableReply rep;
+ Bool isCapable;
+- register int n;
+
+ REQUEST(xXF86DRIQueryDirectRenderingCapableReq);
+ REQUEST_SIZE_MATCH(xXF86DRIQueryDirectRenderingCapableReq);
+@@ -152,8 +150,8 @@
+ rep.isCapable = 0;
+
+ if (client->swapped) {
+- swaps(&rep.sequenceNumber, n);
+- swapl(&rep.length, n);
++ swaps(&rep.sequenceNumber);
++ swapl(&rep.length);
+ }
+
+ WriteToClient(client,
+@@ -611,9 +609,8 @@
+ register ClientPtr client
+ )
+ {
+- register int n;
+ REQUEST(xXF86DRIQueryVersionReq);
+- swaps(&stuff->length, n);
++ swaps(&stuff->length);
+ return ProcXF86DRIQueryVersion(client);
+ }
+
+@@ -622,10 +619,9 @@
+ register ClientPtr client
+ )
+ {
+- register int n;
+ REQUEST(xXF86DRIQueryDirectRenderingCapableReq);
+- swaps(&stuff->length, n);
+- swapl(&stuff->screen, n);
++ swaps(&stuff->length);
++ swapl(&stuff->screen);
+ return ProcXF86DRIQueryDirectRenderingCapable(client);
+ }
+
diff --git a/recipes-graphics/xorg-driver/xf86-dri-vivante_1.1.0.bb b/recipes-graphics/xorg-driver/xf86-dri-vivante_1.1.0.bb
new file mode 100644
index 0000000..aaab593
--- /dev/null
+++ b/recipes-graphics/xorg-driver/xf86-dri-vivante_1.1.0.bb
@@ -0,0 +1,45 @@
+# Copyright (C) 2012-2013 Freescale Semiconductor
+# Copyright (C) 2012-2013 O.S. Systems Software LTDA.
+# Released under the MIT license (see COPYING.MIT for the terms)
+
+LICENSE = "MIT"
+SECTION = "x11/base"
+DEPENDS = "virtual/libx11 virtual/xserver xf86-video-imxfb-vivante"
+LIC_FILES_CHKSUM = "file://src/dri.h;enline=27;md5=c0a9f5e55df7fb9d8c7445890e52e859"
+
+SRC_URI = "${FSL_MIRROR}/xserver-xorg-video-imx-viv-${PV}.tar.gz \
+ file://fix-with-xorg-1-13.patch"
+SRC_URI[md5sum] = "d872365c046738628a7016343ffdb79a"
+SRC_URI[sha256sum] = "d53216d5f9e3f7803983ac1577d83985dfda33145e4711300f4ad5cbbe28e32d"
+
+PE = "1"
+PR = "r0"
+
+S = "${WORKDIR}/xserver-xorg-video-imx-viv-${PV}/DRI_1.10.4"
+
+inherit fsl-eula-unpack autotools pkgconfig
+
+EXTRA_OECONF_armv7a = " --enable-neon "
+CFLAGS += " -I${STAGING_INCDIR}/xorg -DXSERVER_LIBPCIACCESS"
+
+do_install_append () {
+ # Install header files
+ install -d ${D}${includedir}/xorg
+ cp -axr ${S}/src/*.h ${D}${includedir}/xorg
+ find ${D}${includedir} -type f -exec chmod 660 {} \;
+
+ # don't install libtool (*.la) archive not usefull, fix Makefile.am
+ find ${D}${libdir}/xorg/modules -regex ".*\.la$" | xargs rm -f --
+
+ # Remove files provided by xserver-xorg
+ rm ${D}${includedir}/xorg/dri.h
+ rm ${D}${includedir}/xorg/dristruct.h
+ rm ${D}${includedir}/xorg/sarea.h
+}
+
+FILES_${PN}-dev += "${includedir}/xorg/*.h"
+FILES_${PN} += " ${libdir}/xorg/modules/extensions/*.so"
+FILES_${PN}-dbg += " ${libdir}/xorg/modules/extensions/.debug"
+
+PACKAGE_ARCH = "${MACHINE_ARCH}"
+COMPATIBLE_MACHINE = "(mx6)"
diff --git a/recipes-graphics/xorg-driver/xf86-dri-vivante_12.09.01.bb b/recipes-graphics/xorg-driver/xf86-dri-vivante_12.09.01.bb
deleted file mode 100644
index 1653029..0000000
--- a/recipes-graphics/xorg-driver/xf86-dri-vivante_12.09.01.bb
+++ /dev/null
@@ -1,36 +0,0 @@
-# Copyright (C) 2012 Freescale Semiconductor
-# Released under the MIT license (see COPYING.MIT for the terms)
-
-LICENSE = "MIT"
-SECTION = "x11/base"
-DEPENDS = "virtual/libx11 util-macros xf86-video-imxfb-vivante"
-LIC_FILES_CHKSUM = "file://src/dri.h;enline=27;md5=1d0d59e1dc96f5197ea3a8b101bf1fcc"
-
-SRC_URI = "${FSL_MIRROR}/dri-xorg-graphic-imx-viv-${PV}.bin;fsl-eula=true"
-SRC_URI[md5sum] = "8c90045cd5f4dba81095856634ba5136"
-SRC_URI[sha256sum] = "c844dc180e43901359bbdb4f797ab178b3821fbf63bdee9577e5a0afe5d7f6ad"
-
-S = "${WORKDIR}/dri-xorg-graphic-imx-viv-${PV}"
-
-PR = "r2"
-
-inherit fsl-eula-unpack autotools pkgconfig
-
-EXTRA_OECONF_armv7a = " --enable-neon "
-CFLAGS += " -I${STAGING_INCDIR}/xorg"
-
-do_install_append () {
-# Install header files
- install -d ${D}${includedir}/xorg
- cp -axr ${S}/src/*.h ${D}${includedir}/xorg
- find ${D}${includedir} -type f -exec chmod 660 {} \;
-# don't install libtool (*.la) archive not usefull, fix Makefile.am
- find ${D}${libdir}/xorg/modules -regex ".*\.la$" | xargs rm -f --
-}
-
-FILES_${PN}-dev += "${includedir}/xorg/*.h"
-FILES_${PN} += " ${libdir}/xorg/modules/extensions/*.so"
-FILES_${PN}-dbg += " ${libdir}/xorg/modules/extensions/.debug"
-
-PACKAGE_ARCH = "${MACHINE_ARCH}"
-COMPATIBLE_MACHINE = "(mx6)"
--
1.8.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [meta-fsl-arm][PATCH v4 8/9] xf86-video-imxfb-vivante: Add depends/rdepends for DRI support
2013-02-12 21:58 [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade Otavio Salvador
` (6 preceding siblings ...)
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 7/9] xf86-dri-vivante: Upgrade to 1.1.0 Otavio Salvador
@ 2013-02-12 21:58 ` Otavio Salvador
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 9/9] glproto: Don't install glxtokens.h for imx6qsabrelite Otavio Salvador
2013-02-12 21:59 ` [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade Otavio Salvador
9 siblings, 0 replies; 22+ messages in thread
From: Otavio Salvador @ 2013-02-12 21:58 UTC (permalink / raw)
To: meta-freescale Mailing List; +Cc: Otavio Salvador
Change-Id: Id2227df656075f189ce7d3ca4b0ba93dea9e51d0
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_1.1.0.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_1.1.0.bb b/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_1.1.0.bb
index 96fa745..8406bd6 100644
--- a/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_1.1.0.bb
+++ b/recipes-graphics/xorg-driver/xf86-video-imxfb-vivante_1.1.0.bb
@@ -5,9 +5,9 @@
require recipes-graphics/xorg-driver/xorg-driver-video.inc
PE = "3"
-PR = "${INC_PR}.0"
+PR = "${INC_PR}.1"
-DEPENDS += "virtual/libx11 virtual/libgal-x11 gpu-viv-bin-mx6q"
+DEPENDS += "virtual/libx11 virtual/libgal-x11 virtual/dri"
LIC_FILES_CHKSUM = "file://src/vivante_fbdev/vivante.h;endline=19;md5=93a322f91ec495569dcbcfbb2a95454a"
@@ -30,7 +30,7 @@ do_install_append () {
find ${D}${includedir} -type f -exec chmod 660 {} \;
}
-RDEPENDS_${PN} += "xserver-xorg-module-exa"
+RDEPENDS_${PN} += "xserver-xorg-module-exa xf86-dri-vivante"
PACKAGE_ARCH = "${MACHINE_ARCH}"
COMPATIBLE_MACHINE = "(mx6)"
--
1.8.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* [meta-fsl-arm][PATCH v4 9/9] glproto: Don't install glxtokens.h for imx6qsabrelite
2013-02-12 21:58 [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade Otavio Salvador
` (7 preceding siblings ...)
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 8/9] xf86-video-imxfb-vivante: Add depends/rdepends for DRI support Otavio Salvador
@ 2013-02-12 21:58 ` Otavio Salvador
2013-02-12 21:59 ` [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade Otavio Salvador
9 siblings, 0 replies; 22+ messages in thread
From: Otavio Salvador @ 2013-02-12 21:58 UTC (permalink / raw)
To: meta-freescale Mailing List; +Cc: Andrei Gherzan, Otavio Salvador
From: Andrei Gherzan <andrei.gherzan@windriver.com>
Avoid in this way duplicate file warnings in sysroot.
This header is provided by freescale.
Change-Id: I604702b1e35500ce65b8f6b16ffc9ce107908364
Signed-off-by: Andrei Gherzan <andrei.gherzan@windriver.com>
Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
---
recipes-graphics/xorg-proto/glproto_1.4.16.bbappend | 8 ++++++++
1 file changed, 8 insertions(+)
create mode 100644 recipes-graphics/xorg-proto/glproto_1.4.16.bbappend
diff --git a/recipes-graphics/xorg-proto/glproto_1.4.16.bbappend b/recipes-graphics/xorg-proto/glproto_1.4.16.bbappend
new file mode 100644
index 0000000..9be81d3
--- /dev/null
+++ b/recipes-graphics/xorg-proto/glproto_1.4.16.bbappend
@@ -0,0 +1,8 @@
+PRINC := "${@int(PRINC) + 1}"
+
+do_install_append_mx6() {
+ # This is a header provided by fsl so don't use this header
+ rm -rf ${D}${includedir}/GL/glxtokens.h
+}
+
+PACKAGE_ARCH_mx6 = "${MACHINE_ARCH}"
--
1.8.1
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade
2013-02-12 21:58 [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade Otavio Salvador
` (8 preceding siblings ...)
2013-02-12 21:58 ` [meta-fsl-arm][PATCH v4 9/9] glproto: Don't install glxtokens.h for imx6qsabrelite Otavio Salvador
@ 2013-02-12 21:59 ` Otavio Salvador
2013-02-13 17:44 ` Thomas Senyk
9 siblings, 1 reply; 22+ messages in thread
From: Otavio Salvador @ 2013-02-12 21:59 UTC (permalink / raw)
To: meta-freescale Mailing List; +Cc: Otavio Salvador
On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> Hello,
>
> This patch series upgrades the iMX6Q BSP to 1.1.0; it also try to fix
> the DRI support for it.
>
> Please give it a try as this is a huge upgrade and we might have
> regressions and pending issues still unkown. This series depends on a
> cuple of patches I sent to OpenEmbeeded-Core mailing list for
> xserver-xorg and mesa, please apply them before playing with this
> series.
I've created a bundle for this series:
OE-Core/Poky patches:
http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
Meta-FSL-ARM patches:
http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade
2013-02-12 21:59 ` [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade Otavio Salvador
@ 2013-02-13 17:44 ` Thomas Senyk
2013-02-13 21:11 ` Otavio Salvador
0 siblings, 1 reply; 22+ messages in thread
From: Thomas Senyk @ 2013-02-13 17:44 UTC (permalink / raw)
To: meta-freescale; +Cc: Otavio Salvador
On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote:
> On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
>
> <otavio@ossystems.com.br> wrote:
> > Hello,
> >
> > This patch series upgrades the iMX6Q BSP to 1.1.0; it also try to fix
> > the DRI support for it.
> >
> > Please give it a try as this is a huge upgrade and we might have
> > regressions and pending issues still unkown. This series depends on a
> > cuple of patches I sent to OpenEmbeeded-Core mailing list for
> > xserver-xorg and mesa, please apply them before playing with this
> > series.
>
> I've created a bundle for this series:
>
> OE-Core/Poky patches:
>
> http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
>
> Meta-FSL-ARM patches:
>
> http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/
Nice thanks for the bundle.
Most of my issues got fixed in v4! good job! :)
The left overs:
1. After applied the upstream patches I got:
ERROR: No recipes available for:
/home/tsenyk/projects/oe-yocto/fsl-community-bsp/sources/meta-fsl-
arm/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend
ERROR: Command execution failed: Exited with 1
... their is probably just some patch missing or something .. I just deleted
it and it was good ;)
I don't care that much about this one :) (I just wanted to report this)
2. The deploy and symlinks in the image look very good now:
lrwxrwxrwx 1 root root 12 Feb 13 17:49 libEGL.so -> libEGL-fb.so
-rw-r--r-- 1 root root 803326 Feb 13 17:33 libGAL-fb.so
lrwxrwxrwx 1 root root 12 Feb 13 17:49 libGAL.so -> libGAL-fb.so
nice!
Also the deploy in the sysroot looks good (only libEGL-fb.so and non of the
others are present) .... so the file-split is working, but there are no
symblinks.
I tried to fix this by creating symlinks manually in do_install:
diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc b/recipes-
graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
index 9818c72..af6dc82 100644
--- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
+++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
@@ -91,6 +91,20 @@ do_install () {
${D}${libdir}/libGAL.so \
${D}${libdir}/libVIVANTE.so
+ if [ "${KEEP_XLIBS}" = "yes" ]; then
+ ln -s ${D}${libdir}/libEGL-x11.so ${D}${libdir}/libEGL.so
+ ln -s ${D}${libdir}/libGAL-x11.so ${D}${libdir}/libGAL.so
+ ln -s ${D}${libdir}/libVIVANTE-x11.so ${D}${libdir}/libVIVANTE.so
+ elif [ "${KEEP_DFBLIBS}" = "yes" ]; then
+ ln -s ${D}${libdir}/libEGL-dfb.so ${D}${libdir}/libEGL.so
+ ln -s ${D}${libdir}/libGAL-dfb.so ${D}${libdir}/libGAL.so
+ ln -s ${D}${libdir}/libVIVANTE-dfb.so ${D}${libdir}/libVIVANTE.so
+ else
+ ln -s libEGL-fb.so ${D}${libdir}/libEGL.so
+ ln -s libGAL-fb.so ${D}${libdir}/libGAL.so
+ ln -s libVIVANTE-fb.so ${D}${libdir}/libVIVANTE.so
+ fi
+
find ${D}${libdir} -type f -exec chmod 644 {} \;
find ${D}${includedir} -type f -exec chmod 644 {} \;
}
I have absolutely NO idea if this is in anyway the right thing to do!
I had errors, bitbake complaining about .so files not part of the -dev package
... but for some reason I don't get those anymore after I removed all of my
other changes and just kept the 'ln -s'-lines ... so:
If you think it the right way, just take it and submit v5 and/or commit it
after v4 is merged.
3. I still got the following errors when starting any Qt5 application:
vertex shader compilation error:
fragment shader compilation error:
program link error: No vertex shader attached.
My setup: I do a image of my own, the main(!) contents of the image is:
inherit core-image
IMAGE_INSTALL += "libpng tslib libudev gpu-viv-bin-mx6q"
IMAGE_FEATURES += "ssh-server-openssh tools-debug"
DEPENDS = "gpu-viv-bin-mx6q libpng"
Then I compile Qt5 git from outside of yocto, my configure line:
../qt5/configure -opensource -confirm-license -make libs -device imx6 -device-
option CROSS_COMPILE=~/projects/oe-yocto/fsl-community-bsp/imx6-
build-10/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-
gnueabi/arm-poky-linux-gnueabi- -sysroot ~/projects/oe-yocto/fsl-community-
bsp/imx6-build-10/tmp/sysroots/imx6qsabrelite -prefix /opt/pelagicore/Qt5.0-
yocto-imx6-10 -opengl es2 -no-pch -v
This way I've compiled Qt5 against yocto builds for a while now.
The only related problem I had in the past was the '#define mediump vs.
heighp' which I could solve a patching Qt.
This isn't helping anymore ... but I'm still investigating.
Greets
Thomas
>
> --
> Otavio Salvador O.S. Systems
> E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
> Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
> _______________________________________________
> meta-freescale mailing list
> meta-freescale@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
^ permalink raw reply related [flat|nested] 22+ messages in thread* Re: [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade
2013-02-13 17:44 ` Thomas Senyk
@ 2013-02-13 21:11 ` Otavio Salvador
2013-02-15 17:10 ` Thomas Senyk
0 siblings, 1 reply; 22+ messages in thread
From: Otavio Salvador @ 2013-02-13 21:11 UTC (permalink / raw)
To: Thomas Senyk; +Cc: meta-freescale
On Wed, Feb 13, 2013 at 3:44 PM, Thomas Senyk
<thomas.senyk@pelagicore.com> wrote:
>
> On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote:
> > On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
> >
> > <otavio@ossystems.com.br> wrote:
> > > Hello,
> > >
> > > This patch series upgrades the iMX6Q BSP to 1.1.0; it also try to fix
> > > the DRI support for it.
> > >
> > > Please give it a try as this is a huge upgrade and we might have
> > > regressions and pending issues still unkown. This series depends on a
> > > cuple of patches I sent to OpenEmbeeded-Core mailing list for
> > > xserver-xorg and mesa, please apply them before playing with this
> > > series.
> >
> > I've created a bundle for this series:
> >
> > OE-Core/Poky patches:
> >
> > http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
> >
> > Meta-FSL-ARM patches:
> >
> > http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/
>
> Nice thanks for the bundle.
>
> Most of my issues got fixed in v4! good job! :)
>
> The left overs:
>
> 1. After applied the upstream patches I got:
>
> ERROR: No recipes available for:
> /home/tsenyk/projects/oe-yocto/fsl-community-bsp/sources/meta-fsl-
> arm/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend
> ERROR: Command execution failed: Exited with 1
>
> ... their is probably just some patch missing or something .. I just deleted
> it and it was good ;)
> I don't care that much about this one :) (I just wanted to report this)
Yes. I will check if we need to keep the bbappend or it is safe to drop it.
>
> 2. The deploy and symlinks in the image look very good now:
> lrwxrwxrwx 1 root root 12 Feb 13 17:49 libEGL.so -> libEGL-fb.so
> -rw-r--r-- 1 root root 803326 Feb 13 17:33 libGAL-fb.so
> lrwxrwxrwx 1 root root 12 Feb 13 17:49 libGAL.so -> libGAL-fb.so
>
> nice!
Not that nice; in fact we shoudln't have the symlinks or X11 things
might end linking against framebuffer libraries by mistake.
>
> Also the deploy in the sysroot looks good (only libEGL-fb.so and non of the
> others are present) .... so the file-split is working, but there are no
> symblinks.
>
> I tried to fix this by creating symlinks manually in do_install:
>
> diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc b/recipes-
> graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> index 9818c72..af6dc82 100644
> --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> @@ -91,6 +91,20 @@ do_install () {
> ${D}${libdir}/libGAL.so \
> ${D}${libdir}/libVIVANTE.so
>
> + if [ "${KEEP_XLIBS}" = "yes" ]; then
> + ln -s ${D}${libdir}/libEGL-x11.so ${D}${libdir}/libEGL.so
> + ln -s ${D}${libdir}/libGAL-x11.so ${D}${libdir}/libGAL.so
> + ln -s ${D}${libdir}/libVIVANTE-x11.so ${D}${libdir}/libVIVANTE.so
> + elif [ "${KEEP_DFBLIBS}" = "yes" ]; then
> + ln -s ${D}${libdir}/libEGL-dfb.so ${D}${libdir}/libEGL.so
> + ln -s ${D}${libdir}/libGAL-dfb.so ${D}${libdir}/libGAL.so
> + ln -s ${D}${libdir}/libVIVANTE-dfb.so ${D}${libdir}/libVIVANTE.so
> + else
> + ln -s libEGL-fb.so ${D}${libdir}/libEGL.so
> + ln -s libGAL-fb.so ${D}${libdir}/libGAL.so
> + ln -s libVIVANTE-fb.so ${D}${libdir}/libVIVANTE.so
> + fi
> +
> find ${D}${libdir} -type f -exec chmod 644 {} \;
> find ${D}${includedir} -type f -exec chmod 644 {} \;
> }
Read obove...
> I have absolutely NO idea if this is in anyway the right thing to do!
> I had errors, bitbake complaining about .so files not part of the -dev package
> ... but for some reason I don't get those anymore after I removed all of my
> other changes and just kept the 'ln -s'-lines ... so:
> If you think it the right way, just take it and submit v5 and/or commit it
> after v4 is merged.
No; it is not.
> 3. I still got the following errors when starting any Qt5 application:
>
> vertex shader compilation error:
> fragment shader compilation error:
> program link error: No vertex shader attached.
> My setup: I do a image of my own, the main(!) contents of the image is:
> inherit core-image
> IMAGE_INSTALL += "libpng tslib libudev gpu-viv-bin-mx6q"
> IMAGE_FEATURES += "ssh-server-openssh tools-debug"
> DEPENDS = "gpu-viv-bin-mx6q libpng"
>
> Then I compile Qt5 git from outside of yocto, my configure line:
> ../qt5/configure -opensource -confirm-license -make libs -device imx6 -device-
> option CROSS_COMPILE=~/projects/oe-yocto/fsl-community-bsp/imx6-
> build-10/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-
> gnueabi/arm-poky-linux-gnueabi- -sysroot ~/projects/oe-yocto/fsl-community-
> bsp/imx6-build-10/tmp/sysroots/imx6qsabrelite -prefix /opt/pelagicore/Qt5.0-
> yocto-imx6-10 -opengl es2 -no-pch -v
This might be the cause of the problem. We need to build it using
Yocto toolchain so it links with proper library names or we raise the
errors we need to deal with. Can you give it a try?
> This way I've compiled Qt5 against yocto builds for a while now.
> The only related problem I had in the past was the '#define mediump vs.
> heighp' which I could solve a patching Qt.
> This isn't helping anymore ... but I'm still investigating.
Please check if you can build against the toolchain. To generate the
toolchain for your image do:
bitbake <image> -c populate_sdk
I hope it works :)
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade
2013-02-13 21:11 ` Otavio Salvador
@ 2013-02-15 17:10 ` Thomas Senyk
2013-02-15 18:08 ` Tomas Frydrych
2013-02-15 18:23 ` Otavio Salvador
0 siblings, 2 replies; 22+ messages in thread
From: Thomas Senyk @ 2013-02-15 17:10 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale
On Wed, February 13, 2013 19:11:59 Otavio Salvador wrote:
> On Wed, Feb 13, 2013 at 3:44 PM, Thomas Senyk
>
> <thomas.senyk@pelagicore.com> wrote:
> > On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote:
> > > On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
> > >
> > > <otavio@ossystems.com.br> wrote:
> > > > Hello,
> > > >
> > > > This patch series upgrades the iMX6Q BSP to 1.1.0; it also try to fix
> > > > the DRI support for it.
> > > >
> > > > Please give it a try as this is a huge upgrade and we might have
> > > > regressions and pending issues still unkown. This series depends on a
> > > > cuple of patches I sent to OpenEmbeeded-Core mailing list for
> > > > xserver-xorg and mesa, please apply them before playing with this
> > > > series.
> > >
> > > I've created a bundle for this series:
> > >
> > > OE-Core/Poky patches:
> > >
> > > http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
> > >
> > > Meta-FSL-ARM patches:
> > >
> > > http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/
> >
> > Nice thanks for the bundle.
> >
> > Most of my issues got fixed in v4! good job! :)
> >
> > The left overs:
> >
> > 1. After applied the upstream patches I got:
> >
> > ERROR: No recipes available for:
> > /home/tsenyk/projects/oe-yocto/fsl-community-bsp/sources/meta-fsl-
> >
> > arm/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend
> > ERROR: Command execution failed: Exited with 1
> >
> > ... their is probably just some patch missing or something .. I just
> > deleted it and it was good ;)
> > I don't care that much about this one :) (I just wanted to report this)
>
> Yes. I will check if we need to keep the bbappend or it is safe to drop it.
>
> > 2. The deploy and symlinks in the image look very good now:
> > lrwxrwxrwx 1 root root 12 Feb 13 17:49 libEGL.so -> libEGL-fb.so
> > -rw-r--r-- 1 root root 803326 Feb 13 17:33 libGAL-fb.so
> > lrwxrwxrwx 1 root root 12 Feb 13 17:49 libGAL.so -> libGAL-fb.so
> >
> > nice!
>
> Not that nice; in fact we shoudln't have the symlinks or X11 things
> might end linking against framebuffer libraries by mistake.
This sounds rather unconventional ;)
I've never seen any platform were libEGL-something.so is the EGL target to
link to.
In general one should define the default flavor of the GPU-driver
... which is setting the libEGL.so symblink.
In relation to the "link by mistake"-argument:
a) You have a fb-only setup: there will be no x11-things.
b) You have a x11 setup: the default is libEGL-x11.so and theirfor no problem.
... if on a x11 setup a application want to explicitly link against
libEGL-fb.so it can do anyway, but at least the default on is set.
c) You have a dfb setup: the default link goes to libEGL-dfb.so
How do applications within the yocto build link against libEGL?
There are generally no .pc file for GPU-drivers
... are there internal variables to reference?
>
> > Also the deploy in the sysroot looks good (only libEGL-fb.so and non of
> > the
> > others are present) .... so the file-split is working, but there are no
> > symblinks.
> >
> > I tried to fix this by creating symlinks manually in do_install:
> >
> > diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> > b/recipes- graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> > index 9818c72..af6dc82 100644
> > --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> > +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> > @@ -91,6 +91,20 @@ do_install () {
> >
> > ${D}${libdir}/libGAL.so \
> > ${D}${libdir}/libVIVANTE.so
> >
> > + if [ "${KEEP_XLIBS}" = "yes" ]; then
> > + ln -s ${D}${libdir}/libEGL-x11.so ${D}${libdir}/libEGL.so
> > + ln -s ${D}${libdir}/libGAL-x11.so ${D}${libdir}/libGAL.so
> > + ln -s ${D}${libdir}/libVIVANTE-x11.so ${D}${libdir}/libVIVANTE.so
> > + elif [ "${KEEP_DFBLIBS}" = "yes" ]; then
> > + ln -s ${D}${libdir}/libEGL-dfb.so ${D}${libdir}/libEGL.so
> > + ln -s ${D}${libdir}/libGAL-dfb.so ${D}${libdir}/libGAL.so
> > + ln -s ${D}${libdir}/libVIVANTE-dfb.so ${D}${libdir}/libVIVANTE.so
> > + else
> > + ln -s libEGL-fb.so ${D}${libdir}/libEGL.so
> > + ln -s libGAL-fb.so ${D}${libdir}/libGAL.so
> > + ln -s libVIVANTE-fb.so ${D}${libdir}/libVIVANTE.so
> > + fi
> > +
> >
> > find ${D}${libdir} -type f -exec chmod 644 {} \;
> > find ${D}${includedir} -type f -exec chmod 644 {} \;
> >
> > }
>
> Read obove...
>
> > I have absolutely NO idea if this is in anyway the right thing to do!
> > I had errors, bitbake complaining about .so files not part of the -dev
> > package ... but for some reason I don't get those anymore after I removed
> > all of my other changes and just kept the 'ln -s'-lines ... so:
> > If you think it the right way, just take it and submit v5 and/or commit it
> > after v4 is merged.
>
> No; it is not.
Because of the above or because the way I set the symlinks is wrong?
>
> > 3. I still got the following errors when starting any Qt5 application:
> >
> > vertex shader compilation error:
> > fragment shader compilation error:
> > program link error: No vertex shader attached.
> >
> > My setup: I do a image of my own, the main(!) contents of the image is:
> > inherit core-image
> > IMAGE_INSTALL += "libpng tslib libudev gpu-viv-bin-mx6q"
> > IMAGE_FEATURES += "ssh-server-openssh tools-debug"
> > DEPENDS = "gpu-viv-bin-mx6q libpng"
> >
> > Then I compile Qt5 git from outside of yocto, my configure line:
> > ../qt5/configure -opensource -confirm-license -make libs -device imx6
> > -device- option CROSS_COMPILE=~/projects/oe-yocto/fsl-community-bsp/imx6-
> > build-10/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-
> > gnueabi/arm-poky-linux-gnueabi- -sysroot
> > ~/projects/oe-yocto/fsl-community-
> > bsp/imx6-build-10/tmp/sysroots/imx6qsabrelite -prefix
> > /opt/pelagicore/Qt5.0- yocto-imx6-10 -opengl es2 -no-pch -v
>
> This might be the cause of the problem. We need to build it using
> Yocto toolchain so it links with proper library names or we raise the
> errors we need to deal with. Can you give it a try?
>
> > This way I've compiled Qt5 against yocto builds for a while now.
> > The only related problem I had in the past was the '#define mediump vs.
> > heighp' which I could solve a patching Qt.
> > This isn't helping anymore ... but I'm still investigating.
>
> Please check if you can build against the toolchain. To generate the
> toolchain for your image do:
>
> bitbake <image> -c populate_sdk
I already use the yocto toolchain and sysroot ... I think? ;)
I'll checkout what does '-c populate_sdk' as soon as I find some time (I guess
week after next week)
>
> I hope it works :)
Me too ;)
>
> --
> Otavio Salvador O.S. Systems
> E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
> Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade
2013-02-15 17:10 ` Thomas Senyk
@ 2013-02-15 18:08 ` Tomas Frydrych
2013-02-15 18:25 ` Otavio Salvador
2013-02-15 18:23 ` Otavio Salvador
1 sibling, 1 reply; 22+ messages in thread
From: Tomas Frydrych @ 2013-02-15 18:08 UTC (permalink / raw)
To: meta-freescale
On 15/02/13 17:10, Thomas Senyk wrote:
>> Not that nice; in fact we shoudln't have the symlinks or X11 things
>> might end linking against framebuffer libraries by mistake.
>
> This sounds rather unconventional ;)
> I've never seen any platform were libEGL-something.so is the EGL target to
> link to.
>
> In general one should define the default flavor of the GPU-driver
> ... which is setting the libEGL.so symblink.
>
> In relation to the "link by mistake"-argument:
> a) You have a fb-only setup: there will be no x11-things.
> b) You have a x11 setup: the default is libEGL-x11.so and theirfor no problem.
> ... if on a x11 setup a application want to explicitly link against
> libEGL-fb.so it can do anyway, but at least the default on is set.
> c) You have a dfb setup: the default link goes to libEGL-dfb.so
>
Agreed; it generally makes little sense to have multiple versions of EGL
available at run time, and normal applications will be looking for
libEGL.so anyway.
> How do applications within the yocto build link against libEGL?
> There are generally no .pc file for GPU-drivers
> ... are there internal variables to reference?
There is nothing Yocto specific here, how the application looks for EGL
is up to the application author. My recommendation would be if the
upstream driver does not provide a .pc file, to provide one as part of
the Yocto packaging, it is trivial to create one, and libraries such as
cogl will use it if they find it, and it saves much pain all around,
because other home grown ways of checking libEGL availability are
usually not cross-compilation friendly.
Tomas
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade
2013-02-15 18:08 ` Tomas Frydrych
@ 2013-02-15 18:25 ` Otavio Salvador
0 siblings, 0 replies; 22+ messages in thread
From: Otavio Salvador @ 2013-02-15 18:25 UTC (permalink / raw)
To: Tomas Frydrych; +Cc: meta-freescale
On Fri, Feb 15, 2013 at 4:08 PM, Tomas Frydrych
<tf+lists.yocto@r-finger.com> wrote:
> On 15/02/13 17:10, Thomas Senyk wrote:
>>> Not that nice; in fact we shoudln't have the symlinks or X11 things
>>> might end linking against framebuffer libraries by mistake.
>>
>> This sounds rather unconventional ;)
>> I've never seen any platform were libEGL-something.so is the EGL target to
>> link to.
>>
>> In general one should define the default flavor of the GPU-driver
>> ... which is setting the libEGL.so symblink.
>>
>> In relation to the "link by mistake"-argument:
>> a) You have a fb-only setup: there will be no x11-things.
>> b) You have a x11 setup: the default is libEGL-x11.so and theirfor no problem.
>> ... if on a x11 setup a application want to explicitly link against
>> libEGL-fb.so it can do anyway, but at least the default on is set.
>> c) You have a dfb setup: the default link goes to libEGL-dfb.so
>>
>
> Agreed; it generally makes little sense to have multiple versions of EGL
> available at run time, and normal applications will be looking for
> libEGL.so anyway.
In theory I agree as well; what worries me is how to build one app
against libEGL-fb and another against libEGL-x11 in parallel.
>> How do applications within the yocto build link against libEGL?
>> There are generally no .pc file for GPU-drivers
>> ... are there internal variables to reference?
>
> There is nothing Yocto specific here, how the application looks for EGL
> is up to the application author. My recommendation would be if the
> upstream driver does not provide a .pc file, to provide one as part of
> the Yocto packaging, it is trivial to create one, and libraries such as
> cogl will use it if they find it, and it saves much pain all around,
> because other home grown ways of checking libEGL availability are
> usually not cross-compilation friendly.
cross-compilation and packaging unfriendly ;-)
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade
2013-02-15 17:10 ` Thomas Senyk
2013-02-15 18:08 ` Tomas Frydrych
@ 2013-02-15 18:23 ` Otavio Salvador
2013-02-26 17:25 ` Thomas Senyk
1 sibling, 1 reply; 22+ messages in thread
From: Otavio Salvador @ 2013-02-15 18:23 UTC (permalink / raw)
To: Thomas Senyk; +Cc: meta-freescale
On Fri, Feb 15, 2013 at 3:10 PM, Thomas Senyk
<thomas.senyk@pelagicore.com> wrote:
> On Wed, February 13, 2013 19:11:59 Otavio Salvador wrote:
>> On Wed, Feb 13, 2013 at 3:44 PM, Thomas Senyk
>>
>> <thomas.senyk@pelagicore.com> wrote:
>> > On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote:
>> > > On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
>> > >
>> > > <otavio@ossystems.com.br> wrote:
>> > > > Hello,
>> > > >
>> > > > This patch series upgrades the iMX6Q BSP to 1.1.0; it also try to fix
>> > > > the DRI support for it.
>> > > >
>> > > > Please give it a try as this is a huge upgrade and we might have
>> > > > regressions and pending issues still unkown. This series depends on a
>> > > > cuple of patches I sent to OpenEmbeeded-Core mailing list for
>> > > > xserver-xorg and mesa, please apply them before playing with this
>> > > > series.
>> > >
>> > > I've created a bundle for this series:
>> > >
>> > > OE-Core/Poky patches:
>> > >
>> > > http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
>> > >
>> > > Meta-FSL-ARM patches:
>> > >
>> > > http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/
>> >
>> > Nice thanks for the bundle.
>> >
>> > Most of my issues got fixed in v4! good job! :)
>> >
>> > The left overs:
>> >
>> > 1. After applied the upstream patches I got:
>> >
>> > ERROR: No recipes available for:
>> > /home/tsenyk/projects/oe-yocto/fsl-community-bsp/sources/meta-fsl-
>> >
>> > arm/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend
>> > ERROR: Command execution failed: Exited with 1
>> >
>> > ... their is probably just some patch missing or something .. I just
>> > deleted it and it was good ;)
>> > I don't care that much about this one :) (I just wanted to report this)
>>
>> Yes. I will check if we need to keep the bbappend or it is safe to drop it.
>>
>> > 2. The deploy and symlinks in the image look very good now:
>> > lrwxrwxrwx 1 root root 12 Feb 13 17:49 libEGL.so -> libEGL-fb.so
>> > -rw-r--r-- 1 root root 803326 Feb 13 17:33 libGAL-fb.so
>> > lrwxrwxrwx 1 root root 12 Feb 13 17:49 libGAL.so -> libGAL-fb.so
>> >
>> > nice!
>>
>> Not that nice; in fact we shoudln't have the symlinks or X11 things
>> might end linking against framebuffer libraries by mistake.
>
> This sounds rather unconventional ;)
> I've never seen any platform were libEGL-something.so is the EGL target to
> link to.
>
> In general one should define the default flavor of the GPU-driver
> ... which is setting the libEGL.so symblink.
For this the alternatives system might be a solution for the target.
The problem is what to do during the build of applications. Think in
such case:
- gpu-viv is build
- app-fb is build
- app-x11 is build
If we have libEGL.so how we manage to link each to the right one?
> In relation to the "link by mistake"-argument:
> a) You have a fb-only setup: there will be no x11-things.
> b) You have a x11 setup: the default is libEGL-x11.so and theirfor no problem.
> ... if on a x11 setup a application want to explicitly link against
> libEGL-fb.so it can do anyway, but at least the default on is set.
> c) You have a dfb setup: the default link goes to libEGL-dfb.so
This works well for runtime and I fully agree.
I am concerned about how we will manage it at *build* time. Bear on
mind that app-fb and app-x11 can be build in parallel so change the
link during the build is not going to work.
> How do applications within the yocto build link against libEGL?
> There are generally no .pc file for GPU-drivers
> ... are there internal variables to reference?
You may need to patch the application to link to one or another. Or
play with LDFLAGS...
>> > Also the deploy in the sysroot looks good (only libEGL-fb.so and non of
>> > the
>> > others are present) .... so the file-split is working, but there are no
>> > symblinks.
>> >
>> > I tried to fix this by creating symlinks manually in do_install:
>> >
>> > diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> > b/recipes- graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> > index 9818c72..af6dc82 100644
>> > --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> > +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> > @@ -91,6 +91,20 @@ do_install () {
>> >
>> > ${D}${libdir}/libGAL.so \
>> > ${D}${libdir}/libVIVANTE.so
>> >
>> > + if [ "${KEEP_XLIBS}" = "yes" ]; then
>> > + ln -s ${D}${libdir}/libEGL-x11.so ${D}${libdir}/libEGL.so
>> > + ln -s ${D}${libdir}/libGAL-x11.so ${D}${libdir}/libGAL.so
>> > + ln -s ${D}${libdir}/libVIVANTE-x11.so ${D}${libdir}/libVIVANTE.so
>> > + elif [ "${KEEP_DFBLIBS}" = "yes" ]; then
>> > + ln -s ${D}${libdir}/libEGL-dfb.so ${D}${libdir}/libEGL.so
>> > + ln -s ${D}${libdir}/libGAL-dfb.so ${D}${libdir}/libGAL.so
>> > + ln -s ${D}${libdir}/libVIVANTE-dfb.so ${D}${libdir}/libVIVANTE.so
>> > + else
>> > + ln -s libEGL-fb.so ${D}${libdir}/libEGL.so
>> > + ln -s libGAL-fb.so ${D}${libdir}/libGAL.so
>> > + ln -s libVIVANTE-fb.so ${D}${libdir}/libVIVANTE.so
>> > + fi
>> > +
>> >
>> > find ${D}${libdir} -type f -exec chmod 644 {} \;
>> > find ${D}${includedir} -type f -exec chmod 644 {} \;
>> >
>> > }
>>
>> Read obove...
>>
>> > I have absolutely NO idea if this is in anyway the right thing to do!
>> > I had errors, bitbake complaining about .so files not part of the -dev
>> > package ... but for some reason I don't get those anymore after I removed
>> > all of my other changes and just kept the 'ln -s'-lines ... so:
>> > If you think it the right way, just take it and submit v5 and/or commit it
>> > after v4 is merged.
>>
>> No; it is not.
>
> Because of the above or because the way I set the symlinks is wrong?
Your code is right the problem is the concurrent build as explained above.
>> > 3. I still got the following errors when starting any Qt5 application:
>> >
>> > vertex shader compilation error:
>> > fragment shader compilation error:
>> > program link error: No vertex shader attached.
>> >
>> > My setup: I do a image of my own, the main(!) contents of the image is:
>> > inherit core-image
>> > IMAGE_INSTALL += "libpng tslib libudev gpu-viv-bin-mx6q"
>> > IMAGE_FEATURES += "ssh-server-openssh tools-debug"
>> > DEPENDS = "gpu-viv-bin-mx6q libpng"
>> >
>> > Then I compile Qt5 git from outside of yocto, my configure line:
>> > ../qt5/configure -opensource -confirm-license -make libs -device imx6
>> > -device- option CROSS_COMPILE=~/projects/oe-yocto/fsl-community-bsp/imx6-
>> > build-10/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-
>> > gnueabi/arm-poky-linux-gnueabi- -sysroot
>> > ~/projects/oe-yocto/fsl-community-
>> > bsp/imx6-build-10/tmp/sysroots/imx6qsabrelite -prefix
>> > /opt/pelagicore/Qt5.0- yocto-imx6-10 -opengl es2 -no-pch -v
>>
>> This might be the cause of the problem. We need to build it using
>> Yocto toolchain so it links with proper library names or we raise the
>> errors we need to deal with. Can you give it a try?
>>
>> > This way I've compiled Qt5 against yocto builds for a while now.
>> > The only related problem I had in the past was the '#define mediump vs.
>> > heighp' which I could solve a patching Qt.
>> > This isn't helping anymore ... but I'm still investigating.
>>
>> Please check if you can build against the toolchain. To generate the
>> toolchain for your image do:
>>
>> bitbake <image> -c populate_sdk
>
> I already use the yocto toolchain and sysroot ... I think? ;)
> I'll checkout what does '-c populate_sdk' as soon as I find some time (I guess
> week after next week)
Right; if I find the need time I will try to play with it as well.
Regards,
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade
2013-02-15 18:23 ` Otavio Salvador
@ 2013-02-26 17:25 ` Thomas Senyk
2013-02-26 17:39 ` Otavio Salvador
0 siblings, 1 reply; 22+ messages in thread
From: Thomas Senyk @ 2013-02-26 17:25 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale
On Fri, February 15, 2013 16:23:42 Otavio Salvador wrote:
> On Fri, Feb 15, 2013 at 3:10 PM, Thomas Senyk
>
> <thomas.senyk@pelagicore.com> wrote:
> > On Wed, February 13, 2013 19:11:59 Otavio Salvador wrote:
> >> On Wed, Feb 13, 2013 at 3:44 PM, Thomas Senyk
> >>
> >> <thomas.senyk@pelagicore.com> wrote:
> >> > On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote:
> >> > > On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
> >> > >
> >> > > <otavio@ossystems.com.br> wrote:
> >> > > > Hello,
> >> > > >
> >> > > > This patch series upgrades the iMX6Q BSP to 1.1.0; it also try to
> >> > > > fix
> >> > > > the DRI support for it.
> >> > > >
> >> > > > Please give it a try as this is a huge upgrade and we might have
> >> > > > regressions and pending issues still unkown. This series depends on
> >> > > > a
> >> > > > cuple of patches I sent to OpenEmbeeded-Core mailing list for
> >> > > > xserver-xorg and mesa, please apply them before playing with this
> >> > > > series.
> >> > >
> >> > > I've created a bundle for this series:
> >> > >
> >> > > OE-Core/Poky patches:
> >> > >
> >> > > http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
> >> > >
> >> > > Meta-FSL-ARM patches:
> >> > >
> >> > > http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/
> >> >
> >> > Nice thanks for the bundle.
> >> >
> >> > Most of my issues got fixed in v4! good job! :)
> >> >
> >> > The left overs:
> >> >
> >> > 1. After applied the upstream patches I got:
> >> >
> >> > ERROR: No recipes available for:
> >> > /home/tsenyk/projects/oe-yocto/fsl-community-bsp/sources/meta-fsl-
> >> >
> >> > arm/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend
> >> > ERROR: Command execution failed: Exited with 1
> >> >
> >> > ... their is probably just some patch missing or something .. I just
> >> > deleted it and it was good ;)
> >> > I don't care that much about this one :) (I just wanted to report this)
> >>
> >> Yes. I will check if we need to keep the bbappend or it is safe to drop
> >> it.
> >>
> >> > 2. The deploy and symlinks in the image look very good now:
> >> > lrwxrwxrwx 1 root root 12 Feb 13 17:49 libEGL.so -> libEGL-fb.so
> >> > -rw-r--r-- 1 root root 803326 Feb 13 17:33 libGAL-fb.so
> >> > lrwxrwxrwx 1 root root 12 Feb 13 17:49 libGAL.so -> libGAL-fb.so
> >> >
> >> > nice!
> >>
> >> Not that nice; in fact we shoudln't have the symlinks or X11 things
> >> might end linking against framebuffer libraries by mistake.
> >
> > This sounds rather unconventional ;)
> > I've never seen any platform were libEGL-something.so is the EGL target to
> > link to.
> >
> > In general one should define the default flavor of the GPU-driver
> >
> > ... which is setting the libEGL.so symblink.
>
> For this the alternatives system might be a solution for the target.
> The problem is what to do during the build of applications. Think in
> such case:
>
> - gpu-viv is build
> - app-fb is build
> - app-x11 is build
>
> If we have libEGL.so how we manage to link each to the right one?
Why would you support this anyway?
Having two EGL versions on your system/sysroot at the same time sounds wrong
doesn't it?
I'd say it depends on your DISTRO_FEATURES and you need to choice either
linuxfb, directfb or x11.
...and the rules are something like:
- is x11 in your DISTRO_FEATURES? => x11 version of drivers
- if not, is directfb in your DISTRO_FEATURES? => egl version of drivers
- if not: linuxfb version of drivers
<side note>
Besides that: You need to solve the "link to the right one" anyway, if you
have libEGL.so or not. (Although I admit it's more likely to cause problems if
you have it)
<\side note>
>
> > In relation to the "link by mistake"-argument:
> > a) You have a fb-only setup: there will be no x11-things.
> > b) You have a x11 setup: the default is libEGL-x11.so and theirfor no
> > problem.>
> > ... if on a x11 setup a application want to explicitly link against
> >
> > libEGL-fb.so it can do anyway, but at least the default on is set.
> > c) You have a dfb setup: the default link goes to libEGL-dfb.so
>
> This works well for runtime and I fully agree.
>
> I am concerned about how we will manage it at *build* time. Bear on
> mind that app-fb and app-x11 can be build in parallel so change the
> link during the build is not going to work.
again: why support 2 build targets in the same sysroot?
>
> > How do applications within the yocto build link against libEGL?
> > There are generally no .pc file for GPU-drivers
> >
> > ... are there internal variables to reference?
>
> You may need to patch the application to link to one or another. Or
> play with LDFLAGS...
That sounds intense...this would mean that one HW-layer (meta-fsl-arm) tries
to invent/enforce a new way of building application for everybody(?)?
Not sure this will thrive ;)
>
> >> > Also the deploy in the sysroot looks good (only libEGL-fb.so and non of
> >> > the
> >> > others are present) .... so the file-split is working, but there are no
> >> > symblinks.
> >> >
> >> > I tried to fix this by creating symlinks manually in do_install:
> >> >
> >> > diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> > b/recipes- graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> > index 9818c72..af6dc82 100644
> >> > --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> > +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> > @@ -91,6 +91,20 @@ do_install () {
> >> >
> >> > ${D}${libdir}/libGAL.so \
> >> > ${D}${libdir}/libVIVANTE.so
> >> >
> >> > + if [ "${KEEP_XLIBS}" = "yes" ]; then
> >> > + ln -s ${D}${libdir}/libEGL-x11.so ${D}${libdir}/libEGL.so
> >> > + ln -s ${D}${libdir}/libGAL-x11.so ${D}${libdir}/libGAL.so
> >> > + ln -s ${D}${libdir}/libVIVANTE-x11.so
> >> > ${D}${libdir}/libVIVANTE.so
> >> > + elif [ "${KEEP_DFBLIBS}" = "yes" ]; then
> >> > + ln -s ${D}${libdir}/libEGL-dfb.so ${D}${libdir}/libEGL.so
> >> > + ln -s ${D}${libdir}/libGAL-dfb.so ${D}${libdir}/libGAL.so
> >> > + ln -s ${D}${libdir}/libVIVANTE-dfb.so
> >> > ${D}${libdir}/libVIVANTE.so
> >> > + else
> >> > + ln -s libEGL-fb.so ${D}${libdir}/libEGL.so
> >> > + ln -s libGAL-fb.so ${D}${libdir}/libGAL.so
> >> > + ln -s libVIVANTE-fb.so ${D}${libdir}/libVIVANTE.so
> >> > + fi
> >> > +
> >> >
> >> > find ${D}${libdir} -type f -exec chmod 644 {} \;
> >> > find ${D}${includedir} -type f -exec chmod 644 {} \;
> >> >
> >> > }
> >>
> >> Read obove...
> >>
> >> > I have absolutely NO idea if this is in anyway the right thing to do!
> >> > I had errors, bitbake complaining about .so files not part of the -dev
> >> > package ... but for some reason I don't get those anymore after I
> >> > removed
> >> > all of my other changes and just kept the 'ln -s'-lines ... so:
> >> > If you think it the right way, just take it and submit v5 and/or commit
> >> > it
> >> > after v4 is merged.
> >>
> >> No; it is not.
> >
> > Because of the above or because the way I set the symlinks is wrong?
>
> Your code is right the problem is the concurrent build as explained above.
>
> >> > 3. I still got the following errors when starting any Qt5 application:
> >> >
> >> > vertex shader compilation error:
> >> > fragment shader compilation error:
> >> > program link error: No vertex shader attached.
> >> >
> >> > My setup: I do a image of my own, the main(!) contents of the image is:
> >> > inherit core-image
> >> > IMAGE_INSTALL += "libpng tslib libudev gpu-viv-bin-mx6q"
> >> > IMAGE_FEATURES += "ssh-server-openssh tools-debug"
> >> > DEPENDS = "gpu-viv-bin-mx6q libpng"
> >> >
> >> > Then I compile Qt5 git from outside of yocto, my configure line:
> >> > ../qt5/configure -opensource -confirm-license -make libs -device imx6
> >> > -device- option
> >> > CROSS_COMPILE=~/projects/oe-yocto/fsl-community-bsp/imx6-
> >> > build-10/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-
> >> > gnueabi/arm-poky-linux-gnueabi- -sysroot
> >> > ~/projects/oe-yocto/fsl-community-
> >> > bsp/imx6-build-10/tmp/sysroots/imx6qsabrelite -prefix
> >> > /opt/pelagicore/Qt5.0- yocto-imx6-10 -opengl es2 -no-pch -v
> >>
> >> This might be the cause of the problem. We need to build it using
> >> Yocto toolchain so it links with proper library names or we raise the
> >> errors we need to deal with. Can you give it a try?
> >>
> >> > This way I've compiled Qt5 against yocto builds for a while now.
> >> > The only related problem I had in the past was the '#define mediump vs.
> >> > heighp' which I could solve a patching Qt.
> >> > This isn't helping anymore ... but I'm still investigating.
> >>
> >> Please check if you can build against the toolchain. To generate the
> >> toolchain for your image do:
> >>
> >> bitbake <image> -c populate_sdk
> >
> > I already use the yocto toolchain and sysroot ... I think? ;)
> > I'll checkout what does '-c populate_sdk' as soon as I find some time (I
> > guess week after next week)
>
> Right; if I find the need time I will try to play with it as well.
>
> Regards,
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade
2013-02-26 17:25 ` Thomas Senyk
@ 2013-02-26 17:39 ` Otavio Salvador
2013-02-26 17:49 ` Thomas Senyk
0 siblings, 1 reply; 22+ messages in thread
From: Otavio Salvador @ 2013-02-26 17:39 UTC (permalink / raw)
To: Thomas Senyk; +Cc: meta-freescale
On Tue, Feb 26, 2013 at 2:25 PM, Thomas Senyk
<thomas.senyk@pelagicore.com> wrote:
> On Fri, February 15, 2013 16:23:42 Otavio Salvador wrote:
>> On Fri, Feb 15, 2013 at 3:10 PM, Thomas Senyk
>>
>> <thomas.senyk@pelagicore.com> wrote:
>> > On Wed, February 13, 2013 19:11:59 Otavio Salvador wrote:
>> >> On Wed, Feb 13, 2013 at 3:44 PM, Thomas Senyk
>> >>
>> >> <thomas.senyk@pelagicore.com> wrote:
>> >> > On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote:
>> >> > > On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
>> >> > >
>> >> > > <otavio@ossystems.com.br> wrote:
>> >> > > > Hello,
>> >> > > >
>> >> > > > This patch series upgrades the iMX6Q BSP to 1.1.0; it also try to
>> >> > > > fix
>> >> > > > the DRI support for it.
>> >> > > >
>> >> > > > Please give it a try as this is a huge upgrade and we might have
>> >> > > > regressions and pending issues still unkown. This series depends on
>> >> > > > a
>> >> > > > cuple of patches I sent to OpenEmbeeded-Core mailing list for
>> >> > > > xserver-xorg and mesa, please apply them before playing with this
>> >> > > > series.
>> >> > >
>> >> > > I've created a bundle for this series:
>> >> > >
>> >> > > OE-Core/Poky patches:
>> >> > >
>> >> > > http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
>> >> > >
>> >> > > Meta-FSL-ARM patches:
>> >> > >
>> >> > > http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/
>> >> >
>> >> > Nice thanks for the bundle.
>> >> >
>> >> > Most of my issues got fixed in v4! good job! :)
>> >> >
>> >> > The left overs:
>> >> >
>> >> > 1. After applied the upstream patches I got:
>> >> >
>> >> > ERROR: No recipes available for:
>> >> > /home/tsenyk/projects/oe-yocto/fsl-community-bsp/sources/meta-fsl-
>> >> >
>> >> > arm/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend
>> >> > ERROR: Command execution failed: Exited with 1
>> >> >
>> >> > ... their is probably just some patch missing or something .. I just
>> >> > deleted it and it was good ;)
>> >> > I don't care that much about this one :) (I just wanted to report this)
>> >>
>> >> Yes. I will check if we need to keep the bbappend or it is safe to drop
>> >> it.
>> >>
>> >> > 2. The deploy and symlinks in the image look very good now:
>> >> > lrwxrwxrwx 1 root root 12 Feb 13 17:49 libEGL.so -> libEGL-fb.so
>> >> > -rw-r--r-- 1 root root 803326 Feb 13 17:33 libGAL-fb.so
>> >> > lrwxrwxrwx 1 root root 12 Feb 13 17:49 libGAL.so -> libGAL-fb.so
>> >> >
>> >> > nice!
>> >>
>> >> Not that nice; in fact we shoudln't have the symlinks or X11 things
>> >> might end linking against framebuffer libraries by mistake.
>> >
>> > This sounds rather unconventional ;)
>> > I've never seen any platform were libEGL-something.so is the EGL target to
>> > link to.
>> >
>> > In general one should define the default flavor of the GPU-driver
>> >
>> > ... which is setting the libEGL.so symblink.
>>
>> For this the alternatives system might be a solution for the target.
>> The problem is what to do during the build of applications. Think in
>> such case:
>>
>> - gpu-viv is build
>> - app-fb is build
>> - app-x11 is build
>>
>> If we have libEGL.so how we manage to link each to the right one?
>
> Why would you support this anyway?
> Having two EGL versions on your system/sysroot at the same time sounds wrong
> doesn't it?
At runtime, I agree but not at build time.
> I'd say it depends on your DISTRO_FEATURES and you need to choice either
> linuxfb, directfb or x11.
> ...and the rules are something like:
> - is x11 in your DISTRO_FEATURES? => x11 version of drivers
> - if not, is directfb in your DISTRO_FEATURES? => egl version of drivers
> - if not: linuxfb version of drivers
But distro features does not mean "enforce X11 use" but "allow X11
use" so it seems we should support fb use even with X11 feature
enabled.
> <side note>
> Besides that: You need to solve the "link to the right one" anyway, if you
> have libEGL.so or not. (Although I admit it's more likely to cause problems if
> you have it)
> <\side note>
>
>>
>> > In relation to the "link by mistake"-argument:
>> > a) You have a fb-only setup: there will be no x11-things.
>> > b) You have a x11 setup: the default is libEGL-x11.so and theirfor no
>> > problem.>
>> > ... if on a x11 setup a application want to explicitly link against
>> >
>> > libEGL-fb.so it can do anyway, but at least the default on is set.
>> > c) You have a dfb setup: the default link goes to libEGL-dfb.so
>>
>> This works well for runtime and I fully agree.
>>
>> I am concerned about how we will manage it at *build* time. Bear on
>> mind that app-fb and app-x11 can be build in parallel so change the
>> link during the build is not going to work.
>
> again: why support 2 build targets in the same sysroot?
Read above.
>> > How do applications within the yocto build link against libEGL?
>> > There are generally no .pc file for GPU-drivers
>> >
>> > ... are there internal variables to reference?
>>
>> You may need to patch the application to link to one or another. Or
>> play with LDFLAGS...
>
> That sounds intense...this would mean that one HW-layer (meta-fsl-arm) tries
> to invent/enforce a new way of building application for everybody(?)?
> Not sure this will thrive ;)
Well, the "right" way of deal with it is to have a library which loads
the right backend libraries depending if you're running in X11 or not.
Besides it is not new way but a explicit build flag ... not that bad.
>> >> > Also the deploy in the sysroot looks good (only libEGL-fb.so and non of
>> >> > the
>> >> > others are present) .... so the file-split is working, but there are no
>> >> > symblinks.
>> >> >
>> >> > I tried to fix this by creating symlinks manually in do_install:
>> >> >
>> >> > diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> >> > b/recipes- graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> >> > index 9818c72..af6dc82 100644
>> >> > --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> >> > +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
>> >> > @@ -91,6 +91,20 @@ do_install () {
>> >> >
>> >> > ${D}${libdir}/libGAL.so \
>> >> > ${D}${libdir}/libVIVANTE.so
>> >> >
>> >> > + if [ "${KEEP_XLIBS}" = "yes" ]; then
>> >> > + ln -s ${D}${libdir}/libEGL-x11.so ${D}${libdir}/libEGL.so
>> >> > + ln -s ${D}${libdir}/libGAL-x11.so ${D}${libdir}/libGAL.so
>> >> > + ln -s ${D}${libdir}/libVIVANTE-x11.so
>> >> > ${D}${libdir}/libVIVANTE.so
>> >> > + elif [ "${KEEP_DFBLIBS}" = "yes" ]; then
>> >> > + ln -s ${D}${libdir}/libEGL-dfb.so ${D}${libdir}/libEGL.so
>> >> > + ln -s ${D}${libdir}/libGAL-dfb.so ${D}${libdir}/libGAL.so
>> >> > + ln -s ${D}${libdir}/libVIVANTE-dfb.so
>> >> > ${D}${libdir}/libVIVANTE.so
>> >> > + else
>> >> > + ln -s libEGL-fb.so ${D}${libdir}/libEGL.so
>> >> > + ln -s libGAL-fb.so ${D}${libdir}/libGAL.so
>> >> > + ln -s libVIVANTE-fb.so ${D}${libdir}/libVIVANTE.so
>> >> > + fi
>> >> > +
>> >> >
>> >> > find ${D}${libdir} -type f -exec chmod 644 {} \;
>> >> > find ${D}${includedir} -type f -exec chmod 644 {} \;
>> >> >
>> >> > }
>> >>
>> >> Read obove...
>> >>
>> >> > I have absolutely NO idea if this is in anyway the right thing to do!
>> >> > I had errors, bitbake complaining about .so files not part of the -dev
>> >> > package ... but for some reason I don't get those anymore after I
>> >> > removed
>> >> > all of my other changes and just kept the 'ln -s'-lines ... so:
>> >> > If you think it the right way, just take it and submit v5 and/or commit
>> >> > it
>> >> > after v4 is merged.
>> >>
>> >> No; it is not.
>> >
>> > Because of the above or because the way I set the symlinks is wrong?
>>
>> Your code is right the problem is the concurrent build as explained above.
>>
>> >> > 3. I still got the following errors when starting any Qt5 application:
>> >> >
>> >> > vertex shader compilation error:
>> >> > fragment shader compilation error:
>> >> > program link error: No vertex shader attached.
>> >> >
>> >> > My setup: I do a image of my own, the main(!) contents of the image is:
>> >> > inherit core-image
>> >> > IMAGE_INSTALL += "libpng tslib libudev gpu-viv-bin-mx6q"
>> >> > IMAGE_FEATURES += "ssh-server-openssh tools-debug"
>> >> > DEPENDS = "gpu-viv-bin-mx6q libpng"
>> >> >
>> >> > Then I compile Qt5 git from outside of yocto, my configure line:
>> >> > ../qt5/configure -opensource -confirm-license -make libs -device imx6
>> >> > -device- option
>> >> > CROSS_COMPILE=~/projects/oe-yocto/fsl-community-bsp/imx6-
>> >> > build-10/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-
>> >> > gnueabi/arm-poky-linux-gnueabi- -sysroot
>> >> > ~/projects/oe-yocto/fsl-community-
>> >> > bsp/imx6-build-10/tmp/sysroots/imx6qsabrelite -prefix
>> >> > /opt/pelagicore/Qt5.0- yocto-imx6-10 -opengl es2 -no-pch -v
>> >>
>> >> This might be the cause of the problem. We need to build it using
>> >> Yocto toolchain so it links with proper library names or we raise the
>> >> errors we need to deal with. Can you give it a try?
>> >>
>> >> > This way I've compiled Qt5 against yocto builds for a while now.
>> >> > The only related problem I had in the past was the '#define mediump vs.
>> >> > heighp' which I could solve a patching Qt.
>> >> > This isn't helping anymore ... but I'm still investigating.
>> >>
>> >> Please check if you can build against the toolchain. To generate the
>> >> toolchain for your image do:
>> >>
>> >> bitbake <image> -c populate_sdk
>> >
>> > I already use the yocto toolchain and sysroot ... I think? ;)
>> > I'll checkout what does '-c populate_sdk' as soon as I find some time (I
>> > guess week after next week)
>>
>> Right; if I find the need time I will try to play with it as well.
Did you try the sdk?
--
Otavio Salvador O.S. Systems
E-mail: otavio@ossystems.com.br http://www.ossystems.com.br
Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br
^ permalink raw reply [flat|nested] 22+ messages in thread* Re: [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade
2013-02-26 17:39 ` Otavio Salvador
@ 2013-02-26 17:49 ` Thomas Senyk
2013-03-20 14:13 ` Erik Botö
0 siblings, 1 reply; 22+ messages in thread
From: Thomas Senyk @ 2013-02-26 17:49 UTC (permalink / raw)
To: Otavio Salvador; +Cc: meta-freescale
On Tue, February 26, 2013 14:39:18 Otavio Salvador wrote:
> On Tue, Feb 26, 2013 at 2:25 PM, Thomas Senyk
>
> <thomas.senyk@pelagicore.com> wrote:
> > On Fri, February 15, 2013 16:23:42 Otavio Salvador wrote:
> >> On Fri, Feb 15, 2013 at 3:10 PM, Thomas Senyk
> >>
> >> <thomas.senyk@pelagicore.com> wrote:
> >> > On Wed, February 13, 2013 19:11:59 Otavio Salvador wrote:
> >> >> On Wed, Feb 13, 2013 at 3:44 PM, Thomas Senyk
> >> >>
> >> >> <thomas.senyk@pelagicore.com> wrote:
> >> >> > On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote:
> >> >> > > On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador
> >> >> > >
> >> >> > > <otavio@ossystems.com.br> wrote:
> >> >> > > > Hello,
> >> >> > > >
> >> >> > > > This patch series upgrades the iMX6Q BSP to 1.1.0; it also try
> >> >> > > > to
> >> >> > > > fix
> >> >> > > > the DRI support for it.
> >> >> > > >
> >> >> > > > Please give it a try as this is a huge upgrade and we might have
> >> >> > > > regressions and pending issues still unkown. This series depends
> >> >> > > > on
> >> >> > > > a
> >> >> > > > cuple of patches I sent to OpenEmbeeded-Core mailing list for
> >> >> > > > xserver-xorg and mesa, please apply them before playing with
> >> >> > > > this
> >> >> > > > series.
> >> >> > >
> >> >> > > I've created a bundle for this series:
> >> >> > >
> >> >> > > OE-Core/Poky patches:
> >> >> > >
> >> >> > > http://patches.openembedded.org/bundle/otavio/oe-core-dri-patches/
> >> >> > >
> >> >> > > Meta-FSL-ARM patches:
> >> >> > >
> >> >> > > http://patches.openembedded.org/bundle/otavio/bsp-1.1.0-update/
> >> >> >
> >> >> > Nice thanks for the bundle.
> >> >> >
> >> >> > Most of my issues got fixed in v4! good job! :)
> >> >> >
> >> >> > The left overs:
> >> >> >
> >> >> > 1. After applied the upstream patches I got:
> >> >> >
> >> >> > ERROR: No recipes available for:
> >> >> > /home/tsenyk/projects/oe-yocto/fsl-community-bsp/sources/meta-fsl-
> >> >> >
> >> >> > arm/recipes-graphics/mesa/mesa-dri_9.0.1.bbappend
> >> >> > ERROR: Command execution failed: Exited with 1
> >> >> >
> >> >> > ... their is probably just some patch missing or something .. I just
> >> >> > deleted it and it was good ;)
> >> >> > I don't care that much about this one :) (I just wanted to report
> >> >> > this)
> >> >>
> >> >> Yes. I will check if we need to keep the bbappend or it is safe to
> >> >> drop
> >> >> it.
> >> >>
> >> >> > 2. The deploy and symlinks in the image look very good now:
> >> >> > lrwxrwxrwx 1 root root 12 Feb 13 17:49 libEGL.so ->
> >> >> > libEGL-fb.so
> >> >> > -rw-r--r-- 1 root root 803326 Feb 13 17:33 libGAL-fb.so
> >> >> > lrwxrwxrwx 1 root root 12 Feb 13 17:49 libGAL.so ->
> >> >> > libGAL-fb.so
> >> >> >
> >> >> > nice!
> >> >>
> >> >> Not that nice; in fact we shoudln't have the symlinks or X11 things
> >> >> might end linking against framebuffer libraries by mistake.
> >> >
> >> > This sounds rather unconventional ;)
> >> > I've never seen any platform were libEGL-something.so is the EGL target
> >> > to
> >> > link to.
> >> >
> >> > In general one should define the default flavor of the GPU-driver
> >> >
> >> > ... which is setting the libEGL.so symblink.
> >>
> >> For this the alternatives system might be a solution for the target.
> >> The problem is what to do during the build of applications. Think in
> >>
> >> such case:
> >> - gpu-viv is build
> >> - app-fb is build
> >> - app-x11 is build
> >>
> >> If we have libEGL.so how we manage to link each to the right one?
> >
> > Why would you support this anyway?
> > Having two EGL versions on your system/sysroot at the same time sounds
> > wrong doesn't it?
>
> At runtime, I agree but not at build time.
>
> > I'd say it depends on your DISTRO_FEATURES and you need to choice either
> > linuxfb, directfb or x11.
> >
> > ...and the rules are something like:
> > - is x11 in your DISTRO_FEATURES? => x11 version of drivers
> > - if not, is directfb in your DISTRO_FEATURES? => egl version of drivers
> > - if not: linuxfb version of drivers
>
> But distro features does not mean "enforce X11 use" but "allow X11
> use" so it seems we should support fb use even with X11 feature
> enabled.
>
> > <side note>
> > Besides that: You need to solve the "link to the right one" anyway, if you
> > have libEGL.so or not. (Although I admit it's more likely to cause
> > problems if you have it)
> > <\side note>
> >
> >> > In relation to the "link by mistake"-argument:
> >> > a) You have a fb-only setup: there will be no x11-things.
> >> > b) You have a x11 setup: the default is libEGL-x11.so and theirfor no
> >> > problem.>
> >> >
> >> > ... if on a x11 setup a application want to explicitly link against
> >> >
> >> > libEGL-fb.so it can do anyway, but at least the default on is set.
> >> > c) You have a dfb setup: the default link goes to libEGL-dfb.so
> >>
> >> This works well for runtime and I fully agree.
> >>
> >> I am concerned about how we will manage it at *build* time. Bear on
> >> mind that app-fb and app-x11 can be build in parallel so change the
> >> link during the build is not going to work.
> >
> > again: why support 2 build targets in the same sysroot?
>
> Read above.
>
> >> > How do applications within the yocto build link against libEGL?
> >> > There are generally no .pc file for GPU-drivers
> >> >
> >> > ... are there internal variables to reference?
> >>
> >> You may need to patch the application to link to one or another. Or
> >> play with LDFLAGS...
> >
> > That sounds intense...this would mean that one HW-layer (meta-fsl-arm)
> > tries to invent/enforce a new way of building application for
> > everybody(?)? Not sure this will thrive ;)
>
> Well, the "right" way of deal with it is to have a library which loads
> the right backend libraries depending if you're running in X11 or not.
> Besides it is not new way but a explicit build flag ... not that bad.
>
> >> >> > Also the deploy in the sysroot looks good (only libEGL-fb.so and non
> >> >> > of
> >> >> > the
> >> >> > others are present) .... so the file-split is working, but there are
> >> >> > no
> >> >> > symblinks.
> >> >> >
> >> >> > I tried to fix this by creating symlinks manually in do_install:
> >> >> >
> >> >> > diff --git a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> >> > b/recipes- graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> >> > index 9818c72..af6dc82 100644
> >> >> > --- a/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> >> > +++ b/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q.inc
> >> >> > @@ -91,6 +91,20 @@ do_install () {
> >> >> >
> >> >> > ${D}${libdir}/libGAL.so \
> >> >> > ${D}${libdir}/libVIVANTE.so
> >> >> >
> >> >> > + if [ "${KEEP_XLIBS}" = "yes" ]; then
> >> >> > + ln -s ${D}${libdir}/libEGL-x11.so ${D}${libdir}/libEGL.so
> >> >> > + ln -s ${D}${libdir}/libGAL-x11.so ${D}${libdir}/libGAL.so
> >> >> > + ln -s ${D}${libdir}/libVIVANTE-x11.so
> >> >> > ${D}${libdir}/libVIVANTE.so
> >> >> > + elif [ "${KEEP_DFBLIBS}" = "yes" ]; then
> >> >> > + ln -s ${D}${libdir}/libEGL-dfb.so ${D}${libdir}/libEGL.so
> >> >> > + ln -s ${D}${libdir}/libGAL-dfb.so ${D}${libdir}/libGAL.so
> >> >> > + ln -s ${D}${libdir}/libVIVANTE-dfb.so
> >> >> > ${D}${libdir}/libVIVANTE.so
> >> >> > + else
> >> >> > + ln -s libEGL-fb.so ${D}${libdir}/libEGL.so
> >> >> > + ln -s libGAL-fb.so ${D}${libdir}/libGAL.so
> >> >> > + ln -s libVIVANTE-fb.so ${D}${libdir}/libVIVANTE.so
> >> >> > + fi
> >> >> > +
> >> >> >
> >> >> > find ${D}${libdir} -type f -exec chmod 644 {} \;
> >> >> > find ${D}${includedir} -type f -exec chmod 644 {} \;
> >> >> >
> >> >> > }
> >> >>
> >> >> Read obove...
> >> >>
> >> >> > I have absolutely NO idea if this is in anyway the right thing to
> >> >> > do!
> >> >> > I had errors, bitbake complaining about .so files not part of the
> >> >> > -dev
> >> >> > package ... but for some reason I don't get those anymore after I
> >> >> > removed
> >> >> > all of my other changes and just kept the 'ln -s'-lines ... so:
> >> >> > If you think it the right way, just take it and submit v5 and/or
> >> >> > commit
> >> >> > it
> >> >> > after v4 is merged.
> >> >>
> >> >> No; it is not.
> >> >
> >> > Because of the above or because the way I set the symlinks is wrong?
> >>
> >> Your code is right the problem is the concurrent build as explained
> >> above.
> >>
> >> >> > 3. I still got the following errors when starting any Qt5
> >> >> > application:
> >> >> >
> >> >> > vertex shader compilation error:
> >> >> > fragment shader compilation error:
> >> >> > program link error: No vertex shader attached.
> >> >> >
> >> >> > My setup: I do a image of my own, the main(!) contents of the image
> >> >> > is:
> >> >> > inherit core-image
> >> >> > IMAGE_INSTALL += "libpng tslib libudev gpu-viv-bin-mx6q"
> >> >> > IMAGE_FEATURES += "ssh-server-openssh tools-debug"
> >> >> > DEPENDS = "gpu-viv-bin-mx6q libpng"
> >> >> >
> >> >> > Then I compile Qt5 git from outside of yocto, my configure line:
> >> >> > ../qt5/configure -opensource -confirm-license -make libs -device
> >> >> > imx6
> >> >> > -device- option
> >> >> > CROSS_COMPILE=~/projects/oe-yocto/fsl-community-bsp/imx6-
> >> >> > build-10/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linu
> >> >> > x-
> >> >> > gnueabi/arm-poky-linux-gnueabi- -sysroot
> >> >> > ~/projects/oe-yocto/fsl-community-
> >> >> > bsp/imx6-build-10/tmp/sysroots/imx6qsabrelite -prefix
> >> >> > /opt/pelagicore/Qt5.0- yocto-imx6-10 -opengl es2 -no-pch -v
> >> >>
> >> >> This might be the cause of the problem. We need to build it using
> >> >> Yocto toolchain so it links with proper library names or we raise the
> >> >> errors we need to deal with. Can you give it a try?
> >> >>
> >> >> > This way I've compiled Qt5 against yocto builds for a while now.
> >> >> > The only related problem I had in the past was the '#define mediump
> >> >> > vs.
> >> >> > heighp' which I could solve a patching Qt.
> >> >> > This isn't helping anymore ... but I'm still investigating.
> >> >>
> >> >> Please check if you can build against the toolchain. To generate the
> >> >> toolchain for your image do:
> >> >>
> >> >> bitbake <image> -c populate_sdk
> >> >
> >> > I already use the yocto toolchain and sysroot ... I think? ;)
> >> > I'll checkout what does '-c populate_sdk' as soon as I find some time
> >> > (I
> >> > guess week after next week)
> >>
> >> Right; if I find the need time I will try to play with it as well.
>
> Did you try the sdk?
A colleague did and said he has the same results is with the "normal"
toolchain/sysroot.
^ permalink raw reply [flat|nested] 22+ messages in thread