From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bk0-f49.google.com (mail-bk0-f49.google.com [209.85.214.49]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by yocto-www.yoctoproject.org (Postfix) with ESMTPS id 0A295E002AB for ; Tue, 26 Feb 2013 09:49:24 -0800 (PST) Received: by mail-bk0-f49.google.com with SMTP id w11so1992898bku.22 for ; Tue, 26 Feb 2013 09:49:23 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type:x-gm-message-state; bh=RILFpHoOEd5ng+EPcSseb3q8vbp14w94FftnbZ8zRVY=; b=Bgx8AksUgXifyZMnedcIQYHVg9GC1CJJWieJbetzuWBKraoikGIeUICX472l97lCmT gJWETbLK+Z3mHjVoyU1c/cx5V2e8evNxuPg4K10OJyRo+bp8dRSCQLZeEwB/riFUUEHn wZ00chHF218G4SOPjBws6OHgi8DTzRQeuiCbfo5fZxXJ69X5CHKpTLvm97BuX2uCTxoM ceU+t4IAK4HlfZeoG3mOE7BqPP7lLERJCCRZELHEdoGHi+zOnmSP2fdZZ2b8BfH9gcwB Rgyrkc9iajkRFx6kVB6oZu2139yoNDASEAsPb9Tx26u1eFn1+wXvSKTQ81S7FZ3oLeJf Tgvg== X-Received: by 10.205.118.16 with SMTP id fo16mr1517031bkc.61.1361900963228; Tue, 26 Feb 2013 09:49:23 -0800 (PST) Received: from rudolf.localnet (ppp-88-217-8-202.dynamic.mnet-online.de. [88.217.8.202]) by mx.google.com with ESMTPS id o2sm5126337bkv.3.2013.02.26.09.49.22 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 09:49:22 -0800 (PST) From: Thomas Senyk To: Otavio Salvador Date: Tue, 26 Feb 2013 18:49:19 +0100 Message-ID: <2868113.54n3uXbGaY@rudolf> Organization: Nokia User-Agent: KMail/4.10 (Linux/3.7.7-1-ARCH; KDE/4.10.0; x86_64; ; ) In-Reply-To: References: <1360706330-12665-1-git-send-email-otavio@ossystems.com.br> <3075219.gN57kmKb4R@rudolf> MIME-Version: 1.0 X-Gm-Message-State: ALoCoQlOdIXIWHyEx8TWLRgH8KYluliKI3jE2PMY1TVMjzKozqoYOdwo71e8vkstDp1+8GgQqjOF Cc: "meta-freescale@yoctoproject.org" Subject: Re: [meta-fsl-arm][PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade X-BeenThere: meta-freescale@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Usage and development list for the meta-fsl-* layers List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2013 17:49:25 -0000 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" On Tue, February 26, 2013 14:39:18 Otavio Salvador wrote: > On Tue, Feb 26, 2013 at 2:25 PM, Thomas Senyk > > wrote: > > On Fri, February 15, 2013 16:23:42 Otavio Salvador wrote: > >> On Fri, Feb 15, 2013 at 3:10 PM, Thomas Senyk > >> > >> wrote: > >> > On Wed, February 13, 2013 19:11:59 Otavio Salvador wrote: > >> >> On Wed, Feb 13, 2013 at 3:44 PM, Thomas Senyk > >> >> > >> >> wrote: > >> >> > On Tue, February 12, 2013 19:59:45 Otavio Salvador wrote: > >> >> > > On Tue, Feb 12, 2013 at 7:58 PM, Otavio Salvador > >> >> > > > >> >> > > 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. > > > > > 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 -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.