From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bk0-f45.google.com (mail-bk0-f45.google.com [209.85.214.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by yocto-www.yoctoproject.org (Postfix) with ESMTPS id 8A86EE00312 for ; Tue, 26 Feb 2013 09:25:05 -0800 (PST) Received: by mail-bk0-f45.google.com with SMTP id i18so1977340bkv.32 for ; Tue, 26 Feb 2013 09:25:03 -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=oU0MsdG3ZwGoSCDsb++89GggdQFhX1CwNwo/BGwAOJ8=; b=T6SQhfANJLRW2jhWUpfKjeY/kpxzgbj4Y44mtGnSErwVVcF0NxR6Lu/lEtAKQ5yexr pOycjgi2xWophEKcaOeBwYVTitwv2l9bseuDm1Qru+nzeVkxLhFutUI4DcVsx8PdYUGJ YM9yppsdDueDadqd/RM0DR+dhd78WGN2c3l7HtMIvLhx49R09f8SBT1tfmcQ92JvsH/5 fDVB8NntmAtlU8fDC7pCvUlDbzZzNk77zeswoKwfOkUdfCq7U4kEZ/9gvFumFHNI0BZb spfqGqi9HXi70TUMc+FeWa2O3KwYhq0JuurWHax3i1Vkbj7ptS5+ozZ5b7zSzm6BvOOD P3PQ== X-Received: by 10.204.11.68 with SMTP id s4mr6950248bks.74.1361899503528; Tue, 26 Feb 2013 09:25:03 -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 k4sm5088804bkv.18.2013.02.26.09.25.02 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 26 Feb 2013 09:25:02 -0800 (PST) From: Thomas Senyk To: Otavio Salvador Date: Tue, 26 Feb 2013 18:25:01 +0100 Message-ID: <3075219.gN57kmKb4R@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> <4933386.Lo2vlUKGBO@rudolf> MIME-Version: 1.0 X-Gm-Message-State: ALoCoQk/Ve4oRcZ3QRpSpk2eQn0NtnMLoeJrf3vFvkvoOYse+0ajH9U6SjgaWFRuStQ9U18UHFOc 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:25:06 -0000 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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? 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 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 -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,