0

I'm trying to create a very simple wayland compositor using the examples found here, like this:

import QtQuick 2.12
import QtQuick.Window 2.2
import QtWayland.Compositor 1.3

WaylandCompositor {
    id: wlcompositor
    WaylandOutput {
        compositor: wlcompositor
        window: Window {
            width: 800
            height: 480
            visible: true
            title: wlcompositor.socketName
            Grid {
                anchors.fill: parent
                anchors.margins: 100
                columns: 2
                Repeater {
                    model: shellSurfaces
                    ShellSurfaceItem {
                        id: shellSurfaceItem
                        autoCreatePopupItems: true
                        shellSurface: modelData
                        onSurfaceDestroyed: shellSurfaces.remove(index)
                    }
                }
            }
        }
    }
    ListModel { id: shellSurfaces }

    XdgShell {
        onToplevelCreated: shellSurfaces.append({shellSurface: xdgSurface})
    }
}

And then I'm creating a separate client app that just creates a couple Rectangles as a test.

import QtQuick 2.12
import QtQuick.Window 2.12

Window
{
    id: window
    visible: true
    width: 200
    height: 200

    Rectangle
    {
        anchors.fill: parent
        color: "green"

        Rectangle
        {
            x: 10
            y: 10
            width: 100
            height: 100
            color: "blue"
        }
    }
}

Everything seems simple and straightforward. But when I run it on my Pi4 (using the -platform wayland flags), the client gets crazy distortion, like this: Screenshot

I'm testing it with Boot2Qt, which is a yocto linux image. I've tried Qt versions 5.14.2 and the newest 5.15.0 with the same results. There are no errors on the console. Nothing that indicates anything is wrong except that it looks awful.

I did notice that if I use weston as my compositor instead of QtWayland, then the app looks perfect. So that makes me think there's something wrong with WaylandCompositor. But my search of google found nobody else complaining of the same thing.

I don't even know what to try. Does anybody have any ideas?

JarMan
  • 7,589
  • 1
  • 10
  • 25
  • I must be the only person trying to use QtWayland on the pi4. I submitted a bug report [here](https://bugreports.qt.io/browse/QTBUG-84614) but they marked it as only "somewhat important", so it probably won't get fixed anytime soon. – JarMan Jun 08 '20 at 15:22
  • 1
    I noticed a very similar problem on a ARM i.MX 7 device, interestingly using the same resolution. Wayland compositor used OpenGL/Mesa to create a buffer, and it turned out that Mesa uses a stride aligned to 64 pixels. This does not align with 800 pixels. The kernel space driver wasn't able to handle a stride != width, and also did not reject that configuration. After fixing the driver, I wasn't able to run the compositor using OpenGL backend anymore. See also: https://gitlab.freedesktop.org/mesa/mesa/-/issues/2677. Can you reproduce the issue with 640x480? – falstaff Jun 21 '20 at 21:41
  • Thanks for the link on the Mesa issue. I assumed it was a Qt issue since it works correctly when I use Weston. But maybe Weston is just falling back to a software renderer. I'll try out a different resolution and get back to you. – JarMan Jun 22 '20 at 20:41
  • @falstaff Unfortunately, changing my resolution did not work. The 800x480 comes from the native resolution of the 7" PI touch screen. But I used the HDMI port to output to a 1920x1080 monitor (which is divisible by 64) and the output was the same. I do agree that it looks like an alignment issue, but I don't know what to do about it. – JarMan Jun 22 '20 at 22:26
  • you should be able to tell from the output if Weston falls back to software rendering. But yeah, this looks different than what I observed, and probably has a different culprit. – falstaff Jun 23 '20 at 11:42
  • Another voice. I've been seeing this too (I was using a slightly older version of the examples with Qt 5.11 and import QtWayland.Compositor 1.1 which comes with current Raspian - shame it's not fixed in 5.15) I too assume an alignment or buffer size mismatch as I can see the client animation happening but it's just striped. I've not gotten round to rebuilding Qt and tracing it yet :/ – lbt Jan 10 '21 at 14:01

3 Answers3

2

I had similar effects using qt 5.15.1 and qt 5.15.2 with qt wayland on the pi 4. I managed to get QT Wayland working with no distortion by compiling the mesa driver 20.3.3 and 20.3.4, using the following options:
-Dplatforms=x11,wayland -Dvulkan-drivers=broadcom -Ddri-drivers= -Dgallium-drivers=kmsro,v3d,vc4 -Dbuildtype=release -Dprefix=/usr -Degl=true

After installing the drivers i updated the sysroot on my host and cross-compiled the QT Lib. That made it finally working. Good luck.

jns
  • 21
  • 2
  • Hey, thanks for that tip! Did you add those options to a yocto recipe? Or are you building things differently? – JarMan Feb 23 '21 at 21:08
  • I use the default Raspberry Pi OS Lite on the Pi4. I have no experience regarding the yocto project yet, but plan to try it in the future. The mesa drivers were compiled on the pi 4, the qt lib cross compiled on an ubuntu host using GCC 8.3.0 toolchain. – jns Feb 24 '21 at 08:32
  • Ok, by default the yocto build I'm using tries to include version 19.1.6 of mesa. I'm trying to upgrade to 20.3.4, but it's requiring upgrades of other packages too, so it's not going to be a simple task, but I'll keep trying. – JarMan Feb 24 '21 at 14:37
1

I've encountered this very same issue from Qt 5.12 to 5.15, and Qt 6.2.0 RC.

The solution to avoid distortion is to enable dma-buf in QtWayland, and set hardware integration from the compositor side:

export QT_WAYLAND_CLIENT_BUFFER_INTEGRATION=linux-dmabuf-unstable-v1
export QT_WAYLAND_SERVER_BUFFER_INTEGRATION=dmabuf-server 

Note that in order to enable dma-buf it required me to tweak .pro and configure.json files (I'm doing native build on the Pi4), as the libdrm-dev header couldn't be detected by qmake or cmake correctly.

Add INCLUDEPATH += /usr/include/libdrm/ to the following two:

./src/plugins/hardwareintegration/client/dmabuf-server/dmabuf-server.pro
./src/plugins/hardwareintegration/compositor/dmabuf-server/dmabuf-server.pro

And add libdrm/ before drm headers in following files:

./src/client/configure.json
./src/compositor/configure.json

A re-configure & rebuild should work. Tested on Pi4 + Qt 5.15.2 with both armhf and arm64 image, using dtoverlay=vc4-kms-v3d-pi4 overlay.

penk
  • 43
  • 6
  • 1
    Thanks! It's been forever since I've looked at this, but I never did solve it. So I will give your suggestion a try! – JarMan Sep 22 '21 at 15:47
0

If memory serves me correctly, the closed-source graphics driver are a real pain when it comes to wayland support. You may have some luck by enabling the broadcom backend (which I think it's what appropriate for rpis) for qt wayland by setting QT_WAYLAND_CLIENT_BUFFER_INTEGRATION=brcm before starting the compositor.

There is some info about this env var in this readme: https://code.qt.io/cgit/qt/qtwayland.git/tree/README

But if practically possible, I would think the mesa open-source drivers will give you a lot less pain, as it's much more widely used and support is likely much better.

bobbaluba
  • 3,584
  • 2
  • 31
  • 45