[Interest] issues with Qt 5.9.3 with eglfs QPA_Platform on DRM/KMS kernel on Arm32/Mali HW

[Laszlo Agocs]

Hi,

eglfs_mali is for Mali userspace drivers (https://developer.arm.com/products/software/mali-drivers/user-space) marked as fbdev. This is from the time when there were only two options, fbdev and x11.

When having the wayland variants in place, use eglfs_kms instead. When in doubt, try running weston first. If it comes up correctly, eglfs_kms is the right choice. This has been tested with an Asus Tinkerboard (Rockchip RK3288) a while ago. I don’t have experience with other Mali-based boards.

We do have multi-screen support with DRM, yes. The fbdev and other backends have none or very limited capabilities in this regard. The way forward is to use eglfs_kms (or eglfs_kms_egldevice when on NVIDIA) whenever possible.

Best regards,
Laszlo

From: Interest <interest-bounces+laszlo.agocs=qt.io at qt-project.org> On Behalf Of Andrea Venturi
Sent: fredag 9. mars 2018 13.00
To: interest at qt-project.org
Subject: [Interest] issues with Qt 5.9.3 with eglfs QPA_Platform on DRM/KMS kernel on Arm32/Mali HW

hello guys,

the subject says a lot.. :-) let me extend a bit in the body, anyway!
i'm working on a buildroot based OS on top of a Allwinner A20 based EVB (Olimex A20 SOM) with both a LCD and an HDMI interface.
with a fairly latest 4.15 kernel and proper DTS i can see kmstest showing correctly two test cards on both heads/screens. so far so good

now i'd like to use the Mali acceleration for snappy Qt experience (two apps each running full screen on its head..); i know the libMali.so is a bit of a mess and i currently use this binary blobs:

https://github.com/mosajjal/r6p2/tree/master/libwayland_for_mali/h3/lib_wayland
AFAIK it's ARM32 release for "allwinner gears". and it currently someway works on wayland but it's bit too heavy for my workload.
i'm wondering if that trunk is good also for "lighter" gbm-only approach (wayland free.. i mean)

i'm trying to make Qt5 use the eglfs backend, because i suppose the less the code, the less the bugs.. :-)
but i fail to understand if i have to use elgfs_mali or eglfs_kms device integration, because the first one failt on "createdisplay()" with a segfault inside the libMali.so binary blob.

i'm wondering if this issue is related to the fact that the Mali integration in qt5 eglfs is supposed to use /dev/fb0 for video mode setting, but the dual head DRM/KMS setup is not offering a complete dual-head fbdev emulation (and never will AFAICS from the linux-sunxi community..).
so my question is, finally, is the eglfs_kms supposed to be able to:
* drive correctly the dual-head DRM/KMS setup
* still use the libGLESV2 accelerated path provided by libMali.so
if the latter is true, i'm wondering what's the purpose of eglfs_mali "device integration".. is that a leftover of times where only /dev/fbX mode setting was supported?
what's the long term more healthy path to support acceleration and dual/multiple heads on linux mainline?
really let me know if there are reference updated documentation with clear information of the different implementation and their use cases, because my google-fu is failing on me and i find a lot of discussions dealing with Mali (on many different SOCs) with very few technical details and insights (that's why this post is pretty long.. feel free to ask for more info if i'm missing something usefull).
bests
andrea
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20180309/8c10eed6/attachment.html>