Rpi4: balena multicontainer read keyboard input, missing characters


I installed balenaOS on a Raspberry Pi 4.
I’m trying to read data from a QR code reader that acts as keyboard. Dmesg gives me the following info:

[13392.153101] usb 1-1.4: USB disconnect, device number 6
[13429.093031] usb 1-1.4: new full-speed USB device number 7 using xhci_hcd
[13429.198220] usb 1-1.4: New USB device found, idVendor=1eab, idProduct=1303, bcdDevice= 1.00
[13429.198243] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[13429.198261] usb 1-1.4: Product: NLS IOTC PRDs HID KBW
[13429.198277] usb 1-1.4: Manufacturer: Newland Auto-ID
[13429.198292] usb 1-1.4: SerialNumber: FC9C2544
[13429.207139] input: Newland Auto-ID NLS IOTC PRDs HID KBW as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.4/1-1.4:1.0/0003:1EAB:1303.0005/input/input4
[13429.266238] hid-generic 0003:1EAB:1303.0005: input,hidraw0: USB HID v1.00 Keyboard [Newland Auto-ID NLS IOTC PRDs HID KBW] on usb-0000:01:00.0-1.4/input0

Here’s my docker-compose file:

version: '2'
    build: ./rpi.bash
    privileged: true
      io.balena.features.supervisor-api: '1'

    build: ./python-evdev2mqtt
    privileged: true

python-evdev2mqtt is copied from here with input_device set to “/dev/input/event0”. It receives the events from the event device 0.

Here is my docker file:

FROM balenalib/raspberrypi3-node:10.18
COPY ./script.sh ./script.sh

RUN chmod +x ./script.sh
ENTRYPOINT ["bash", "./script.sh"]

Here is script.sh:


while read line
  echo "$line"
done < "${1:-/dev/tty1}"

When I scan some QR codes I sometimes don’t see all the characters in the rpi.bash service while the python-evdev2mqtt does always give me the correct characters.
When I ran this script in a terminal on default raspbian it works flawlessly. Is somebody else reading from /dev/tty1? I would like to treat this device as simple keyboard than rely on an event device to keep it on a very high level.

I scanned this QR code:
https://images-na.ssl-images-amazon.com/images/I/31Umxl57vfL.SY355.png which contains the following content:


However when I scanned this QR codes I got the following output from the two services:
The python-evdev2mqtt service gives the correct events, but rpi.bash gives the wrong output (https//itunes.apple.com/us/app/qr-coe-rader-oentapandgo/id3872461?l=1&t=8).

Is the input too fast, is some other process reading from /dev/tty1, …? I’m kinda out of ideas, any help would be very welcome!

Thanks in advance!


Hello Ben, thanks for the detailed reporting of the issue you are facing. First and foremost while looking at this, does a regular keyboard work in that ‘rpi.bash’ container? If so, can you perform some manual text entry and make sure that all characters are properly rendered / captured? I imagine that typing slowly, and gradually increasing speed, may be a good test to see if there are performance bottlenecks on the device…though the QR scanner will likely be tough to beat in a speed challenge.

A second idea, as you alluded to, is that perhaps if the input is simply too fast for the Pi to capture, is there a way to slow down the QR reader output? Perhaps write its output directly to a file, then read the contents of that file into your program.

Hopefully those suggestions help get you started!

Hi David!

Thanks for the fast response!
I flashed Raspbian Buster with desktop (https://www.raspberrypi.org/downloads/raspbian/) on the device and there it worked perfectly fine. I just ran the script inside the terminal on the host OS, no docker no special things and it works every time.

I also tried this “script.sh” directly on the balena host OS (in balenaCloud SSH terminal) and this is the output:

Connecting to c4182ca26037837b38732f0b8a75723b...
Spawning shell...
    Welcome to balenaOS
root@c4182ca:~# while read line
> do
>   echo "$line"
> done < "${1:-/dev/tty1}"
this is  sloz ;qnuql test
this is a slow manual test

The first few outputs are QR code scans where we miss some characters and the last two lines are manual keyboard inputs (on an azert keyboard, hence the weird content on the first line…).
I don’t know why this doesn’t work properly, maybe the reverse shell is displaying things incorrectly? Could it be that balena or some internal process is reading from tty1 or throttling it?
Do you have other suggestions I can try?

Thanks for your time!


Can you confirm if this is a development image, or a production one? I think I might know the answer here, but it’s a long shot; basically plymouthd is grabbing your keystrokes periodically and it can be resolved by killing the process. If you could try that and report back then it would be good to know if this is causing the issue.

At the moment it’s a production image.
Is plymouthd available only on a production image?
I found plymouthd and I killed it. It doesn’t seem to come back. Is this intended?

Also if killing this service is the solution, how can we disable it permanently? I’m also a bit curious what it does. I found this: https://github.com/balena-os/meta-balena/issues/1403
Is it displaying the splash screen? :slight_smile:

Edit: I tested this and it works perfectly now! How can we disable plymouthd in config?


So it’s on both production and development images, just configured in a slightly different way; and yes, it’s used for the splash screen.

You can kill plymouthd using DBUS if you add the label io.balena.features.dbus to your container, then run the following on service start:

DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket dbus-send --system --dest=org.freedesktop.systemd1 --type=method_call --print-reply /org/freedesktop/systemd1   org.freedesktop.systemd1.Manager.StartUnit string:"plymouth-quit.service" string:"replace"

See here for more info on labels: https://www.balena.io/docs/learn/develop/runtime/

Ok, thanks we’ll need to do some DBUS commands in our container anyhow due to other requirements.
Thanks for the help!

I’m working on something similar, listening for a USB barcode scanner input (HID keyboard device) on a Pi Zero W. Works great on Raspbian but drops a lot of input keystrokes on balena. I’m going to try again tomorrow with plymouthd disabled on the supervisor OS. Is this DBUS method the best option or can I do something with the config text files of the supervisor OS prior to provisioning? Can I kill it over SSH easily as a test?

BTW big picture I’ve concluded that a USB HID keyboard input scanner is too brittle and plan to use one that will send scans via USB serial.


You can kill it easily on the host OS as it’s only a Unix process.
First look up the process id with ps | grep 'plymouth'.
You will see two results: the plymouth service and your own ps grep command, usually the one with the lower process id is the correct one.
Then kill that process id with kill and the process id as first parameter.
The service will not be restarted until the device reboots as far as I know.
Hope this helps.

1 Like