On Wed, 23 Sep 2015 11:53:46 -0400 Trevor Woerner <[email protected]> wrote:
> I'm working with the cubietruck and I'm performing my builds using > OpenEmbedded. > > The OpenEmbedded recipe > (https://github.com/linux-sunxi/meta-sunxi/blob/master/recipes-kernel/linux/linux-sunxi_3.4.bb) > currently pins the kernel at commit > "e37d760b363888f3a65cd6455c99a75cac70a7b8", which correlates to 3.4.90. > I hadn't noticed this before, I'll unpin my build to use the latest. OK. Then the kernel should be fine. However normally people first try something that is known to work, such as the instructions from http://linux-sunxi.org/Mali_binary_driver And only then begin experimenting. But you are experimenting right from the start. Unfortunately, I can't provide support for solving problems, which are specific to OpenEmbedded. > >> I can't seem to get my build to work, I keep getting errors such as: > >> > >> Error: Unable to choose an EGL config > >> > >> or > >> > >> eglChooseConfig() failed > >> > >> or > >> > >> Error: couldn't get an RGB, Double-buffered visual > > What exactly are you doing to make it fail this way? > > To be honest I'm not entirely sure what I should be trying. The "Verifying the EGL/GLES driver stack" section in http://linux-sunxi.org/Mali_binary_driver suggests to try a very simple triangle demo program first. > So I've built the "mesa-demos" recipe > (http://layers.openembedded.org/layerindex/recipe/4686/) and am trying > to run some of its artifacts. Examples include: eglgears_x11, eglinfo, > eglkms, glxdemo, glxgears, xeglgears, xeglthreads... Anything with "glx" in its name is not going to be supported by the Mali drivers, because GLX is the desktopish OpenGL thing: https://en.wikipedia.org/wiki/GLX And if you got Mesa installed together with the Mali blobs, then this is really asking for troubles: http://lists.freedesktop.org/archives/mesa-dev/2013-August/043219.html "It seems to be a rather common failure scenario when some big bloatware application loads both libGL.so (provided by Mesa) and libGLESv2.so (provided by some proprietary OpenGL ES driver on ARM hardware) into the same process via indirect library dependencies. These shared libraries are providing overlapping function names, but are backed by totally different implementations. And everything blows up as a result when the application is run, or maybe it even mostly works if you are lucky." And for additional information also see: http://stackoverflow.com/questions/14680481/how-to-link-with-two-shared-libraries-with-many-conflicting-functions > My output from eglinfo is: > > EGL API version: 1.4 > EGL vendor string: ARM > EGL version string: 1.4 Linux-r3p0-04rel0 > EGL client APIs: OpenGL_ES > EGL extensions string: > EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap > EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image > EGL_KHR_gl_renderbuffer_image EGL_KHR_reusable_sync > EGL_KHR_fence_sync EGL_KHR_lock_surface EGL_KHR_lock_surface2 > Configurations: > bf lv colorbuffer dp st ms vis cav bi renderable supported > id sz l r g b a th cl ns b id eat nd gl es es2 vg surfaces At least this looks good. -- Best regards, Siarhei Siamashka -- You received this message because you are subscribed to the Google Groups "linux-sunxi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
