I have a Qt program which runs fine in Qtcreator, and they are fine when I built it with “build debug amd64”. After I created production image for arm64, I have to scp the image to my Verdin IMX8M with Mallow Board (company blocks the internet for our development boards). When I ran the container, I got following: (docker run -it image_name bash, then run the executable)
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin “xcb” in “” even though it was found.
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.
I am still reading previous posts on this issue, but so far they were not working for me. Please let me know if you saw or knew the solutions.
Could you describe how you’re executing your software here?
In addition to your application container I assume there is a Weston container of some kind running in parallel yes?
When you execute your application in your container are you executing it as the root or torizon user? By default xcb will have issues if you try to execute as the root user as described here: TorizonOS 6.5 Running a Qt app linked xcb under wayland
Thanks jeremias.tx. Yes I started with a weston-vivante:3
my image list: portainer/portainer-ce:2.17.1, torizon/chromium:2, and torizon/weston-vivate:3
my qt contain generate an executable “torizontest”.
root@5e7c1698efb9:/# su torizon
$ /home/torizon/app/torizontest
qt.qpa.xcb: could not connect to display
qt.qpa.plugin: Could not load the Qt platform plugin “xcb” in “” even though it was found.
My Qtcreator program originally was a wayland application. so I am guessing maybe I missed either wayland or xcb plugin in my dockerfile.
Take note of the various arguments that the wayland container gets executed with. These give the container various access and permissions needed to use the graphical stack of the system in the container. Most importantly is the bind-mount -v /tmp:/tmp. If you launched the Weston container as we document, then it creates a socket file in /tmp. You then need to give access to /tmp for your application container so that it can access the socket file and subsequently communicate with the Weston/Wayland process running in the other container.
Try to run your containers as we document in the article I linked.
It turned out this was a network issue. I retried the project at home, there was no problem.
Thanks for help.
Oh interesting, well glad you were able to resolve this. Was it a case of your office network being too restrictive with firewalls/network restrictions, something like that?
