I need to run a Qt project with VTK on Ubuntu and I'm using VirtualBox, but I have an error:
GL version 2.1 with the gpu_shader4 extension is not supported by your
graphics driver but is required for the new OpenGL rendering backend.
Please update your OpenGL driver. If you are using Mesa please make
sure you have version 10.6.5 or later and make sure your driver in
Mesa supports OpenGL 3.2.
Recent version of VTK use a new rendering backend by default. In the CMake cache file used to configure your build, the corresponding cmake variable VTK_RENDERING_BACKEND has the value "OpenGL2" which assumes a minimum OpenGL API version of 2.1. But the problem is that a vanilla installation of VirtualBox does not grant access to 3D acceleration by default as it cannot presumably infer these informations from the host system.
So I think that you have several options here depending on your needs and constraints, you could install the VirtualBox Guest Additions to enable hardware 3D acceleration, allow access to a newer version of the OpenGL API and use in the end the host to performs the requested 3D operations. You could also use a recent version of the Mesa3D library to performs the needed 3D operations on the CPU (to choose preferably if you don't have graphics hardware on the host). For a presentation of its features, you can take a look here
Related
I am setting up a Qt project which will be cross-copiled for a given display (running on ARM/Linux). The display will come with a self-contained cross-build toolchain which comprises Qt libraries with a specific Qt version (probably 5.15).
Now I would like to use a specific "static" toolchain incl. Qt libraries to also generate x86-builds of this Qt project (for testing, simulation; building/running on Linux and maybe also on Windows).
I'd avoid using the GCC and Qt development files introduced by the Linux package manager (e.g. apt), because the are not tied to a specific Qt version, i.e. upgrading the OS would always come with the risk to introduce build problems or break compatibility completely.
Are there good-practice approaches to achieve this?
So far I see three options:
Use a docker image
Possible problems:
Finding a image with the correct Qt version
building the Qt application would then work, but to execute it, the compatible Qt LGPL shared libs need to be available to the Qt application binary
Use a x86 -> x86 "standalone" toolchain
Find some standalone x86-toolchain analog to those (x86 -> x86), but additionaly...
it would either have to come with the Qt development files in the correct version
or we would have to build the Qt sources with this toolchain, and then extend the toolchain with the Qt built artifacts
Would be the preferred solution (and currently seems to be the most feasible of the approaches I can think of).
Virtual machine
Possible problems:
Finding a OS version with the correct Qt version
Select a OS version that contains the correct Qt version via package manager.
Not very elegant.
Qt online installer
only provides a limited choice of Qt versions (as of today: 5.15.2, 6.2.4, 6.3.2, 6.4.0) which is probably subject to change in the future
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]
I have installed the last version of QT but it seems that this one contains some DirectX calls, so I expect that the default installer use ANGLE !
I wish to install a 100% openGL version, but I can't find one !
Any idea ?
Thx
All official binary packages are configured with
-opengl dynamic
which means that programs can either use the installed (desktop) OpenGL driver, DirectX (via ANGLE), or an OpenGL emulation in software (Mesa) as OpenGL backends. If you always want to use Desktop OpenGL, you can force this by
Setting the environment variable QT_OPENGL to desktop
Calling QCoreApplication::setAttribute(Qt::AA_UseDesktopOpenGL)
See also http://doc.qt.io/qt-5/windows-requirements.html#graphics-drivers .
If you want a Qt version that only supports the Desktop OpenGL backend, you have to build Qt from sources.
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.
We have a desktop application built with Qt 4.8.4 which makes use of ICU. I am now porting that application to Qt 5.2.1. I notice a new configure option: -icu. What does this do? I'm trying to determine if I should use it or not.
I've read that it "enables ICU support." What does that mean? And does that matter for porting an application that is already using ICU under 4.8.4?
In case it matters: we plan to build on Windows, Mac OSX, and several Linux distros.
Note: our application does not use webkit.