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

[Andrea Venturi]

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

[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-project.org> On Behalf Of Andrea Venturi
Sent: fredag 9. mars 2018 13.00
To: ***@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

[Andrea Venturi]

thanx Laszlo for the fast reply.

Weston indeed is working pretty well, but two issues:
* is "wasting" a 10% of CPU power and
* we are finding some issue on the Qt setting the right display
"programmatically".

for example this invocation of the example app *hellowindow* was displaying
TWO rotating trolltech logos in the same head.

*/usr/lib/qt/examples/opengl/hellowindow/hellowindow --multiscreen
-platform wayland*

on a dual head desktop PC instead, the windows are shown on different
screens. using the mouse can bring smoothly the rendered windows from a
screen to the other and back.. puzzling!

that's why we were trying to test the "lighter" EGLFS approach.

i appreciate a lot your confirm about ELGFS_KMS being the right "device
integration" for accessing the rendering pipeline with DRM/KMS (the MALI
keyword on eglfs_mali is going to mislead a lot people..). we'll check more
hardly this path now.

on the other hand, the RK3288 is a little different beast, as AFAICS it has
a Midgard core instead of Utgard (MP4xx), but maybe it could be a worthy
experience testing it too, i have a Radxa Rock2 lying around, indeed..

let you know, anyway..

[Andrea Venturi]

hello,

i've been finally able to make the platform EGLFS render on both screens
and the "hellowindow --multiscreen" example shows me nicely the two
trolltech logs spinning each on its display. so far so good.

now my setup is 2 screens: one internal LCD 800x480 and one external
fullHD 1920x1080 on ext HDMI.

kmstest shows me the two test cards, correctly.

/ # kmstest
Connector 0/@32: Unknown-1
  Crtc 0/@30 (plane 0/@28): 800x480 29.500 800/24/72/96 480/3/10/7 60
(59.48) 0xa 0x48
    Fb 44 800x480-XR24
Connector 1/@37: HDMI-A-1
  Crtc 1/@35 (plane 2/@33): 1920x1080 148.500 1920/88/44/148
1080/4/5/36 60 (60.00) 0x5 0x48
    Fb 45 1920x1080-XR24
press enter to exit

now, when i test my own sample code, i loop for screenIdx 0&1 into this fn:

bool Manager::StartOnScreen(int screenIdx){
 _desktopWidget = QApplication::desktop();
    QScreen * qScreen = QGuiApplication::screens().at(screenIdx);

    QWidget* screen = _desktopWidget->screen(screenIdx);
    QWidget* bgWidget = new QWidget(screen);

    bgWidget->show();

    QFrame* smallFrame = new QFrame(bgWidget);

    //Set frame color
    if(screenIdx == 0)
        bgWidget->setStyleSheet("background-color:rgb(0, 0, 254);");
    else
        bgWidget->setStyleSheet("background-color:rgb(254, 0, 0);");

    smallFrame->setStyleSheet("background-color:rgb(0, 254, 0);");

    //Show the frame (windowed)
    smallFrame->show();

    smallFrame->resize(100,100);
    smallFrame->move(100,100);

    return true;
}


then, i get this wrong render on the full HD display only:
https://drive.google.com/open?id=1vFuJEz1HgiUO6Ariz53ih-yNgXwDUe-3

we can see on the left the "viewport" supposed to land on the internal
LCD, on the right the widget for the HD screen with an offset of 800px
(and cropped on the right border..)

i tried also with setting a simple *QT_QPA_EGLFS_KMS_CONFIG*:

/ # cat /root/egl_kms.json
{
"device": "/dev/dri/card0",
"hwcursor": false,
"pbuffers": true,
"outputs": [
{
"name": "None1",
"mode": "800x480"
},
{
"name": "HDMI1",
"mode": "1920x1080"
}
]
}

but not visible change at all. same view as above on the HDMI display
and the LCD black.

the crazy thing is that if i just run the loop only for screenIndex 0, i
see the widget on the LCD! at full frame 800x480

BTW i found very few info about EGLFS multihead..  mainly google returns
me this post from Laszlo and indeed his sample code IS working! thanx
Laszlo!

http://blog.qt.io/blog/2016/09/19/qt-graphics-with-multiple-displays-on-embedded-linux/

is this behaviour triggering ideas on anyone ? can you spot bugs or
errors on the simple procedure for setting up the objects?

BTW my scope is a single app driving both displays, so i like this EGLFS
stuff because it's light and i do not need a compositor..

thanx

andrea

