Solved Problems getting Qt running on embedded device..
-
@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; }
-
Are you using the LinuxFB backend ?
-
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.
-
Are you sure the LinuxFB plugin is loaded when you start your application ?
-
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 ...
-
Did you try to set the size of the screen just in case ?
The options are described here.
-
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
-
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 ?
-
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.
-
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.
-
@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,