On Wed, Feb 27, 2013 at 12:11 PM, Thomas Senyk <[email protected]> wrote: > On Tue, February 26, 2013 19:25:41 Thomas Senyk wrote: >> Hi, >> >> I think it's time to start a independent thread about (my) inability to get >> anything OpenGL ES2.0 related running on the new BSP (aka.: "[PATCH v4 0/9] >> iMX6Q BSP 1.1.0 upgrade") >> >> fyi: I'm always building without 'x11' in DISTRO_FEATURES >> >> >> My findings so far: >> 1. Someone mentioned that it's possible to deploy/unpack the 1.1.0 drivers >> on top of a 12.04.01-image and still run Qt5. >> I can confirm this! >> This means it's NOT the libraries (aka. driver?) which are causing this >> problem! >> >> (From here on everything is based on a "PATCHv4"-build!) >> >> 2. I can't get any of the viv_samples running! >> Their behavior is rather erratic >> (sometimes errors and crashes, something just black screen nothing on >> stdout) ... I guess it's because they "pollute" the drivers-state if they >> crash... >> >> Anyway: Very often I get errors like: >> >> VertexShader: chiclet.vert: comiple error >> FragmentShader: chiclet.frag: comiple error >> ShaderProgram: null vertex program >> Segmentation fault >> >> >> .. which look very similar to the Qt errors I have: >> QOpenGLShader::compile(Vertex): failed >> Problematic Vertex shader source code *** >> attribute mediump vec4 vertexCoord; >> attribute mediump vec4 vertexColor; >> uniform mediump mat4 matrix; >> uniform mediump float opacity; >> varying lowp vec4 color; >> void main() { >> gl_Position = matrix * vertexCoord; >> color = vertexColor * opacity; >> } >> >> >> >> Can anyone confirm or contradict* this? >> >> *can you build a image bases on the PATCHv4, and any of viv_samples (which >> use es2.0) on the screen? >> >> >> >> 3. It's not because of former "highp"-error (I replaced all 'highp' within >> the Qt code with 'mediump') >> >> >> >> >> ... The next thing I'll do is build without PATCHv4 ... as some patches have >> already gone in (e.g. kernel) it might be that it's not about PATHv4, but >> rather about the patches already in. >> ... I'll give a update tomorrow. > > > ...I found it...this is...annoying :)
Great you found it. I am working in a v5. I will send it later today/tomorrow. > The way to solve a "broken build"* is to deploy: usr/lib/libGLSLC.so > ...libglslc-mx6-1.1.0-r5.0.imx6qsabrelite.rpm does get created, but nobody > depends on it (=> he is not installing it) > ... why? because** no other lib links against it(?***) > > So the solution (or rather workaround****) is to manually add a dependency > somehow?... I guess the libGLESv2-package should depend on libGLSLC-package or > something? Yes; it is. > *"broken build" == meta-fsl-arm HEAD + [PATCH v4 0/9] iMX6Q BSP 1.1.0 upgrade Good will fix it for v5. > **this is the fist reason I'm annoyed .. why would you not link against it if > you obviously going to need a GLSL-compiler?.. or not? > ... the second reason is that their isn't even the a tiny little error- > message pointing me in the right direction... Welcome :-) It is hard to fix problems when we do not have access to source code to look at ;-) > *** Is how the packaging works?.. does it check what missing libraries-links a > package has and creates rpm-dependencies out of that...? Yes; it checkes the symbols used and put a rdepends on the packages providing those. The problem here is that the library most probably is load at runtime (dlopen or so) and thus breaking this. > ****I think this is a error in the GPU-driver and should be fixed upstream > eventually I agree. -- Otavio Salvador O.S. Systems E-mail: [email protected] http://www.ossystems.com.br Mobile: +55 53 9981-7854 http://projetos.ossystems.com.br _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
