Application fails with "Compiling Vertex shader failed" - qt

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.

Related

Out-of-tree galcore build causing Qt seg fault

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]

QT application on BeagleboneBlack

Hi I have a debian image on BBB I have already installed QT creator on B^3 but the problem is whenever I try to start a new project in qt creator, couldn't see any option of kit. Infact when i add qmake and compiler path the application throws error.
What can I do to solve the problem. Can i directly get the full pack of SDK from qt.io/download ?
You must compile Qt libraries for your device (BBB) on your own, using specified compiler. You can find more information on this topic, here:
Qt Cross-Compilation Options
As soon as you compile Qt libraries for your device, you must move them to appropriate directories (on your BBB).
First, I would suggest learning to cross-compile, it's much faster & more easily maintained when you want to move to new versions. There's a ton of documentation and community around doing this. Windows & Linux both of which are probably dated, but info is still relavent. I've heard it's much easier from a linux host, but that could be biased.
That being said, if you don't want to cross-compile I believe you can simply install the qt embedded libraries. This question may offer some good advice. Once you have the libraries installed, you should be able to use qmake directly to create the Makefile for your project, then you can use cmake, or g++, etc.. to do the actual compiling.
You're likely going to work in command line though, I'm not sure you can run QT Creator on the BBB directly. I could be wrong.

How can I compile Qt app in Linux using Windows style?

I'm developing a Qt Widgets application and due to compile performance issues, I started developing it in Linux Ubuntu instead of Windows. The problems is that, when compiled and run, the app appears with traditional Ubuntu style instead of Windows (7) style. Since the app is only for Windows, I'ld like to know how can I compile it inside Linux Ubuntu but making it appear with Windows style.
I tried using QApplication::setStyle(QStyleFactory::create("QWindowsStyle")); in main.cpp, without success. I guess the QtAssistant docs just aren't clear enough on how can I do this change. Any help will be appreciated.
Could you by any chance be using a Qt package that is compiled without the style? Can you try running QStyleFactory::keys() to verify that the style exists?
It can't be done, since the style's elements are rendered by Windows (or OS X), not by Qt. Qt's style implementation asks the OS libraries to provide bitmaps of those elements. If you wanted to, you could modify the style to use a disk cache for static items. You could then use the style on all platforms. The problem is that these OS-provided bitmaps are a part of the OS and thus non-redistributable.
The only plastform-specific style that at least used to be available everywhere was the old Windows 95 style, in times of Qt 3. I'm not sure what its current status is.
First check out put of QStyleFactory::keys()
then set the look by calling
qApp->setStyle("Windows");
This command will give you windows 98 look. If you want windows vista look you should configure qt sources with -style-windowsvista and rebuild all sources.
UPDATE
according to http://doc.qt.io/qt-5/qstylefactory.html#details qt style is not platform independent. So IT IS IMPOSSIBLE to have that native look in not windows platform. It's worth mentioning that in windows also Windows SDK itself is required in order to build sources of Qt otherwise your application will look like windows 98 in windows 7.

Google NaCl with Qt on Windows

I have a project which is using Qt 4.7.4 version (also I can't rebuild it using qt4.8 or qt5 – there are a lot of errors appears, project is big and not mine so fixing issues would be even harder than erasing the whole code and write new code). So I need to make this project, well, working on NativeClient.
Is it even possible? I use Windows and Visual Studio, I was trying to google instructions about qt+nacl on Windows but just can’t find nothing.
Also which pepper version should I use if it depends on it?
Is your qt build supporting native client?
Please check out this
Windows
The Qt-Nacl is not support, for now, in Windows.
By the way, here is the github repository dedicated for it -> https://github.com/msorvig/qt5-qtbase-nacl
In the file nacl-readme it is written :
[...] Windows is not supported as a host platform.
Linux
If you want to compile in Linux, I have made a script that will compile Qt5.4 with NaCl with all the dependencies needed.
https://gist.github.com/theshadowx/438297ac465874a5e226
I also made a video that will show the different steps and a showCase at the end :
https://www.youtube.com/watch?v=q2pMv1Svtqw

Re-built Qt5.0.2 with OpenGL, how to use with Qt Creator

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.

Resources