But the QML portion is not displayed when I run it with the default wayland platform:
I think the combination of QQuickview and QWidget::createWindowContainer() is a very basic implementation for adding qml elements into Qt Widgets application. But this is not running with the default wayland platform. Is there any work around to solve this issue?
I further tested Qt QML integration and observed the following:
The alternative to the combination of QQuickView and QWidget::createWindowContainer() is - QQuickWidget
QQuickWidget *wid = new QQuickWidget();
I tested the same code replacing QQuickview portion with the above QQuickWidget portion in mainwindow.cpp.
This time, the program is running in wayland platform also. But there is heavy flickering(no flickering with xcb platform), whenever there is a movement in the qml portion. When the animation or movement is stopped there is no flickering.
In both of these cases, the application is working finely in my Ubuntu Laptop.
So I doubt some issues with my image/sdk build. My Qtbase config summary is attached for reference.
~/oe-core-IMX8/build/tmp/work/x86_64-nativesdk-tdxsdk-linux/nativesdk-qtbase/5.14.2+gitAUTOINC+3a6d8df521-r0/build/config.summary is attached. config.summary_qtbase (6.1 KB)
How can I ensure that a basic qml/qt quick application with some animation(movement) is working in Colibri IMX8QXP+Iris 2.0 platform without any flickering.
Can anybody suggest some proven example applications.
That’s an image from a lengthy blog post I wrote here.
The application drunk drives across all three lanes and has random crashes due to garbage collection running in three different lanes at three different uncontrollable times.
That’s not your problem, but it kinda is.
You make the claim that the “default” environment is Wayland/Weston. - - - Not exactly true.
There is a Wayland/Weston compositor in the default TorizonCore. It has some X11 client capabilities. It’s the some that’s killing you.
Remember the three lanes and drunk driving from earlier? Well, they all determine which backend to use. When you pass -platform on the command line you force all 3 of them to use the same backend. When left to their own decision tree they don’t all arrive at the same place.
If memory serves it searches from the oldest/lowest forward. Depending on how your stuff was built one lane may find and love XCB. Another might find and prefer EGL.
The EGL support is far from complete in Wayland/Weston.
I strongly recommend you never consider Qt for anything going forward. The bug database is north of 5,000 and many of them are old enough to get a driver’s license in America. Qt 6 is piling bugs on by the train load.
Both produce light clean UIs. Both have to be built and run in a pure Bullseye Docker Container.
You can make almost anything that uses pure X11 work inside of a Bullseye Docker Container. What you can’t do, at least I never could, is get the mouse. Touch input is just fine, but the mouse cannot be seen.
From inside a container you also cannot control screen position. If you are writing a full screen touch-screen app this isn’t an issue.
You can follow some of this discussion with these two threads on here.
Assuming you are determined to stick with Qt despite it being a really broken platform right now, you need to actually read this:
Don’t just glance at it, actually read it. You are assuming the plugin you need to use actually got built. That’s not a safe assumption. You are probably going to have to do your own Yocto build unless you can find a way to wedge a custom Qt from source build into TorizonCore Builder.
This plugin system that Qt has is a massive Achilles Heel. Just because something runs fine on your Ubuntu laptop doesn’t mean anything. That environment builds the XCB plugin by default. God only knows what got built with the default TorizonCore build. Apparently the XCB plugin did because when you force XCB with -platform your application “kinda works.”
I suspect at least part of your application is trying to use EGL on target and that ain’t going to work. I couldn’t make it work for either NanoGUI or Elements and those are comparatively simple libraries.
Once you are done reading the first Qt plugin link, you can read the Wayland specific one.
If you don’t read the other one first, this one isn’t going to help you.
If you want a great big has everything UI library, last I checked, the TorizonCore repos included wxWidgets. It supports Wayland. You can use CodeBlocks for the IDE unless there is a wxWidgets plugin for VSCode.
Getting something to run “native” on the default TorizonCore with Wayland/Weston running is a real PITA. Not something anyone should attempt on their first try if they aren’t used to embedded systems work.
This is why they push Docker Containers as the main development method. As long as you don’t need the mouse, you can make most things work in a Docker container.
Here is a wee bit more Qt Wayland documentation for you.
Wayland also introduces an awful lot of bugs/problems.
If you are using touch and don’t mind using containers, you can make very professional looking applications using Elements. You can make good simple applications with NanoGUI. You can make massive applications with wxWidgets.
Just don’t make the mistake of believing that because you can get something simple using Qt/QML up and running on Ubuntu it ought to be a cake walk on an embedded target. That’s not going to be true. Ubuntu still using X11 so everything “just works.” Very little actually “just works” with Wayland/Weston.
Thank You very much for providing a comprehensive guidance on the topic. Now, I remember Yocto/oe build was not the main development method, suggested by Toradex for Colibri IMX8QXP. It was Torizon+Docker Container.
I was choosing Yocto/oe build, since I used it for developing applications for Colibri IMX7D. And I thought that I can reuse some of the code.
So I need to think about shifting to Torizon+Docker Container method. Hope I would get further guidance on request from this community.
Thanks for the guidance,