Buildroot:GSoC2014 Multimedia

From eLinux.org
Revision as of 11:07, 22 June 2014 by HadrienB (talk | contribs)
Jump to: navigation, search

Boards

From the 2013 Google Summer of Code:

  • Pandaboard (TI OMAP4)
    • 3D acceleration: normally supported by the ti-gfx package. Should work with EGL, support under X.org unknown.
      • No more upstream support (in TI SDK or IMG DDK) since a while. No need to spend time on it right now.
    • video decoding acceleration: unknown.
    • Misc: how does gst-omapfb fit in the picture?
  • BeagleBoneBlack (TI AM335x)
    • 3D acceleration: normally supported by the ti-gfx package. Should work with EGL, support under X.org unknown. Was not tested last year, since 3D acceleration was not ready yet at the time.
      • 3D acceleration OK in framebuffer. X.org support is not tested in latest TI SDK versions, didn't try it for now.
    • video decoding acceleration: unknown.
  • BeagleBoard XM (TI OMAP3)
    • 3D acceleration: normally supported by the ti-gfx package. Should work with EGL, support under X.org unknown.
    • video decoding acceleration: unknown.
  • SABRE (Freescale i.MX6)
    • 3D acceleration: normally supported by the gpu-viv-bin-mx6q package. Should work with EGL. For X.org, there are some patches pending.
    • video decoding acceleration: unknown.
  • Wandboard (Freescale i.MX6)
    • 3D acceleration: normally supported by the gpu-viv-bin-mx6q package. Should work with EGL. For X.org, there are some patches pending.
    • video decoding acceleration: unknown.
  • Cubieboard (Allwinner)
    • 3D acceleration: normally supported by the sunxi-mali package. Should work with EGL, support under X.org unknown.
    • video decoding acceleration: normally supported by the sunxi-cedarx package. Not sure with what they are interfaced, though.
  • ODROID-U2 (Samsung Exynos)
    • 3D acceleration: not done
    • video decoding acceleration: not done

To buy or get sponsored:

  • An x86 platform with an Intel card (to test full OpenGL support in Mesa)
  • An x86 platform with an AMD APU (ditto mesa3d)
  • A RaspberryPi:
    • 3D acceleration: through the rpi-userland package. Works with EGL, support under X.org unknown.
    • video decoding acceleration: through the rpi-userland and gst-omx packages.

Bonus:

  • An x86 platform with an NVidia card
    • using nouveau (to test full OpenGL support in Mesa)
    • using the NVidia blob (to be packaged)

TODO

Weekly reports

Week 21

Week 22

Day 1

  • OpenGL on BeagleBone Black
    • Defconfig based on beaglebone_defconfig with mainly ti-gfx
    • Kernel boot: OK
    • Init: OK
    • Fail to load ti-gfx module
      • track: fbset missing
  • Patchwork
    • #278305 (mesa3d-demos: new package): updating, currently not working

