UPERFECT Y Portable Monitor touch input not working

I am attempting to get USB touch input working on a Raspberry Pi 4, 4GB.
video output on HDMI is working

I am using the Balena OS 2.94.4.

The results of lsusb are:

root@08e79b6:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux 5.10.83-v8 xhci-hcd xHCI Host Controller
Bus 001 Device 007: ID 0403:6001 FTDI USB-RS485 Cable
Bus 001 Device 006: ID 248a:8367 Telink Wireless Receiver
Bus 001 Device 004: ID 20b1:0104 AV Access AVA AnyCo A3
Bus 001 Device 009: ID 0416:c168 TSTP MTouch
Bus 001 Device 008: ID 1a40:0801 USB 2.0 Hub
Bus 001 Device 002: ID 2109:3431 USB2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux 5.10.83-v8 xhci-hcd xHCI Host Controller

the results of ls /dev/input are:

oot@08e79b6:~# ls /dev/input
by-id by-path event0 event1 event2 event7 event8 mice mouse0 mouse1

No response at all to touches on the screen.

More info: With a standard raspios install the touch input works correctly.

Hello,

can you please share more details about the application that you ware building?
I understand that you have a RaspberryPi 4 connect with HDMI and USB to the UPERFECT Y external monitor, right?

  • What application drives / creates the image for the screen?
  • Do you see a pointer on the screen that can be moved with another input device? (Can you test it with an USB mouse)
  • How do you determine that the input is not working?
  • Can you please unplug and plug the USB touch screen cable and share the dmesg output from the hostOS directly after you’ve plugged in the cable?
  • Do you have a docker-compose file to specify the applications running on the balenaOS? Can you share it?
  • When you say it works on raspios, how are the applications running on the raspios in comparison to balenaOS? Are they also containerized?
  • Can you share sources and descriptions of the applications that you want to run on balenaOS as services?

Thanks and best regards
Harald

First of all I want to say thank you for the excellent questions and willingness to help.

The application that drives / creates images for the screen is Flutter. I am using the excellent flutter-pi embedder that can be found here: GitHub - ardera/flutter-pi: A light-weight Flutter Engine Embedder for Raspberry Pi that runs without X.

For my testing purposes I am using the very basic counter app from Flutter that has a single button. It turns out that the touch actually is working. As you can see in the pictures below that there is a gap around the border and I was touching in the wrong place. So I think I am down figuring out how to get the app scaled properly to the screen. I am not using containers on the app that is properly scaled and it is the using the raspios 64 bit lite found at this page Operating system images – Raspberry Pi

Here is my docker file:

FROM balenalib/%%BALENA_MACHINE_NAME%%-debian:bullseye AS build

ENV UDEV 1

RUN usermod -a -G render root

RUN apt-get -y update
RUN apt-get -y install git
wget
gcc
g++
build-essential

WORKDIR /DEVELOP

RUN git clone --depth 1 GitHub - ardera/flutter-engine-binaries-for-arm: flutter engine binaries (libflutter_engine.so) for arm & aarch64 engine-binaries && \
cd engine-binaries &&
./install.sh

RUN apt-get -y install cmake
libgl1-mesa-dev
libgles2-mesa-dev
libegl1-mesa-dev
libdrm-dev
libgbm-dev
libgl1-mesa-dri

RUN echo “deb Index of /debian bullseye main contrib” > /etc/apt/sources.list
&& echo “deb Index of /debian-security bullseye-security main contrib” >> /etc/apt/sources.list
&& echo “ttf-mscorefonts-installer msttcorefonts/accepted-mscorefonts-eula select true” | debconf-set-selections
&& apt-get update
&& apt-get install -y ttf-mscorefonts-installer

RUN apt-get -y install fontconfig
libsystemd-dev
libinput-dev
libudev-dev
libxkbcommon-dev

RUN fc-cache

RUN git clone GitHub - ardera/flutter-pi: A light-weight Flutter Engine Embedder for Raspberry Pi that runs without X.
WORKDIR /DEVELOP/flutter-pi/build
RUN cmake …
RUN make -j nproc
RUN make install

WORKDIR /DEVELOP

COPY counter/build/flutter_assets ./flutter_assets

CMD flutter-pi ./flutter_assets

For completeness here is what dmesg gives me when I unplug and plug back in the USB touch from my screen:

