Docker image with X11 instead of Wayland or how to use QT5 with linuxfb


Is there an Docker image available which provides an xserver instead of wayland? Because I have a simple kiosk mode browser written with QT5 to render some HTML gui on the Colibri module. I know there is a docker image with chromium as kiosk mode browser but chromium is always crashing when I try to start the image.
And with the existing wayland/weston container, I have problems to display my browser because QT5Webengine is printing some warnings that it is not ready for wayland. Nevertheless the window is shown but has some graphical defects.

So, I think having X11 instead of wayland running, could solve that problem.

Another way could be to have my QT browser running without any X11 or wayland compositor and draw directly to the framebuffer with linuxfb.

I tried this but the color depth of the framebuffer was not good enough (maybe it is configured for some LCD display?!). I would like to have only HDMI output. But I think this has to be configured with some DTBOs, right? Is there some documentation about this?

And I also needed to configure the exact input device to get the mouse running. And I fear if I plugin in another mouse or use another USB port, the input device will change and the mouse wouldn’t be working anymore.


Greetings @aauer1

Let me touch on the two points you brought up here. First of all LinuxFB backend for Qt is possible on Torizon but it’s not perfect in a Debian based container. This is because currently Debian packages don’t provide the proper support necessary for this. We have had discussions and talks internally of creating custom packages to add this support to our Debian containers, but this is still in discussion and is not currently planned. Alternatively you could take a boot2qt rootfs and import that as a container, with a boot2qt environment a LinuxFB backend should be possible. However this process isn’t very well tested and may have unforeseen issues later down the road.

This brings us to the next point of an X11 container, so currently as far as I know this is the only X11 container we still have:


Though ultimately depending on your use case it might be best to create your own container with the X11 backend and packages you require.

As for the framebuffer/display settings and such they should be read from whatever is set in the device tree. If you wish to use HDMI on the colibri platform please see the answer in this post:

As for input devices I think I need more details to understand what you configured on your end and what you’re ultimately trying to achieve.

Best Regards,

Hi @aauer1,

Any feedbacks about this issue?

Best regards,
André Curvello

I certainly would love such a container.

I am trying to get several low weight free as in beer UI libraries working on Verdin. Wayland just ain’t what Wayland claims to be. If one follows this doc

and changes the backend to
weston-launch won’t even start. Just plain dies before the slightest screen flicker.

One of the libraries I’m trying is NanoGUI. It’s nice looking in a straight forward simple kind of way. More than enough for many embedded systems.I did some tweaking and got it to build in the container all nice like. Deployed a container with it to the target and tried to run the first example.

Made the mistake of doing an Internet search for an answer. Google is a bad thing.

Not a good rabbit hole to go down.

I know, one is not supposed to revive a year dead conversation, but it’s still relevant.

If Toradex is making a business decision to not have an X11 only container, there should at least be some full example that is easy to find on how to make Wayland actually work with X11. The Wayland doc makes a lot of claims about XWayland but so far I haven’t found a way to make it work.

Admittedly I usually don’t work this close to the metal but this has been like trying to catch smoke in a fishing net.

Note: Forgot to mention last night that if one tries to run it in the Weston terminal it segfaults without displaying anything.

According to this:

X11 isn’t supported on MX8. Is this true?

I would really like to be pointed to an X11 demo that will compile, link, and run on Verdin in full screen mode. Just open an Xwindow full screen, put a prompt and a button on it, make sure the mouse can actually be seen and that would go a long way to helping a lot of people.

X11 works on every other Linux platform. It’s stable, tried, true, and trusted.

Sorry if this sounds whiny, but I’m four weeks into this project and just now finding out X11 may not be supported on the platform.

Qt cannot be used. This is a medical device.

Thank you for all of your efforts.

This is correct, NXP has made the decision to not support X11 with their i.MX8* SoCs. While there may be some hacky solution out there that allow X11 on i.MX8, I can’t really attest the long term viability of any solution given the current support from NXP.

Does i.MX7 still support X11?

I’m just asking. I don’t know if switching the SOM is viable at this point in the project. I doubt this application needs the horsepower of i.MX8, but I’m not a hardware person.

Other than Qt, which is not an option, what actually works for C/C++ development on i.MX8? Something in C/C++ where you can get 100% of the source code for static analysis and FDA vetting. We’ve got more than enough (possibly too much) SOUP (Software Of Unknown Providence) with this module as it is.

Does the wxWidgets stuff in the repo even install under Weston/Wayland? Anything based on OpenGLx or GTK seems to not install.

The older i.MX6/7s historically have had support for X11 based graphics. As for C/C++ based UIs on i.MX8 with Linux, the only thing we at Toradex have tried and tested is Qt. Not to say this is the only option, but it’s the only option we can give a somewhat confident guarantee that it at least works.

Well, I sat through both of these Webinars.

Yocto webinars

If they are current (they do mention imx6) angstrom-LXDE is one of your base images for a yocto build. It’s an X11 desktop. I have to go find the Web page that was referred to but never explicitly shown in the Webinar to get all of the pre-reqs for a yocto build. From there I should be able to see what you have.

I typically don’t do yocto builds, but this is the approach every project has used that I’ve been on. Someone custom builds an embedded OS and U-boot then it is flashed on the device. If angstrom-LXDE is still there and it supports i.MX8, then we should be able to use tried and true X11.

If you could provide the link to the yocto tutorial page which shows all of the prerequisites one needs to install before performing a Toradex Yocto build, that would be swell.

Thank you.

As a note, you (being Toradex) should put a big disclaimer on the i.MX8 EasyInstaller stuff that if you use Torizon and EasyInstaller, X11, GTK3, anything based on “mesa” will not be an option.

Btw, in both of those demos, the little black bordered touchscreen sure looks like a Chalkboard.

Starting with BSP V3.0 we have used:

A Poky-based distribution for our Toradex Reference Images for Yocto Project.
A minimal distribution with OTA capabilities and a container engine for TorizonCore. TorizonCore and the Torizon ecosystem were created to provide a great out-of-the-box experience and an easy migration path for Windows CE users.


Up-to BSP 2.8 we opted to use the Yocto compatible Ångström distribution with an LXDE desktop environment.

You no longer use Angstrom?

Can LXDE be layered onto Poky?

Qt is not an option. The bug database is north of 5000 entries.

You no longer use Angstrom?

As you have noted, we only started supporting the i.MX8 products with our 3.0BSP at the earliest. Therefore the i.MX8 products were never supported on our Angstrom based BSP.

Can LXDE be layered onto Poky?

It “should” be possible but I can’t speak to the amount of effort this would actually take. Basic instructions on building our BSP can be found here: Build a Reference Image with the Yocto Project/OpenEmbedded - Toradex System/Computer on Modules

Thank you for your reply.

I’ve been headed down that path all morning. Will let you know if it works.

Thanks again.



We are using Verdin iMX8M Plus, not the Mini. There are no tags for it at Index of /toradex-bsp-platform.git/refs/tags

LinuxImageV2.8 (the most recent I could find with a Vm.n and nothing after it name (read somewhere on the site to only use those) doesn’t list Verdin.

V2.5 which isn’t listed but was used in this Webinar

Magically pulled down and had the platform listed, just really didn’t have squat for it.

What is the correct LinuxImageVm.n for Verdin i.MX8M Plus?

Btw, there are multiple Python standards listed in the spider web of prerequisite configuration stuff. Currently Toradex has something in the mix that won’t work with anything higher than 2.7.

Our Verdin i.MX8M Plus product only came out just this year. Meaning the earliest Toradex software it was supported on is our 5.X BSP.