QT5 + /dev/fb0: redraw problems & mouse and keyboard input not working


Currently i am playing with an QT5 application compiled for balena (rpi3) and running in an balena application container (mounted /dev/fb0, capa: SYS_RAWIO) that shall output on the framebuffer device /dev/fb0. I am trying this approach to avoid using a X server.

What is working right now within the container:
Starting my application like this and it occurs on the screen.

/usr/local/bin/app -platform linuxfb:fb=/dev/fb0

Howewrver i am confronted with some obstacles here:

  1. Any redraw on the framebuffer that comes from balena overwrites my screen
  2. I have no control over the program. If i run the application on my dev host, i get a mouse and keyboard input.

So my questions are:

  1. How do i prevent balena from outputting anything to /dev/fb0
  2. How do i get the mouse and keyboard working?


It’s possibly UDEV related. Run the application as a single-container app (no docker-compose) or, in multicontainer (with docker-compose) with it privileged AND host network mode. If you’re using one of our balenalib base images (which we would suggest) then also add ENV UDEV=1 to your Dockerfile.

Regarding the redraw, what exactly are you experiencing being redrawn?

Trying privileged, host network and UDEV=1 right now.

For your other question regarding redraws:
Before my application starts i see the balena boot logo on the display.
If any logs seem to happen they appear on the screen overwriting what has been drawn before. That’s how the framebuffer works. When my application is running and those logs come in, they overdraw some parts of my application as well.
My goal is that balena does not log anything to tty0 (where fb0 is connected to). I might need to fiddle with the config.txt or cmdline.txt in /mnt/boot to adapt some kernel parameters.
Is there any known best practice to do so - hopefully without manually fiddling with the host balena OS?

FYI: working with privileged, host network and UDEV=1 works. Now i need to find out what caused it to work to restrict privileges again. Thanks for the tip.
The other question regarding logging on tty0 on /dev/fb0 (see above) is still open.

UDEV signallying requires the host network, and privileged exposes the entire /dev tree to the container.

If you wish to prevnt the FB overwrite, then running a production image would have this effect since we do not log to the console in these variants :+1: