Cannot get QML with QtQuickControls2 and Google Material Style to work on Colibri imx7d

Hi there,

Upon conceiving our new HMI (we already made a full functionnal QML HMI) we wanted to go with qtquickcontrols2 to benefit from the material style. (Material Style | Qt Quick Controls 5.15.14)
Although we were aware of some “limitations” due to the lack of GPU on our SOM (Limitations | Qt Quick 2D Renderer 5.7)

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 :


Our configuration :
[Colibri iMX7D 512MB V1.1D]
Custom Carrier Board
UBoot : 2016.11-toradex
Kernel : toradex_4.9-1.0.x-imx
buildroot 2020.02.7

Any help would be greatly appreciated !

Best Regards,


Hi @nicolas.b !

What is the content of your QT_QPA_PLATFORM variable?

Also, which QT_QPA_PLATFORM are available on your platform?

If you are using Wayland, you could try to set QT_QPA_PLATFORM to wayland, for example.

Best regards,

Hi @henrique.tx !

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…

Best regards,

Hi @nicolas.b !

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…

Best regards,

Hi @henrique.tx !

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)…

Best Regards, (3.8 MB)

Hi @nicolas.b !

Please allow us some time to be able to test it.

Once we can test it, I will get back to you, ok?

Best regards,

1 Like

Hi @henrique.tx !

Were you able to setup a testing environment ?

Best Regards,

Hi @nicolas.b !

Sorry for the delay.

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 default QT_QUICK_BACKEND (according to Scene Graph Adaptations | Qt Quick 6.6.1, it must be rhi - whatever it means :man_shrugging:):

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:

qrc:/ QML IconImage: Error decoding: qrc:/QML/assets/drawer_close.svg: Unsupported image format
qrc:/ QML IconImage: Cannot open: qrc:/QML/QML/assets/list.svg

I changed some organization, so the path is not the same as you use, but the Unsupported image format bit is something unexpected.

Best regards,

Hi again! :slight_smile:

I would like to share the outcome of two more tests I did.

I created a demo pretty much based on

  • Qt/QML/C++ template from Torizon’s extension (the animation part), and
  • Qt’s Material documentation: Material Style | Qt Quick Controls 6.5.1, and
  • Your application with the Page Horizontal Swipe.

This one is executed without setting QT_QUICK_BACKEND (therefore, I assume it is rhi):

This one is executed with QT_QUICK_BACKEND=software:

From the videos, we can see that the Switch control keeps being rendered wrongly.

Here is the project, if you are interested.

simple-material-torizon-test.tar (50 KB)

Best regards,

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 !

Best regards,


Hi @nicolas.b ,

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.

He suspects the problem child to be here:

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.

Hope this helps already a bit.

Best Regards

Hi @kevin.tx ,

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,

1 Like

Hi @nicolas.b,

Sorry for my late reaction.

Thanks for the overview.

Please let us know if and when Toradex can help you on your way.

We’re here to help you on that journey.

Best Regards