[meta-freescale] results of building fsl-image-test/fsl-image-gui: can play hd videos on the console, but opengl under X11 is not working

Otavio Salvador otavio at ossystems.com.br
Wed May 1 18:59:56 PDT 2013

On Tue, Apr 30, 2013 at 7:03 PM, Christian Betz
<christian.betz at gmail.com> wrote:
> hi everyone,
> i'm working with a freescale imx6q dev board from freescale. though
> our freescale application engineers recommended LTIB, i already have
> experience using openembedded on two different arm platforms and x86
> (before yocto was created). in short: i want to use yocto, but i'll
> drop back to LTIB when I need to use it as a reference. and i'm
> willing to do what I can to help improve meta-fsl-arm.

We do need more people to help so it is a very welcome initiative :-)

> some quick background: our application involves using two features of
> the i.MX6 together: decoding video in the VPU and then rendering it
> using the GPU (using OpenGL). I know this is possible on LTIB, but
> maybe not with X11 (see links below). But my first goal with yocto is
> simple: prove that I can do each of these tasks individually before
> attempting them together.

You may do it in framebuffer as well. We currently have support for
the gst-plugin-gl so it might be of help. Drop 'x11' distro feature
and give it a go.

> On the first count, hardware video decoding: success! I was able to
> use gstreamer to play an HD video (directly on the console, no X11). I
> was using fsl-image-test.
> However, i've run into a wall with OpenGL support under X11. From what
> I can tell from reading the list, this is something Otavio might be
> working on. But let me provide some details anyway:

Well, X11 is not in good state yet for MX6 and it still have several
issues needing fixes.

> * I was using fsl-image-gui
> * my kernel cmd line: console=ttymxc0,115200 root=/dev/mmcblk1p2
> rootwait rw video=mxcfb0:dev=hdmi,1920x1080M at 60,if=RGB24.
> * Xorg starts fine and displays the app chooser
> * the main symptom appears to be undefined symbols in
> /usr/lib/dri/vivante_dri.so:
> ** first: there are these errors appearing the Xorg.0.log (this has
> been reported by others). My Xorg.0.log is attached.
> [1545980.369] (EE) AIGLX error: vivante exports no extensions
> (/usr/lib/dri/vivante_dri.so: undefined symbol: __driDriverExtensions)
> [1545980.369] (EE) AIGLX: reverting to software rendering
> ** next: there are some errors reported when I actually try to run an
> opengl app (i.e. qtdemo)
> root at imx6qsabresd:~# LIBGL_DEBUG=verbose DISPLAY=:0 qtdemo
> QIconvCodec::convertFromUnicode: using Latin-1 for conversion, iconv_open failed
> QIconvCodec::convertToUnicode: using Latin-1 for conversion, iconv_open failed
> libGL: screen 0 does not appear to be DRI2 capable
> libGL: XF86DRIGetClientDriverName: 4.1.0 vivante (screen 0)
> libGL: OpenDriver: trying /usr/lib/dri/tls/vivante_dri.so
> libGL: OpenDriver: trying /usr/lib/dri/vivante_dri.so
> libGL error: dlopen /usr/lib/dri/vivante_dri.so failed
> (/usr/lib/dri/vivante_dri.so: undefined symbol:
> __driUtilCreateNewScreen)
> libGL error: unable to load driver: vivante_dri.so
> libGL error: failed to load driver:
> libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so
> libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
> ** unsurprisingly, glxgears is really slow (4 fps) and i get the same
> error as above (undefined symbol: __driUtilCreateNewScreen)

You seem to be using Qt, move to Qt embedded :-)

> Is there some kind of API/version mismatch between the vivante driver
> and Xorg? I think i've discovered the correct recipe
> (gpu-viv-bin-mx6q.inc), but it looks like all this recipe does is
> unpack the closed source vivante binaries from the 1.1.0 release. For
> now I'm going to switch gears and see how these same things work using
> LTIB. But let me know if I can provide any more info.

We have; we didn't include the Vivante GL lib but if we do, we get
black screen in Xorg.

> One final, mostly unrelated note: as another user in another thread
> mentioned, I cannot boot *any* fsl-meta-arm image without commenting
> out all lines in /etc/udev.d/rules.d/automount.rules. The system
> appears to hang on 'Starting Bootlog daemon: bootlogd', but i did some
> debugging and traced the "hang" to line 213 in
> /etc/rcS.d/S37populate-volatile.sh, specifically where the 'sync'
> command is used. So it seems that automounting and
> populate-volatile.sh are interacting in a bad way: somehow a
> filesystem is getting mounted that is 'unsyncable', for lack of a
> better term. (worth noting: there are filesystems of unknown origin on
> the emmc, perhaps from an earlier android install since this is a demo
> board from our freescale rep). I'd be happy to poke around at this
> issue some more if somebody has any ideas.

The first boot slowness is due postinst being run. The automount is
when you have extended partitions in the SDcard (as a demo image from
Android, for example) and is fixed in OE-Core master (and will be in
1.4.1 I think).

> More details (including youtube video) of what I am trying to achieve:
> * http://imxcv.blogspot.com/2012/10/video-to-texture-streaming-part-3-imx6.html
> * http://imxcv.blogspot.com/2012/03/video-to-texture-streaming-part-2-imx6.html
> * https://github.com/andreluizeng/i.MX6-Video-Streaming-Texture
> --christian
> p.s. I am running Fedora 17. Let me know if you think that matters for
> any reason; i'll be installing an ubuntu 10.04 system to use LTIB
> anyway.

For Yocto it does not and if it does, it is a bug. I'd use a VM for
LTIB as I do hope it does not last too much ;-)


Otavio Salvador                             O.S. Systems
E-mail: otavio at ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br

More information about the meta-freescale mailing list