Day 2

  • OpenGL on BeagleBone Black
    • Still can't load ti-gfx module
      • Adding fbset eliminated of course one error
      • now /dev/fb0 is not found
  • Patchwork
    • #278305 (mesa3d-demos: new package): updated and rebased on master. Testing build for x86 failed :
      • with DRI i965 driver (depends on X.org and provides full libgl with mesa3d): failed because it needs glew (not yet packaged in BR).
      • with Gallium nouveau driver (provides only libgles and libegl with mesa3d): failed due to linking errors for xdemos/* binaries. No refererences to all OpenGL functions (mesa3d build fine, libs are installed, correct PATH).
      • at least glew is a dependency for full OpenGL/X.org demos.

Day 3

  • OpenGL on BeagleBone Black
    • Still can't load ti-gfx module
      • forget to select again OMAP DSS driver between two configs... But even with it /dev/fb0 is still missing.
  • Patchwork
    • #278305 (mesa3d-demos: new package): testing build for x86 was not a very good idea, as the support for mesa3d, especially on x86, is very recent and untested. Next builds will be done on RPi's OpenGL implementation.
      • build fine for RPi
      • no problem with the framebuffer, tested some non OpenGL program
      • but failed to execute es2gears_screen (mesa3d-demos) with error "EGLUT: EGL_MESA_screen_surface is not supported".

Day 4

  • OpenGL on BeagleBone Black
    • have to select FB_DA8XX_TDA998X in kernel config to have /dev/fb0
    • Still can't load ti-gfx modules, problem with symbols exportation. Have those errors :
      • pvrsrvkm: Unknown symbol v7_dma_map_area (err 0)
      • pvrsrvkm: Unknown symbol v7_dma_flush_range (err 0)

Day 5

Day 6

  • OpenGL on BeagleBone Black
    • ti-gfx OpenGL demos run fine in framebuffer, it's OK
    • sent patches to improve OpenGL support on BBB and fix fbset dependency for ti-gfx
  • Patchwork
    • #278305 (mesa3d-demos: new package): no solution to run it on RPi.

Week's summary

OpenGL on BBB is supported out of the box in framebuffer, demos run fine

Week 23

Day 1

  • ti-gfx: bump SDK version to 5_01_01_01, tested on BBB, patch sent
  • updating package/webkit to last version

Week's summary

  • bump WebKit to 2.4.3
    • need Pango >= 1.30.0
      • try Pango 1.36.3 (last version): fails, error during reconfigure: "gtk-doc.make:270: error: HAVE_GTK_DOC does not appear in AM_CONDITIONAL". Seems to need gtk-doc-am for an obscure raison. No patch yet.
      • try Pango 1.30.1: OK. Build fine, good enough for WebKit.
      • bump Pango to 1.30.1
    • enable EGL/GLES2 support fails. Doesn't find EGL/egl.h while it is there (finds well GLES2/gl2.h).
      • disable acceleration for now
  • had to provide again AR_FLAGS="cru" in WEBKIT_CONF_ENV to prevent ar to make thin archives and fix the error: `x' cannot be used on thin archives.
  • have a strange deadlock with parallel make, currently only on the build server (builds fine with -j8 on my laptop). make block and freeze on libWebCoreSVG.la (while: CXXLD libWebCoreSVG.la). Fine with -j1 (well, if >10 hours build time is fine). Is it the make version? Will try in a Debian chroot.
  • GTK3: new package
    • still some errors I resolve step by step.

Week 24

Day 1

  • bump WebKit to 2.4.3
    • the problem for finding EGL/egl.h only occurs with rpi-userland for now. With ti-gfx it's found.
      • libXcomposite and libXdamage are also needed with GLES/EGL (not only GL as previously).

Week's summary

  • test ti-gfx on Pandaboard: Pandaboard (and OMAP4 in general) is no longer supported by the SDK since a while (a version 4_04_XX_XX). As Pandaboard is used less and less and that there is no viable solution, this topic is abandoned for now.
  • test ti-gfx on Bragleboard xM: for now I have an error during the compilation of the kernel's module:

/home/hadrienb/buildroot/output/build/ti-gfx-5_01_01_01/GFX_Linux_KM/services4/3rdparty/dc_omapfb3_linux/omaplfb_linux.c: In function ‘OMAPLFBWaitForVSync’: /home/hadrienb/buildroot/output/build/ti-gfx-5_01_01_01/GFX_Linux_KM/services4/3rdparty/dc_omapfb3_linux/omaplfb_linux.c:180:92: error: ‘struct omap_dss_device’ has no member named ‘output’

#define OMAP_DSS_MANAGER(man, dev) struct omap_overlay_manager *man =

(dev) != NULL ? (dev)->output->manager : NULL

                   ^

/home/hadrienb/buildroot/output/build/ti-gfx-5_01_01_01/GFX_Linux_KM/services4/3rdparty/dc_omapfb3_linux/omaplfb_linux.c:821:2: note: in expansion of macro ‘OMAP_DSS_MANAGER’

 OMAP_DSS_MANAGER(psDSSMan, psDSSDev);
  • bump of imx-lib: Gary Bisson sent patches and I was not as advanced as he. I will test his next series.
  • webkit: still not found a solution for the parallel make hang with make 3.81.
  • libgtk3: need to bump libglib2 and pango. Have an error for pango related to font backend not found.

Week 25

Week 26

Week 27

Week 28

Week 29

Week 30

Week 31

Week 32

Week 33