Problems getting Qt running on embedded device..

BradWalker · 4 Dec 2018, 15:10

I am having just a real bear of time getting the Qt library running on my embedded devices. A little background is in order here.. I'm an embedded engineer and know that domain pretty well.. Using Qt is not my domain. But, I have followed the directions and manged to get the Qt library to compile for my Xilinux FPGA board. And it seems to be running.

But, Qt is giving me real fits when I run a simple application.

Here is my simple app..

#include <QtWidgets/QApplication>
#include <QtWidgets/QPushButton>

int main(int argc, char *argv[])
{
     QApplication app(argc, argv);

     QPushButton hello("Hello world!");
     hello.resize(100, 30);

     hello.show();

     return app.exec();
}

Yet, I get error messages on the console when I try to start it..

I've enabled debug output in qtbase/src/gui/painting/qpainter.cpp and here is what I see on the console..

root@petalinux:/tmp# /tmp/qt-test-app
No such plugin for spec  "tslib:/dev/input/event0"
QPainter::begin(), device=0xbe998bd0, type=1
QWidget::paintEngine: Should no longer be called
QPainter::begin: Paint device returned engine == 0, type: 1
QPainter::pen: Painter not active
QPainter::setPen(), color=ffffffff
QPainter::setPen: Painter not active
QPainter::drawPolyline(), count=3
QPainter::setPen(), color=ff767472
QPainter::setPen: Painter not active
QPainter::drawPolyline(), count=3
QPainter::setPen(), color=ffefebe7
QPainter::setPen: Painter not active
QPainter::drawPolyline(), count=3
QPainter::setPen(), color=ff9f9d9a
QPainter::setPen: Painter not active
QPainter::drawPolyline(), count=3
QPainter::setPen(), color=ff000000, (brushStyle=1) style=1, cap=16, join=64
QPainter::setPen: Painter not active
QPainter::pen: Painter not active
QPainter::setPen(), color=ff000000, (brushStyle=1) style=1, cap=16, join=64
QPainter::setPen: Painter not active
QPainter::drawText(), r=[2,2,96,26], flags=2180, str='Hello world!'
QPainter::setPen(), color=ff000000, (brushStyle=1) style=1, cap=16, join=64
QPainter::setPen: Painter not active
QPainter::begin(), device=0x235b8, type=3
QPainter::begin: Paint device returned engine == 0, type: 3
QPainter::setCompositionMode: Painter not active
QPainter::begin(), device=0x240c0, type=3
QPainter::begin: Paint device returned engine == 0, type: 3
QPainter::setCompositionMode: Painter not active
QPainter::begin(), device=0xbe998bd0, type=1
QWidget::paintEngine: Should no longer be called
QPainter::begin: Paint device returned engine == 0, type: 1
QPainter::pen: Painter not active
QPainter::setPen(), color=ffffffff
QPainter::setPen: Painter not active
QPainter::drawPolyline(), count=3
QPainter::setPen(), color=ff767472
...

Any advice on what I might be missing here is most appreciated !!

-brad w.

BradWalker · wrote on 1 Nov 2017, 15:50

@SGaist

Turns out the problem is that my framebuffer is using RBG (yes, I meant to say red-BLUE-green) color format.

The LinuxFB plugin only checks for RGB or BGR and fails silently. Once I determined this, I was able to modify qlinuxfbscreen.cpp and now it work correctly.

Thanks very much for your help! It turns out that your efforts did, in fact, help me to figure this out.

I filed a bug for this: GTBUG-64169

SGaist · wrote on 27 Oct 2017, 20:03

Hi and welcome to devnet,

Can you give more information about:

The Qt version your are using
The Linux distribution you are using on your target ?
What CPU architecture you are using on your FPGA ?
What graphical capabilities does it provide ?

BradWalker · wrote on 27 Oct 2017, 21:56

@SGaist said in Problems getting Qt running on embedded device..:

The Qt version your are using

5.6.3 opensource

Linux distribution you are using on your target

Petalinux 2016.4

CPU architecture you are using on your FPGA

arm-linux-gnueabihf-g++

graphical capabilities does it provide
800x600 (RGB888).. I can draw on the screen using the /dev/fb0 interface directly.. So my h/w is functional.

In addition, when I do an strace on my Qt app, I do see the Qt library open /dev/fb0 and issue screen info ioctls. Lastly, the mmap() does succeed for the proper memory space.

