Have you succesfully run any example that properly displays some sliders/toggle buttons with that style and Colibri imx7d ?
Even our simpler apps fail to display them / get them to work properly (touch animation has bad coordinates, sliders aren’t completely rendered, buttons don’t show up)…
And yet everything runs fine on desktop !
Any general ideas / hints on what we could have possibly missed ?
We are using buildroot 2020.02.7 and added all associated packages :
Thanks for the help, we use linuxfb.
Using the command
./IHM -platform wayland
to force it to wayland fails. We get the following availables platforms : linuxfb, minimal, offscreen, vnc
I thought wayland required an opengl capabled backend (which we don’t have with imx7d).
If anyone could get a small example with Material style native buttons working it would prove us we are doing something wrong and that it’s not a 2D renderer / platform limitation.
For now our workaround is to make our own qml button components (adding text and mouse areas with onclick handlers, but we wanted to use the native ones to avoid this work in the first place…
Unfortunately, this is improbable, as Toradex does not develop Qt applications. You might have more luck going to Qt’s forum to get an example application. On the other hand, if you share some really small source code that reproduces your issue, we might try that on our side.
From the QtQuick 2 limitations you’ve shared, it is not clear to me that a simple, basic application would fail…
Thank you for your answer, here’s a small test code that I ran on my desktop (and worked fine) and then cross-compiled for our Colibri IMX7D.
Upon executing it on our platform, switches don’t show up properly (moving disk isn’t displayed) and upon pressing any button the animation is displayed with the wrong coordinates (always 0,0 visibly)…
I could test the code you shared. I must say I didn’t dig down to try to solve it. I simply tried to reproduce the behavior
I can say I saw the same with QT_QUICK_BACKEND=software. Without setting QT_QUICK_BACKEND (therefore using its default value), seems like everything is rendered accordingly, but the application is slow.
Here are some videos. I used:
Colibri iMX7D 1Gb eMMC V1.1A
Carrier Board Aster V1.1B
TorizonCore 6.2.0 (based on Toradex’s BSP 6.2)
Current Torizon Containers (Debian Bookworm)
Qt 6
To compile/deploy I am using VSCode extension for Torizon (nickname ApolloX)
Your application with Material and QT_QUICK_BACKEND set as software:
Your application with Material disabled (I changed directly your source code - .qml and .cpp files - and recompiled) and QT_QUICK_BACKEND set as software:
As we can see, setting QT_QUICK_BACKEND to software and not using Material (last video) makes everything work. Seems like there is indeed some issue related to the Material stuff…
I think that it makes sense for you to ask Qt directly about what might be missing to make Material work…
In the meantime, I will also ask internally if someone has any tips regarding this.
PS: Your example printed this everytime I launched this on Colibri iMX7:
Hi @henrique.tx, thank you very much for all the efforts and the videos you provided to help, we really appreciate !
We can’t quite figure out why QT_QUICK_BACKEND set to default works fine in your second demo and is really (really) slow in the first one…
We’ll try to switch to RHI for testing on our platform but I’d say we need to upgrade our Qt version to 5.14 first according to the documentation you linked before !
I had a chat with our Qt-Expert and I am relaying and summarizing his comment about this one here.
So according to him the issue could be the flag clip:true. If this is enabled for certain elements in can lead to issues with the SW renderer. Maybe this is the issue for the material design. If you use the RHI as renderer then OpenGL will be used.
On the iMX7 this is the SW implementation of OpenGL. Meaning it will work but it will be slow.
There’s an option clip: visible that is enabled. Disabling this is apparently not so trivial. It might be needed that you create your own Material Design based on the original.
Overall it might be worth to bring this up to Qt support. To get more details.
Thank you for investigating even further !
We’ve discussed in our team about the way to go (our project has already been delayed a lot with these tests).
Copying the Material Design could be a good idea but we’re afraid of having to eventually debug every component we use (without your insight we could’ve spent a lot of time - only for the slider - to understand “clip” property should be set to false !)
Other solutions we mentionned were to switch to imx8 colibri - which was refused for obvious cost reasons (and switching from nandflash to eMMC) - or to simply abandon QML, implying to redevelop our interface from scratch…
All in all, we decided to keep on creating simple custom components and avoid the use of styles for now, that’s the simplest solution to keep our schedule ! Maybe we’ll give another try to Materials later, when we have more time for trial and error !
Thank you very much to both of you for all the efforts you provided in this topic, have a great day !
Best Regards,
Nicolas
):