I use Yocto (Krogoth) to build my imx6 images and toolchains, however it's a bit heavy and slow for working on kernel drivers. As such my dev cycle is to build the kernel on its own, just using the output of a "do_patch" run in yocto as the source tree base and sourcing the toolchain environment.
This is normally not a problem, as mostly I'm focussed at that end of the s/w stack. However, I now need to be able to run a Qt application (running under eglfs) on top of my continually updated kernel, for a bug hunt. To do this, I need the imx6 graphics driver working, so I get the galcore source from git://github.com/Freescale/kernel-module-imx-gpu-viv.git export my kernel build directory, make it and deploy it. That module loads perfectly. However running the working application that has already been built with Yocto causes a crash, somewhere in libQt5EglDeviceIntegration.so.5. All the libs etc. are part of the original working image, the same place I took my kernel source from.
What do I need to do to make this work? Is there some part of Qt tied to the graphics driver that's going to force me to rebuild the entire library? What's the relationship between galcore.ko and Qt? Is there now a weird dependency between my application and the linux kernel?!
EDIT: PEBCAK. I'm an idiot. I didn't check out from the right SHA1 (that listed in the recipe) for the galcore driver. Still, the answer below is instructive, so I'd like to keep this question.
What do I need to do to make this work?
No idea. Maybe your self-built galcore.ko is incompatible with the binary blob OpenGL libraries from Freescale somehow? Does the original galcore.ko work correctly? How does the backtrace look?
Is there some part of Qt tied to the graphics driver that's going to force me to rebuild the entire library?
No need to rebuild Qt. While Qt is linked against the OpenGL library, the OpenGL ABI/API is stable and therefore a Qt rebuild isn't needed. Besides that, you aren't changing the OpenGL libraries.
What's the relationship between galcore.ko and Qt?
Qt uses OpenGL for rendering when using QtQuick. The OpenGL library (libGL.so and a few variants like libGLes2.so) is provided by Freescale as a binary blob. The OpenGL library makes syscalls that end up in the galcore.ko kernel module.
libQt5EglDeviceIntegration.so.5 is the part in Qt that does the first OpenGL calls to initialize OpenGL.
Is there now a weird dependency between my application and the linux kernel?!
Well, yes, indirectly via Qt -> libGL.so -> kernel [galcore.ko]
Related
I'm trying to get QtWebEngine running on a VM and am having difficulties. According to the answer to this question:
Eventually I realised that OpenGL 3.3 wouldn't work easily on virtual machines .. yet. I had to boot from ubuntu usb and work from there by installing latest mesa 3d package.
Is there a way to get QtWebEngine to work without OpenGL? I'm not directly using any OpenGL calls, nor do I need any 3d capabilities. I just want to embed a QWebEngineView to display dynamic HTML pages. I'm guessing this should be possible since Chrome works on the same VM without an issue.
I don't think there is a way to use the Qt WebEngine without OpenGL. It is not very explicitly said in the documentation, but here's what I understood from what I found.
About Chromium
As it is said here, QtWebEngine integrates chromium's fast moving web capabilities into Qt. Plus, it is Chromium that allows the manipulation of OpenGL via the Qt Quick scene graph (source) :
Chromium is tightly integrated to the Qt Quick scene graph, which is
based on OpenGL ES 2.0 or OpenGL 2.0 for its rendering. This provides
you with one-pass compositing of web content and all the Qt Quick UI.
The integration to Chromium is transparent to developers, who just
work with Qt and JavaScript.
It is also said that both the render process and the GUI process should share an OpenGL context :
Because the render process is separated from the GUI process, they
should ideally share an OpenGL context to enable one process to access
the resources uploaded by the other, such as images or textures.
About the Qt WebEngine itself
We just talked about the Qt's GUI : in fact, the Qt WebEngine is not dependent of this GUI (page rendering and JavaScript execution are separated from the GUI process into the Qt WebEngine process), but remember that if you want your application to work, you will need to share an OpenGL context between both processes. In particular, this is achieved by default with a QSurfaceFormat, which has a OpenGLContextProfile accessible by the function QSurfaceFormat::profile(). Now, we look back at the Qt WebEngine platform notes which states :
If a new default QSurfaceFormat with a modified OpenGL profile has to
be set, it should be set before the application instance is declared,
to make sure that all created OpenGL contexts use the same OpenGL
profile.
On OS X, if the default QSurfaceFormat is set after the application
instance, the application will exit with qFatal(), and print a message
that the default QSurfaceFormat should be set before the application
instance.
If we look at the source code of Qt, calls to OpenGL are made in several important files, like qtwebengine\src\core\web_engine_context.cpp or qtwebengine\src\webengine\api\qtwebengineglobal.cpp. Moreover, I also found calls to OpenGL in functions from the sources in qtwebengine\src\3rdparty\chromium\, so I suspect that Chromium needs to call OpenGL functions sometimes.
In short
The Qt WebEngine is using Chromium (which doesn't necessarily use OpenGL) and also Qt GUI, which uses an OpenGL context which has to be shared by the Web Engine. Thus, my conclusion is that you can't use the Qt WebEngine without OpenGL.
I had the same problem on my VM environment trying to start an application that uses QtWebEngine and it crashed.
I will add this answer as a reference - although Sergey Khasanov mentioned it already in the comment above
Use Software Qt Quick2DRenderer - see https://doc.qt.io/QtQuick2DRenderer/
To do that, simply set the environment variable:
export QMLSCENE_DEVICE=softwarecontext
then restart your application. It might still complain about
libEGL warning: GLX/DRI2 is not supported
libEGL warning: DRI2: failed to authenticate
but (in my case) it finally worked!
I'm using Qt 5.2.1 and have compiled it for OpenGL (using build-option "-opengl desktop"). Now when I try to use a component that should make use of OpenGL, it fails with a
qFatal("Compiling Vertex shader failed")
All other Qt-applications that do not use OGL still work fine. The test-application mentioned above is just a ready-to use demo, no self-written crap.
Any idea what the reason could be or what I could check to find out what's wrong?
Thanks!
Windows only supports DirectX and OpenGl 1.1 by default. You'll get this error, among others, if you don't have proper OpenGL drivers installed.
Try installing drivers from your graphics card's vendor web site (not the ones installed by Windows automatically), which should include a proper opengl32.dll.
Using Qt with ANGLE would also solve it, if this is your problem.
I need to move my code from a C++/OpenGL and Config.txt situation to a UI friendly space. I was told here to try Qt and installed it in Windows.
The issue I ran into is that it did not support the OpenGL version I needed out of the box and I had to rebuild with the -opengl desktop parameter.
First time doing this, but was able to follow the instructions (and a ton of Google) and it "succesfully" was built. My issue now is I am unsure how to make the files I have work with Qt Creator.
I copied over all the folders from the qt5 folder created by git over to the Src folder in Qt5.0.1/5.0.1/Src but the hellogl example still wouldn't build.
I checked the options and it was pointing to a qmake in Qt5.0.1/5.0.1/msvc2010/bin so I copied over the qmake.exe from qtbase/qmake over to this folder (renaming the old one) and now Qt Creator builds the hellogl example on my Windows system.
My worry is, did I do this the right way? I fumbled around and got something, but is this the way I should have proceeded after I built the qt5 from git? If not what was the way I should have gone about making it all work with the Qt Creator?
The typical way to utilize the modern OpenGL the feature set (post fixed-function pipeline) in Qt is by utilizing a extension wrangler (GLEW) that finds all the OpenGL functions your graphics drivers support BEFORE Qt includes any OpenGL headers.
To accomplish this simply do the following:
If you already haven't, download GLEW (or another extension wrangler if you wish) and install it in your system path. I would recommend the 32 bit package as it will be easier to work with.
#include glew.h in your source code before any other Qt header includes that may use OpenGL headers. Just to be safe, make glew.h the first header included in your source code.
In your Qt project's .pro file add the line LIBS += -lGLEW (mac/linux) or LIBS += -lglew32 (windows).
Note: Beware of using Qt OpenGL wrappers when implementing an application that uses post fixed-function pipeline facilities. Qt 5's OpenGL wrappers all operate using the OpenGL ES 2.0 specification which may cause problems when interleaved with your OpenGL 3/4 code. Even QPainter can become troublesome when performing overpainting on a QGLWidget due to it's heavy use of the fixed-function transformation stack. I am currently developing a library called QGLX that provides alternative Qt wrappers designed for complying to the modern desktop OpenGL specification. The beta will hopefully be released by the end of this year for Qt 4 & Qt 5.
I'm developing a closed source application and to do so in accordance with the LGPL I have to dynamically link Qt's libraries to my application. Does Qt do this by default or do I have to take steps to do so? If that's the case how would I go about doing it?
Qt uses dynamic linking by default.
You'll notice this immediately during deployment to a non-developer machine, because your code will not run without the Qt libraries.
If your concern is the LGPL, just be careful when compiling Qt itself. Most LGPL violations with Qt are not because of static linking (since dynamic is the default), but for compiling Qt with non-default parameters.
LGPL is not just that the library must be provided along your binaries, but also that you specify how your users can build themselves the LGPL part. If you compile Qt yourself and do not use the pre-compiled binaries from the website, you must document that part of your build configuration in your release!
As soon as you get something running on your program, start preparing a release version for a non-developer environment without Qt installed. Your program should fail as soon as you delete the DLLs that you must copy along your program (or whatever format your OS uses).
It does it by default, statically linking seems to be quite involved judging by the many questions on the site regarding it.
Whats the best way to deploy a QT app? I've read the documentation hosted at trolltech but is it better to link with a static library or the dynamic libraries and have the user install the framework? I don't really want anyone using my app to have to download a 160mb framework just to run a simple gui frontend.
On OS X it's a good way to do a dynamic build and post-process the resulting ".app" with the macdeployqt tool which comes with Qt starting with 4.5.
This will copy the Qt frameworks used by your application into the application bundle, which results in a larger package than building a static version of your application.
Here is what you can do to make sure you get the smallest file size possibly in a dynamic build:
First off, make sure you only include the stuff you need (in the project.pro file's QT += core gui network xml lines).
Open the application bundle and remove any unneeded "Qt Plugins" from the bundle. macdeployqt automatically compies all the Qt plugins in there, which can be kind of bulky.
Make sure you are building your application in release mode. Otherwise your application might be linked against the debug libraries of the Qt4 framework, and they are really big (for instance, well over 90 MB for the debug library vs. 16 MB of a release variant without debugging symbols). This might be what happened in your case.
If you have a large application binary, you can use UPX to compress your executable file by 40-50%.
Other than that, you should use compressed disk images to deploy your application.
One of my projects uses QtGui, QtNetwork, QtCore and QtXml and the resulting bundle is about 16 MB in size.
Hope that helps.
Unfortunately you will have to include the Qt libraries you need into your own bundle, as you cannot expect your users to have Qt installed on Mac (whereas on Linux packaging systems allow you to require at least a given version of Qt.
There is a nice tool to help you with that, which is called macdeployqt. You just need to invoke it on your bundle application and it will pack the required libraries, changing the linkage of your binary to refer to them. Without it, making bundles for Mac is a real pain (it still is, but considerably less though).
http://doc.trolltech.com/4.6/deployment-mac.html#the-mac-deployment-tool
Afterwards, you can make a .dmg image as you would do with any other app. There is an option in macdeployqt that builds a basic one.
On Linux, it's better to rely on the OS's copy of Qt, as it's almost certainly installed - for OS X, almost all apps use a statically compiled library.