Any advice is most appreciated as I'm looking at the low level guts of Qt. It looks like the following code in qpainter.cpp is causing me problems.

 d->engine = pd->paintEngine();

    if (!d->engine) {
        qWarning("QPainter::begin: Paint device returned engine == 0, type: %d", pd->devType());
        return false;
    }

SGaist · 29 Oct 2017, 04:41

Are you using the LinuxFB backend ?

BradWalker · S SGaist 27 Oct 2017, 22:17

@SGaist

Are you using the LinuxFB backend ?

Yes. I have a very basic program that I wrote that opens /dev/fb0 issues the FB ioctls and then based on the information, will mmap() the framebuffer and draw graphics on it. So I believe my framebuffer is correct.

SGaist · 30 Oct 2017, 01:22

Are you sure the LinuxFB plugin is loaded when you start your application ?

BradWalker · S SGaist 29 Oct 2017, 20:21

@SGaist

Are you using the LinuxFB backend ?

I'm pretty certain..

Here is what my env. looks like.

root@petalinux:/tmp# env | grep QT
QT_QPA_PLATFORM_PLUGIN_PATH=/usr/lib/plugins/platforms
QT_QPA_GENERIC_PLUGINS=tslib:/dev/input/event0
QT_QPA_FONTDIR=/usr/lib/fonts
QT_QPA_PLATFORM=linuxfb
QT_PLUGIN_PATH=/usr/lib/plugins
root@petalinux:/tmp#

And here is what strace shows when executing the app..

...
lstat64("/usr", {st_mode=S_IFDIR|0755, st_size=200, ...}) = 0
lstat64("/usr/lib", {st_mode=S_IFDIR|0755, st_size=2200, ...}) = 0
lstat64("/usr/lib/plugins", {st_mode=S_IFDIR|0775, st_size=160, ...}) = 0
lstat64("/usr/lib/plugins/platforms", {st_mode=S_IFDIR|0775, st_size=100, ...}) = 0
lstat64("/usr/lib/plugins/platforms/libqlinuxfb.so", {st_mode=S_IFREG|0755, st_size=708936, ...}) = 0
open("/usr/lib/plugins/platforms/libqlinuxfb.so", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
fcntl64(3, F_SETFD, FD_CLOEXEC)         = 0
fstat64(3, {st_mode=S_IFREG|0755, st_size=708936, ...}) = 0
fstat64(3, {st_mode=S_IFREG|0755, st_size=708936, ...}) = 0
mmap2(NULL, 708936, PROT_READ, MAP_SHARED, 3, 0) = 0xb5cde000
close(3)                                = 0
munmap(0xb5cde000, 708936)              = 0
...

SGaist · 1 Nov 2017, 15:50

Did you try to set the size of the screen just in case ?

The options are described here.

BradWalker · wrote on 1 Nov 2017, 15:50

@SGaist

Turns out the problem is that my framebuffer is using RBG (yes, I meant to say red-BLUE-green) color format.

The LinuxFB plugin only checks for RGB or BGR and fails silently. Once I determined this, I was able to modify qlinuxfbscreen.cpp and now it work correctly.

Thanks very much for your help! It turns out that your efforts did, in fact, help me to figure this out.

I filed a bug for this: GTBUG-64169

SGaist · 1 Nov 2017, 20:54

Great !

Glad you found out and thanks for sharing !

The solution you have seems pretty simple, would you consider a contribution to Qt implementing it ?

BradWalker · S SGaist 1 Nov 2017, 20:14

@SGaist

would you consider a contribution to Qt implementing it ?

Absolutely.. But, I'm unsure what process to follow. If you could tell me, then I would be happy to do that.

SGaist · wrote on 1 Nov 2017, 21:47

You can find the gerrit introduction here. Don't be afraid by the length of the page, it really goes into the details of the submission process.

Saulo Alessandre · wrote on 4 Dec 2018, 15:10

@BradWalker Recently I had the same problem in 5.11.2 version, and to keep record to anyone, the problem in case was that Qt does not implement suport to 8 bpp framebuffer. You can see this on qlinuxfbscreen.cpp:dtermineFormat function.

switch (depth) {
case 32: {
code...
break;
}
case 24: {
code...
break;
}
...
case 16: {
code...
break;
}
...
case 8: {
// A Qt Warning would be very wellcome here
break;
}
}

I think they should put a warning there. I lost many hours thinking it was a configuration problem.

regards,