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

[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


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
>
> *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/20180314/15cd7108/attachment.html>