This follows on from one of my previous questions but its probably more useful as a separate thread than a long continuous stream of comments.
So, bitbaking the angstrom-qt5-x11-image does not seem to include the Qt5 libraries as expected. Having followed this guide here, when the bitbaking is complete and the image is pushed to my target Apalis T30, none of the Qt5 libraries are present, only Qt4.8 libs.
When I follow the output of the bitbake, there is also no mention of any of the Qt5 packages being built - the only ones mentioned are Qt 4.8.X. Looking at other forum posts, the impression given is that the angstrom-qt5-x11-image already includes the Qt5 layers as part of the bitbaking process but what I have found is that only by explicitly adding the qtXXX packages into the IMAGE_INSTALL_append list do they then get included as part of the bitbake.
Is this supposed to be the case? In which case, to what end do I need to include entries in the IMAGE_INSTALL_append list? Likewise for things like samba, etc, does this need to go in here also?
The following line is taken from your guide:
One can build the following image
target that contains all Qt5 Packages:
angstrom-qt5-x11-image: for Qt 5 X11
image without desktop [build] $
bitbake -k angstrom-qt5-x11-image
Unfortunately the phrase contains all Qt5 Packages does not seem to be the case.
For example, take this link here for the Wandboard and Qt5. Would I need to add all of the Qt packages which has been mentioned in that article?
Again, this is all very new to me so maybe I have missed something. Apologies if this is a dumb question.
I assume you are doing something wrong somewhere along the way. As you may see here Qt5 stuff should of course already get included. You sure you did not inadvertently build the Qt4 image?
What exact versions of things are you trying to build? Build log files?
I downloaded the latest oe as specified in the Toradex guide (rocko, 2.8). I followed the instructions to ensure that ALL pre-requisites were installed. I changed the MACHINE setting in local.confand then followed the build instructions further down the guide.
I found that all through the build, there were no Qt5 references in the output. When I deployed the rootfs to the target, again, there were no Qt5 libs. The only way I got Qt5 to be bitbaked was to include it as per my previous comment on this thread.
WAIT…
Ah crap, I’ve just realised something… completely ignore everything I’ve just said
Sorry for the stupid questions.
Mental note, when I type that I’m actually bitbaking angstrom-qt5-x11-image, I need to make sure that I include the qt5 and not just qt. I’m an idiot!
So adding those entries to the IMAGE_INSTALL_append list enables Qt5 on the target.
The Qt5 qtdemo app runs (with display, after running the lvds-single-channel.sh script) but the only thing that does not seem to work are the OpenGL demos which can be launched from the qtdemo app - they don’t seem to be included or compiled as part of the bitbake.
Well, EGLFS is a completely different story. Unfortunately, EGLFS is not supported in any way by any of NVIDIA’s downstream BSPs. On Tegras OpenGL is really only supported on top of X11.
Rather than meta-toolchain-qt5 you may want to do bitbake your image with -c populate_sdk.
I used the bitbake -k meta-toolchain-qt5 rather than the -c populate_sdk - firstly, I deleted the sdk directory and then re-bitbaked. I now have a working toolchain and Qt5 toolchain.
As for the OpenGL side of things, how would I enable the OpenGL support?
I shall explain why I’m asking…
Our main Qt application makes extensive use of OpenGL (via QOpenGLWidget) for various sensor displays.
When testing the Qt example hellogl2, there are a couple of errors generated when running the application:
./hellogl2
QEGLPlatformContext: eglMakeCurrent failed: 3003
QOpenGLWidget: Failed to make context current
QEGLPlatformContext: eglMakeCurrent failed: 3003
QOpenGLWidget: Failed to make context current
However, the openglwindow example works just fine (spinning triangle)
UPDATE
The 2dpainting example also does not work due to the same errors as reported above. Out of the two widgets in this example, the native display works, the opengl display just shows a black box
I understand that, with not having EGLFS support, this is the reason why the QEGLPlatformContext is failing. However, I don’t understand why this is the default option?
Looking at the two example applications (the openglwindow and cube - working and not working, respectively) the only differences I can see is that one has a MainWidget derived from QOpenGLWidget (doesn’t work) whereas the other derives from QWindow but calls setSurfaceType(QWindow::OpenGLSurface)
When testing the Qt example hellogl2, there are a couple of errors generated when running the application:
Not all of the built Qt examples actually works on each platform. Whta exactly is the difference which makes them fail I do not know.
I understand that, with not having EGLFS support, this is the reason why the QEGLPlatformContext is failing. However, I don’t understand why this is the default option?
While not knowing all the details I think that sentence is wrong.
EGLFS is one of the graphical backend Qt can use, X11 is another. EGL is an interface between OpenGL ES and the underlying graphics HW, independent of the used graphical backend.
Note that for the T30 we don’t provide drivers which would allow to use EGLFS.