Post by 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
*On Behalf Of *Andrea Venturi
*Sent:* fredag 9. mars 2018 13.00
*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
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..).
* 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

[Andrea Venturi]

hello,

i put together a small code snippet for QtCreator, to better showcase
the issue i see in my dual-head setup with a Qt widget app running
through EGLFS on a libMali.so/DRM/KMS setup on Allwinner A20 mainline
based OS:

 https://github.com/aventuri/widgetMultiScreen

the outcome is the wrong display of the two (yellow and red) rectangles
with the code above only on the ext HDMI diplay. see:

https://drive.google.com/open?id=1tGJxoBzBNn_wEhCi5mnI5a5zLSKIrAwX

the puzzling issue is that if i comment out the w2.show() line:

https://github.com/aventuri/widgetMultiScreen/blob/master/main.cpp#L3

i can see (correctly) a single yellow screen on the primary LCD display.

can someone point me toward better debugging? is a GDB step by step
approach the best one?  the Qt stack is that huge..

Post by 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

[Laszlo Agocs]

Hi,

No immediate ideas unfortunately, but it could well be that widgets (raster windows) do not behave as well in this regard as pure OpenGL windows (Qt Quick and friends). The multi-head work in the past was focused on the latter.

Please create a bug report at https://bugreports.qt.io

Best regards,
Laszlo

From: Interest <interest-bounces+laszlo.agocs=***@qt-project.org> On Behalf Of Andrea Venturi
Sent: mandag 19. mars 2018 12.32
To: ***@qt-project.org
Subject: Re: [Interest] issues with Qt 5.9.3 with eglfs QPA_Platform on DRM/KMS kernel on Arm32/Mali HW


hello,

i put together a small code snippet for QtCreator, to better showcase the issue i see in my dual-head setup with a Qt widget app running through EGLFS on a libMali.so/DRM/KMS setup on Allwinner A20 mainline based OS:

https://github.com/aventuri/widgetMultiScreen

the outcome is the wrong display of the two (yellow and red) rectangles with the code above only on the ext HDMI diplay. see:

https://drive.google.com/open?id=1tGJxoBzBNn_wEhCi5mnI5a5zLSKIrAwX

the puzzling issue is that if i comment out the w2.show() line:

https://github.com/aventuri/widgetMultiScreen/blob/master/main.cpp#L3

i can see (correctly) a single yellow screen on the primary LCD display.

can someone point me toward better debugging? is a GDB step by step approach the best one? the Qt stack is that huge..


On 03/09/2018 02:42 PM, Laszlo Agocs wrote:

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

[Andrea Venturi]

hi Laszlo,

thanx for the prompt reply, here the bug filed:

 https://bugreports.qt.io/browse/QTBUG-67160

i'll continue my investigation too, let's hope to sort out something.

i'm wondering if there's a reason why the "widgets" are less used in
multi-screen setups. i supposed they were "first class citizens" of the
Qt Stack.

BTW if the issue is that they are typically "sw rendered"  only, that
could be a problem for me too, because i was trying to "leverage" the
OpenGL ES HW core in the A20 SOC to reduce CPU usage in a high refresh
rate app! :-|

anyway in my first tests with Wayland&Weston the same app was seeing a
huge relief (in terms of CPU load) then running as "Mesa3d" sw rendering
on the Linux simplefb. that's why i was hopefull!

Post by Laszlo Agocs
Hi,
No immediate ideas unfortunately, but it could well be that widgets
(raster windows) do not behave as well in this regard as pure OpenGL
windows (Qt Quick and friends). The multi-head work in the past was
focused on the latter.
Please create a bug report at https://bugreports.qt.io
Best regards,
Laszlo
*On Behalf Of *Andrea Venturi
*Sent:* mandag 19. mars 2018 12.32
*Subject:* Re: [Interest] issues with Qt 5.9.3 with eglfs QPA_Platform
on DRM/KMS kernel on Arm32/Mali HW
hello,
i put together a small code snippet for QtCreator, to better showcase
the issue i see in my dual-head setup with a Qt widget app running
through EGLFS on a libMali.so/DRM/KMS setup on Allwinner A20 mainline
https://github.com/aventuri/widgetMultiScreen
the outcome is the wrong display of the two (yellow and red)
https://drive.google.com/open?id=1tGJxoBzBNn_wEhCi5mnI5a5zLSKIrAwX
https://github.com/aventuri/widgetMultiScreen/blob/master/main.cpp#L3
i can see (correctly) a single yellow screen on the primary LCD display.
can someone point me toward better debugging? is a GDB step by step
approach the best one?  the Qt stack is that huge..
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