[ 2471.332621] usb 1-1.3: USB disconnect, device number 5
[ 2471.332653] usb 1-1.3.3: USB disconnect, device number 7
[ 2474.631159] usb 1-1.3: new high-speed USB device number 8 using xhci_hcd
[ 2474.731875] usb 1-1.3: New USB device found, idVendor=1a40, idProduct=0801, bcdDevice= 1.00
[ 2474.731899] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
[ 2474.731917] usb 1-1.3: Product: USB 2.0 Hub
[ 2474.734213] hub 1-1.3:1.0: USB hub found
[ 2474.734386] hub 1-1.3:1.0: 4 ports detected
[ 2475.043128] usb 1-1.3.3: new full-speed USB device number 9 using xhci_hcd
[ 2475.154506] usb 1-1.3.3: New USB device found, idVendor=0416, idProduct=c168, bcdDevice= 0.00
[ 2475.154523] usb 1-1.3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 2475.154531] usb 1-1.3.3: Product: MTouch
[ 2475.154538] usb 1-1.3.3: Manufacturer: TSTP
[ 2475.154545] usb 1-1.3.3: SerialNumber: CMTP_1.0
[ 2475.165082] input: TSTP MTouch as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3.3/1-1.3.3:1.0/0003:0416:C168.0006/input/input10
[ 2475.165478] hid-generic 0003:0416:C168.0006: input,hidraw3: USB HID v1.11 Mouse [TSTP MTouch] on usb-0000:01:00.0-1.3.3/input0
[ 2475.180476] input: TSTP MTouch as /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.3/1-1.3.3/1-1.3.3:1.1/0003:0416:C168.0007/input/input11
[ 2475.180989] hid-multitouch 0003:0416:C168.0007: input,hidraw4: USB HID v1.11 Device [TSTP MTouch] on usb-0000:01:00.0-1.3.3/input1

Any thoughts on how to scale the screen to fit?

Another update… I went into config.txt (with a freshly flashed SD card before first boot). And I uncommented the #disable_overscan=1 line. Then the black border is gone. And things line up nicely. I then felt more confident and ran the gallery app as shown below. The touch inputs work and I was able to frolic around in the various parts of the app and the touch worked great everywhere.

One thing that is not quite right yet… If I make a change to my docker file and a new update gets pushed to the device, the touch input stops working. Only after I reboot the device does the touch input start working again. Any thoughts on how to debug this issue? Thanks.

Any words of wisdom on how to figure out why a reboot is needed when a container is updated to get the touch working again? Thanks.

Hello,

first of all, thanks a lot for sharing these details as this is very valuable for everyone here.
BTW the application looks nice and seeing this running on top of balenaOS is great :wink:

Regarding the reboot issue, again can you share some more details. I understand that you are pushing changes to the open-balena and from their the new service image is sent to the device, right? This step implicitly shuts down the old container and starts a new container.

Can you please describe more precise what steps you are following that lead to the no working touch input.

  1. Can you please check on the hostOS and in the container if the touch device is still mounted to /dev/ ?
  2. Can you please check if unplugging and replugging solves the problem even without a reboot of the device?
  3. Can you please run this command on the balenaOS / hostOS after you have pushed a new version and the balena service image was updated on the device?
  • journalctl --no-pager -n 200 -u balena-supervisor this will show the last 200 log entries of the supervisor
  • journalctl --no-pager -n 200 -u balena this will show the last 200 log entries of the balena daemon

Please check if the logs are showing any suspicious entries and share them here, or share all of them. When you increase the log count (e.g. >1000) please upload them as a github gist and link to it.

  1. Can you execute these commands on the balenaOS / hostOS.
systemctl stop balena-supervisor
systemctl stop balena
systemctl start balena
systemctl start balena-supervisor

They stop and start the balena-supervisor and the balena engine completely if this resolves the problem it indicates that the container or the engine is failing to attach to the touch interface after a container stop and start.

Thanks and best regards,
Harald

If I do an ls /dev. I see that hidraw0 is always there even if touch is not plugged in.
hidraw1 and hidraw2 go away when the touch controller is not plugged in. hidraw1 and hidraw2 come back when the touch controller USB is plugged back in.

The act of unplugging and replugging the USB does get the touch working.

executing these command in the hostOS does also get the touch working

systemctl stop balena-supervisor
systemctl stop balena
systemctl start balena
systemctl start balena-supervisor

Here is a link to the logs from the journalctl commands:

So so far there are three ways to get the touch working after a container rebuild:

physically unplug and replug the USB
run the systemctl stop and start commands
reboot the device from the Balena dash board.

If I run a balena push --nocache for the cli tool on my computer I can get the touch to fail every time after the new container is brought up.

I am using the “less than 10 devices” free plan for all my testing thus far. You had mentioned pushing to “open-balena”. Just for clarity not sure if that refers to the service I am using on the regular Balena.io website.

Thanks very much.

Any further ideas on how to figure out how to get the container to connect to the touchscreen without the reboot? Any kind of unplugging replugging is not an option for remote. systemctl stop and start commands are also not desirable. I could make this work knowing I have to send a reboot after an update, but am hoping there is a better way. Thanks.