[Buildroot] AM3517 Neon, OpenGL & EGLFS support
thomas.petazzoni at free-electrons.com
Fri Jun 7 16:48:29 UTC 2013
Dear Charles Krinke,
On Fri, 7 Jun 2013 08:40:40 -0700, Charles Krinke wrote:
> You touch on the key piece of understanding I am seeking.
> Unfortunately some of this understanding is obfuscated by similar
> terms used by different groups.
> In the AM3517, there is a source tree called the "Graphics_SDK". And
> it contains, I believe, EGL and OpenGL implementations for the AM3517
> and other SoC from TI. Wojciech patch does define several variables
> which include headers and libraries for Qt.
> I *think* we are 99% there and the missing part is this library
> constant from Raspberry Pi, but, ... because all the alphabet soup is
> different between Ti, Qt, and the rest of the opensource community, we
> get to deal with ambiguity a bit.
I am not sure what is confusing you here. OpenGL, EGL, OpenVG and so on
are APIs. Those APIs are provided by different implementations,
depending on which SoC you're using. Those implementations are
generally provided by libraries given by the SoC vendor. So in
Buildroot, a package that needs OpenGL doesn't depend directly on a
specific OpenGL implementation. Instead, it depends on 'libgles',
which is a virtual package that guarantees that *one* OpenGLES
implementation has been selected in the system.
The rpi-userland is currently the only OpenGL implementation that we
support in Buildroot (but more are coming!). So what the rpi-userland
package does in its Config.in is:
This "announces" to packages like Qt that an OpenGLES, an EGL, an
OpenVG and an OpenMAX implementation is available. Therefore, packages
like Qt are allowed to depend on virtual packages libgles, libegl,
libopenvg and libopenmax.
In turn, those virtual packages do the following:
LIBGLES_DEPENDENCIES += rpi-userland
echo "No libGLES implementation selected. Configuration error."
This allows to make the virtual package 'libgles' depend on
'rpi-userland' is this package is selected. However, if no dependency
exists of libgles, it means that no OpenGL implementation was selected,
which is an error: some packages (Qt for example) uses the libgles
dependency, but no OpenGLES implementation has been enabled in the
Again, just wait for Spenser to post his patches, it should make OpenGL
work out-of-the-box for AM3xxx.
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
More information about the buildroot