Debian, GraphicsSDK and Qt 4.8.6 problems

Hi,
I’m trying since some days to run a Qt OpenGL ES example application on my Beaglebone Black.

I’m using the latest debian image from beagleboard.org with the 3.12 kernel from Robert C Nelson’s linux-dev repository. The Graphics SDK was downloaded and compiled by the sgx-build-modules.sh script (which is also provided in the git repository from Robert). I copied the sgx folders to /opt on the BBB and ran the sgx-install script, which setups and loads the pvrsrv and omaplfb modules. The sgx graphic examples (EvilSkull, ChameleonMan, etc.) run like a charm. (Before compilation I had to change this line https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.12/sgx_build_modules.sh#L272 from “no” to “yes”, otherwise there is a EGL error when I want to start a graphics sdk example)

Now I want to compile Qt-4.8.6 applications with OpenGL ES support. I changed my qws mkspec to use OpenGL and use the same compiler which was used for compiling the kernel and the Graphics SDK (gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux). Also I had to apply these two patches: qt-configs/qt4.8 at master · prabindh/qt-configs · GitHub

My configure directive is:

./configure -v -opensource -confirm-license -prefix /opt/qt -embedded arm -platform qws/linux-x86-g++ -xplatform qws/linux-TIarmv7-sgx-g++ -depths 16,24,32 -no-mmx -no-3dnow -no-sse -no-sse2 -no-ssse3 -no-glib -no-cups -no-largefile -no-accessibility -no-openssl -no-gtkstyle -qt-mouse-pc -qt-mouse-linuxtp -qt-mouse-linuxinput -plugin-mouse-linuxtp -plugin-mouse-pc -fast -little-endian -host-big-endian -no-pch -no-sql-ibase -no-sql-mysql -no-sql-odbc -no-sql-psql -no-sql-sqlite -no-sql-sqlite2 -no-webkit -no-qt3support -nomake demos -nomake docs -nomake translations -qt-mouse-tslib -opengl es2 -qt-gfx-linuxfb -plugin-gfx-powervr -D QT_NO_QWS_CURSOR -D QT_QWS_CLIENTBLIT

After make install I’m copying the examples, libs and plugins to the BBB. Any non-opengl application works properly. But when I want to start the opengl_es2 example, a GLSurface error comes up:

debian@beaglebone:/opt/qt/examples/opengl/hellogl_es2$ sudo ./hellogl_es2 -qws -display powervr

QEglContext::createSurface(): Unable to create EGL surface, error = 0x300b

On the BBB display (HDMI) I can see the running Qt application, but there’s only a completely green area where the OpenGL rendering should happen.

Well, I don’t have any clue how to solve this problem. I even don’t know if it’s a problem with my Qt compilation OR my graphics sdk compilation. Maybe I’ve only missed to add a neccessary patch, which isn’t automatically applied by Robert C Nelson’s building scripts?

Many thanks in advance!
Greetings,
Marcel

Here I’ll provide some information which could be helpful to figure out the problem.
I disabled the window manager “lightdm”.

Hi,
I’m trying since some days to run a Qt OpenGL ES example application on my Beaglebone Black.

I’m using the latest debian image from beagleboard.org with the 3.12 kernel from Robert C Nelson’s linux-dev repository. The Graphics SDK was downloaded and compiled by the sgx-build-modules.sh script (which is also provided in the git repository from Robert). I copied the sgx folders to /opt on the BBB and ran the sgx-install script, which setups and loads the pvrsrv and omaplfb modules. The sgx graphic examples (EvilSkull, ChameleonMan, etc.) run like a charm. (Before compilation I had to change this line https://github.com/RobertCNelson/linux-dev/blob/am33x-v3.12/sgx_build_modules.sh#L272 from “no” to “yes”, otherwise there is a EGL error when I want to start a graphics sdk example)

Now I want to compile Qt-4.8.6 applications with OpenGL ES support. I changed my qws mkspec to use OpenGL and use the same compiler which was used for compiling the kernel and the Graphics SDK (gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux). Also I had to apply these two patches: https://github.com/prabindh/qt-configs/tree/master/qt4.8

My configure directive is:

./configure -v -opensource -confirm-license -prefix /opt/qt -embedded arm -platform qws/linux-x86-g++ -xplatform qws/linux-TIarmv7-sgx-g++ -depths 16,24,32 -no-mmx -no-3dnow -no-sse -no-sse2 -no-ssse3 -no-glib -no-cups -no-largefile -no-accessibility -no-openssl -no-gtkstyle -qt-mouse-pc -qt-mouse-linuxtp -qt-mouse-linuxinput -plugin-mouse-linuxtp -plugin-mouse-pc -fast -little-endian -host-big-endian -no-pch -no-sql-ibase -no-sql-mysql -no-sql-odbc -no-sql-psql -no-sql-sqlite -no-sql-sqlite2 -no-webkit -no-qt3support -nomake demos -nomake docs -nomake translations -qt-mouse-tslib -opengl es2 -qt-gfx-linuxfb -plugin-gfx-powervr -D QT_NO_QWS_CURSOR -D QT_QWS_CLIENTBLIT

After make install I’m copying the examples, libs and plugins to the BBB. Any non-opengl application works properly. But when I want to start the opengl_es2 example, a GLSurface error comes up:

debian@beaglebone:/opt/qt/examples/opengl/hellogl_es2$ sudo ./hellogl_es2 -qws -display powervr

QEglContext::createSurface(): Unable to create EGL surface, error = 0x300b

On the BBB display (HDMI) I can see the running Qt application, but there’s only a completely green area where the OpenGL rendering should happen.

Well, I don’t have any clue how to solve this problem. I even don’t know if it’s a problem with my Qt compilation OR my graphics sdk compilation. Maybe I’ve only missed to add a neccessary patch, which isn’t automatically applied by Robert C Nelson’s building scripts?

Is there a reason you want to use QT4.8 and not QT5.1.1? If you search beagleboard google groups for QT5.1.1, you will see a thread which shows you have to get QT5.1.1 working with Debian and kernel V3.12.

Regards,
John

Hi, thanks for your response!

I’ve read that Qt 5 only supports one window at a time. That’s why I want to use Qt 4.8 with QWS. Or is my information wrong? If it’s wrong, I could of course switch to Qt 5.

I’m even not sure if kernel v3.12 is right for me - because I need to activate the CAN bus with DTS, which isn’t good supported in this kernel. I’d prefer to use kernel v3.8, but there is no sgx support. (Nontheless, currently I only want to run a Qt OpenGL application, no matter which kernel)

Cheers,
Marcel

Hi, thanks for your response!

I’ve read that Qt 5 only supports one window at a time. That’s why I want to use Qt 4.8 with QWS. Or is my information wrong? If it’s wrong, I could of course switch to Qt 5.

I think what you need is xorg support which isn’t available for current release of SGX running on V3.8 or V3.12.

http://e2e.ti.com/support/arm/sitara_arm/f/791/t/298596.aspx?pi301021=1

I haven’t tried this myself, but perhaps you should try Wayland which is a windows manager that works with QT.

I’m even not sure if kernel v3.12 is right for me - because I need to activate the CAN bus with DTS, which isn’t good supported in this kernel. I’d prefer to use kernel v3.8, but there is no sgx support. (Nontheless, currently I only want to run a Qt OpenGL application, no matter which kernel)

There is SGX support in V3.8.

https://github.com/RobertCNelson/linux-dev/commit/c29d0000ed356595c216ab534417f44528c27464

Regards,
John

Hi,
the last days were more or less successful. I’ve got Qt 5.1.1 on kernel v3.12 running. But there’s no input device support and also no good cape support. So I’ll take distance to Qt 5 and specialize to Qt 4.8.6 with kernel 3.8 (Robert Nelson, linux-dev).

In your link to the TI forums, on the second last site, there was somebody able to run Qt 4.8.5 with kernel v3.8. He provided 3 patches, which seems to me like they’re implemented in Roberts repository. So I should have nothing to do there.
Next, I’ve downloaded the Graphics SDK 4.10.00.01 from http://downloads.ti.com/dsps/dsps_public_sw/gfxsdk/4_10_00_01/index_FDS.html (full package), installed it and adjusted the Rules to use the KERNEL directory and the same toolchain which was downloaded by Robert’s kernel build script (linaro 3.8, hardfp). After the compilation was done without any errors, I’ve copied the created /etc and /opt folder to my BBB and ran the installation script.
Unfortunately it doesn’t load the omaplfb kernel module (can’t remember the exactly error message, it was something meaningless like “error loading omaplfb”).

I’m going to re-setup my Beaglebone Black now with the above mentioned settings, because actually there’s kernel v3.12 running. Then I’m able to provide better error messages and details. But for all of that, maybe someone found an mistake in my procedure and can say what’s wrong (so I don’t recompile all the things now for the birds).

Many many thanks!

Regards,
Marcel