Rpi-ft5406 touchscreen not working in electron app

Product support
1

I’ve got an electron app running on a pi with the standard 7" touch screen (rpi-ft5406) and I cannot for the life of me get the touch to work. I’m working off of the resin-electronjs template. I’ve enabled touch events with URL_LAUNCHER_TOUCH. Some of my screen settings were ported over from the raspbian OS and they’ve all worked fine for simply rotating the screen. I’ll list them below in case someone notices some conflicting configuration. The screen is in portrait mode essentially.

RESIN_HOST_CONFIG_display_lcd_rotate: 1
RESIN_HOST_CONFIG_dtoverlay: rpi-ft5406,touchscreen-swapped-x-y=1,touchscreen-inverted-x=1

I did enable the cursor as well just to make sure that the touch events weren’t registering, via this guide:

Anyone have any ideas? I imagine it’s something silly that’s just outside my reach.

raspberry pi 3 b+
balenaOS 2.38.0+rev1

1 Like
3

Let me ask a few questions to clarify the status – sorry if a few of them seem obvious, but “being on the same page” usually helps a lot… :slight_smile:

  • When you say you cannot get the touch screen to work, does it mean that it is completely unresponsive to any touches?
    • I understand that the screen image displays correctly, and rotation also works correctly, just the touches aren’t working, right?
    • I note you say that you also “enabled the cursor”: did it make any difference before/after enabling the cursor?
  • How are you establishing that “the touch events weren’t registering”? Perhaps running some tool?
  • You’ve enabled touch events with URL_LAUNCHER_TOUCH. I see in the resin-electronjs README that there is another variable, URL_LAUNCHER_TOUCH_SIMULATE that “might be useful for touchscreen with partial driver support”. Perhaps you could try that just as an additional data point in the investigation.
  • I came across the following closed issue (you may have seen it too), and in one of the comments there, they mention the command lsmod that should have a row for rpi_ft5406. Could you share your lsmod output? On this point, is there anything “suspicious” in the output of some debugging commands like "dmesg" or "journalctl -ab"?

This reply probably doesn’t help much, but your answers will hopefully instigate a more relevant exchange that may eventually actually be useful. :slight_smile:

4

Nothing obvious to me here. I’m currently in a state where I don’t even know what kind of information to provide so I’m happy to answer any and all clarifying questions!

The touch screen is totally unresponsive. Enabling the cursor didn’t make any difference. I had done that to verify that it wasn’t a case of my axis being incorrect and that my touches were just registering in different locations. I wasn’t using any tools - just my eyeballs. Very scientific, I know.

I had tried URL_LAUNCHER_TOUCH_SIMULATE but saw no change.

There is a record for rpi_ft5406 returned by lsmod. I’ve attached the outputs those commands below. I didn’t see anything alarming. There were some references to the screen but nothing looked amiss.

dmesg.log (21.2 KB)
lsmod.log (1.7 KB)
journalctl-ab.log (111.1 KB)

Thanks so much for the response. I’ll keep troubleshooting and if I find anything new I’ll post it here.

For what it’s worth, maybe related, I can’t the my mouse to register inputs either.

5

Thanks for the answers. :+1:
From dmesg (for the benefit of anyone else reading this), these two lines seem to be of interest:

[    9.221333] rpi-ft5406 rpi_ft5406: Probing device
[    9.228669] input: FT5406 memory based driver as /devices/virtual/input/input0

And from lsmod:

Module                  Size  Used by
rpi_ft5406             16384  0

I wonder if anything in following thread would apply and be helpful here, including some of the debugging methods, like using xinput:

Given that dmesg showed that /devices/virtual/input/input0 “is there”, it would be interesting to somehow find out whether touch events are being produced and could be “read” somehow, just not being captured at a higher level.

7

Hey @AdamLee,

Just to confirm that with the Pi3, you only need to supply power to the display plus the flat cable.
To make sure your hardware is working correctly, can you deploy the balenaDash project https://github.com/balena-io-projects/balena-dash,

Point WPE_URL to some website such as https://balena.io and see if the touch works?

Thanks

8

@pdcastro

Interestingly enough xinput gives me “Unable to connect to X server” which is odd because xinit says “Server is already active for display 0”. I tried the other options in that thread with no success.

@dansku

The touchscreen works because if I switch over to raspbian I don’t have any issues. I can still give that a shot though if you think it would be beneficial.

Also just for the sake of it here are the relative lines in my dockerfile:

RUN install_packages \
xserver-xorg-core \
xserver-xorg-input-all \
xserver-xorg-video-fbdev \
xserver-xorg-input-evdev \
xorg \
xinput \
…
…

9

Some more interesting log messages…

28.06.19 09:46:49 (-0500) main [45:0628/144649.517640:ERROR:bus.cc(427)] Failed to connect to the bus: /usr/bin/dbus-launch terminated abnormally without any error message

[ 6456.290]
X.Org X Server 1.19.2
Release Date: 2017-03-02
[ 6456.291] X Protocol Version 11, Revision 0
[ 6456.291] Build Operating System: Linux 4.9.41-v7+ armv7l Raspbian
[ 6456.292] Current Operating System: Linux c5e9086 4.14.98 #1 SMP Mon Jun 17 12:13:38 UTC 2019 armv7l
[ 6456.292] Kernel command line: 8250.nr_uarts=1 bcm2708_fb.fbwidth=480 bcm2708_fb.fbheight=800 bcm2708_fb.fbdepth=16 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3f000000 vc_mem.mem_size=0x3f600000 dwc_otg.lpm_enable=0 console=tty1 console=ttyS0,115200 rootfstype=ext4 rootwait root=PARTUUID=1e5c56fe-02 rootwait
[ 6456.293] Build Date: 18 October 2017 04:55:30PM
[ 6456.294] xorg-server 2:1.19.2-1+rpt1+deb9u2 (https://www.debian.org/support)
[ 6456.294] Current version of pixman: 0.34.0
[ 6456.295] Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
[ 6456.295] Markers: (–) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[ 6456.297] (==) Log file: “/var/log/Xorg.0.log”, Time: Fri Jun 28 15:57:12 2019
[ 6456.298] (==) Using system config directory “/usr/share/X11/xorg.conf.d”
[ 6456.299] (==) No Layout section. Using the first Screen section.
[ 6456.299] (==) No screen section available. Using defaults.
[ 6456.299] (**) |–>Screen “Default Screen Section” (0)
[ 6456.299] (**) | |–>Monitor “”
[ 6456.300] (==) No monitor specified for screen “Default Screen Section”.
Using a default monitor configuration.
[ 6456.300] (==) Automatically adding devices
[ 6456.300] (==) Automatically enabling devices
[ 6456.300] (==) Automatically adding GPU devices
[ 6456.300] (==) Max clients allowed: 256, resource mask: 0x1fffff
[ 6456.300] (WW) The directory “/usr/share/fonts/X11/cyrillic” does not exist.
[ 6456.300] Entry deleted from font path.
[ 6456.301] (==) FontPath set to:
/usr/share/fonts/X11/misc,
/usr/share/fonts/X11/100dpi/:unscaled,
/usr/share/fonts/X11/75dpi/:unscaled,
/usr/share/fonts/X11/Type1,
/usr/share/fonts/X11/100dpi,
/usr/share/fonts/X11/75dpi,
built-ins
[ 6456.301] (==) ModulePath set to “/usr/lib/xorg/modules”
[ 6456.301] (II) The server relies on udev to provide the list of input devices.
If no devices become available, reconfigure udev or disable AutoAddDevices.
[ 6456.301] (II) Loader magic: 0x1fbf40
[ 6456.301] (II) Module ABI versions:
[ 6456.301] X.Org ANSI C Emulation: 0.4
[ 6456.301] X.Org Video Driver: 23.0
[ 6456.301] X.Org XInput driver : 24.1
[ 6456.301] X.Org Server Extension : 10.0
[ 6456.301] (EE) dbus-core: error connecting to system bus: org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory)
[ 6456.302] (–) using VT number 2

[ 6456.302] (II) systemd-logind: logind integration requires -keeptty and -keeptty was not provided, disabling logind integration
[ 6456.302] (II) no primary bus or device found
[ 6456.303] (II) LoadModule: “glx”
[ 6456.305] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so
[ 6456.311] (II) Module glx: vendor=“X.Org Foundation”
[ 6456.311] compiled for 1.19.2, module version = 1.0.0
[ 6456.311] ABI class: X.Org Server Extension, version 10.0
[ 6456.311] (==) Matched modesetting as autoconfigured driver 0
[ 6456.311] (==) Matched fbdev as autoconfigured driver 1
[ 6456.311] (==) Assigned the driver to the xf86ConfigLayout
[ 6456.311] (II) LoadModule: “modesetting”
[ 6456.312] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so
[ 6456.313] (II) Module modesetting: vendor=“X.Org Foundation”
[ 6456.313] compiled for 1.19.2, module version = 1.19.2
[ 6456.313] Module class: X.Org Video Driver
[ 6456.313] ABI class: X.Org Video Driver, version 23.0
[ 6456.313] (II) LoadModule: “fbdev”
[ 6456.314] (II) Loading /usr/lib/xorg/modules/drivers/fbdev_drv.so
[ 6456.314] (II) Module fbdev: vendor=“X.Org Foundation”
[ 6456.314] compiled for 1.19.0, module version = 0.4.4
[ 6456.314] Module class: X.Org Video Driver
[ 6456.314] ABI class: X.Org Video Driver, version 23.0
[ 6456.314] (II) modesetting: Driver for Modesetting Kernel Drivers: kms
[ 6456.314] (II) FBDEV: driver for framebuffer: fbdev
[ 6456.315] (WW) Falling back to old probe method for modesetting
[ 6456.315] (EE) open /dev/dri/card0: No such file or directory
[ 6456.315] (WW) Falling back to old probe method for fbdev
[ 6456.316] (II) Loading sub module “fbdevhw”
[ 6456.316] (II) LoadModule: “fbdevhw”
[ 6456.316] (II) Loading /usr/lib/xorg/modules/libfbdevhw.so
[ 6456.316] (II) Module fbdevhw: vendor=“X.Org Foundation”
[ 6456.317] compiled for 1.19.2, module version = 0.0.2
[ 6456.317] ABI class: X.Org Video Driver, version 23.0
[ 6456.317] (II) FBDEV(0): using default device
[ 6456.317] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support
[ 6456.317] (II) FBDEV(0): Creating default Display subsection in Screen section
“Default Screen Section” for depth/fbbpp 16/16
[ 6456.317] (==) FBDEV(0): Depth 16, (==) framebuffer bpp 16
[ 6456.317] (==) FBDEV(0): RGB weight 565
[ 6456.317] (==) FBDEV(0): Default visual is TrueColor
[ 6456.317] (==) FBDEV(0): Using gamma correction (1.0, 1.0, 1.0)
[ 6456.317] (II) FBDEV(0): hardware: BCM2708 FB (video memory: 750kB)
[ 6456.317] (II) FBDEV(0): checking modes against framebuffer device…
[ 6456.317] (II) FBDEV(0): checking modes against monitor…
[ 6456.318] (–) FBDEV(0): Virtual size is 480x800 (pitch 480)
[ 6456.318] (**) FBDEV(0): Built-in mode “current”
[ 6456.318] (==) FBDEV(0): DPI set to (96, 96)
[ 6456.318] (II) Loading sub module “fb”
[ 6456.318] (II) LoadModule: “fb”
[ 6456.318] (II) Loading /usr/lib/xorg/modules/libfb.so
[ 6456.319] (II) Module fb: vendor=“X.Org Foundation”
[ 6456.319] compiled for 1.19.2, module version = 1.0.0
[ 6456.319] ABI class: X.Org ANSI C Emulation, version 0.4
[ 6456.319] (**) FBDEV(0): using shadow framebuffer
[ 6456.319] (II) Loading sub module “shadow”
[ 6456.319] (II) LoadModule: “shadow”
[ 6456.319] (II) Loading /usr/lib/xorg/modules/libshadow.so
[ 6456.320] (II) Module shadow: vendor=“X.Org Foundation”
[ 6456.320] compiled for 1.19.2, module version = 1.1.0
[ 6456.321] ABI class: X.Org ANSI C Emulation, version 0.4
[ 6456.321] (II) UnloadModule: “modesetting”
[ 6456.321] (II) Unloading modesetting
[ 6456.323] (==) FBDEV(0): Backing store enabled
[ 6456.325] (==) FBDEV(0): DPMS enabled
[ 6456.325] (==) RandR enabled
[ 6456.343] (II) SELinux: Disabled on system
[ 6456.346] (II) AIGLX: Screen 0 is not DRI2 capable
[ 6456.346] (EE) AIGLX: reverting to software rendering
[ 6456.452] (II) IGLX: enabled GLX_MESA_copy_sub_buffer
[ 6456.454] (II) IGLX: Loaded and initialized swrast
[ 6456.454] (II) GLX: Initialized DRISWRAST GL provider for screen 0
[ 6456.624] (EE) dbus-core: error connecting to system bus: org.freedesktop.DBus.Error.FileNotFound (Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory)

11

Thanks for the feedback!
On a slightly different note, take a look at this project, see if it fits your needs:
https://github.com/willswire/balena-dashboards

14 
[ 6456.301] (EE) dbus-core: error connecting to system bus: org.freedesktop.DBus.Error.FileNotFound
(Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory)

Hmm this looks like a rather objective and deterministic error (file not found). :slight_smile: Re DBUS socket, some applications should share the same DBUS socket / daemon as the host OS (balenaOS), but other applications should not use the host OS DBUS and should instead run their own separate DBUS daemon in the app container. In the former case, sharing the host OS DBUS daemon can be achieved with some ENV vars and multicontainer label, but if your application should not share the host OS DBUS daemon, then the fix would be in installing the required packages and configuring systemd to start the daemon in the app container.

If you run the resin-electronjs or the balena-dashboards projects “unmodified”, do you still get this error? Having a working starting point as a reference would be helpful…

16

@pdcastro

Booted with vanilla balena-dashboards on a new application and the touch screen was not responsive. Booted with raspbian and the touch screen is functioning just fine.

23

I also tried running balena-dashboards on the 64-bit OS because I wanted to eliminate that as a variable and it doesn’t seem to work. The dashboard can’t detect the host OS version, though it does show the logs from vnc and electron and they seem to be functioning. The screen is completely black. Running startx on the terminal doesn’t show anything on the display either.

So… I guess I don’t know if this is a variable I can truly eliminate. I wonder if it’s perhaps an issue with electron because I couldn’t get it functioning on a 64-bit OS either. I’ll may try downloading 32-bit raspbian to see if the touchscreen still functions… except that there isn’t a 64-bit version so what I have is indeed 32-bit.

I did a reboot of the 64-bit OS with balena-dashboards and saw a suspicious message on the screen:

IMG_5755
IMG_5755.jpg3183×2384 2.38 MB

26

Maybe @wwalker can help here - have you ever tried using a touchscreen with your balena-dashboards project? If not do you have any idea of the changes that would be required to get one working?

30

While going crazy I ran across this post and corresponding repository. This certainly seems related so I think I’m going to try and integrate portions of this repo to see what sticks. Until then I welcome any and all knights in shining armor.

32

There was a brief period of time where I was testing touchscreen support on a GPIO interface. Not much luck. I would definitely ensure everything at the balenaOS level is working (setting proper device configuration variables, etc.), but then also adding whatever Debian packages are needed. I think xorg-input-all or something like it is required for touch support within X (this is if you’re installing the balena-dashboards project).

I can certainly test some things on my end once I find some time.

35

@adamlee could you please share your Dockerfile?
Can you move the cursor if you plug an usb mouse?
Did you set ENV UDEV=1 in your Dockerfile?

38

@zvin

No, I haven’t been able to get the cursor to work with a USB mouse or keyboard.

Dockerfile attached (renamed the extension from template to attach here). I have set this up as a multicontainer environment now and the two services I have do work but I still can’t seem to get touch or USB input functioning. I have played around with ENV UDEV = 1 as well.

docker-compose.log (261 Bytes)

Dockerfile.log (2.5 KB)

39

Hello, I’m using the following Dockerfile in a project (slightly modified to remove unused things):
It works fine with both a mouse and a touchscreen.
Make sure it’s privileged.
You may not need to install all the stuff I’m installing with apt-get.
Having ENV UDEV=true is important.

FROM balenalib/%%BALENA_MACHINE_NAME%%-debian-node:10.16.0-stretch

RUN apt-get update \
  && apt-get install -y --no-install-recommends \
    x11-xserver-utils \
    xinit \
    xserver-xorg \
    xserver-xorg-video-fbdev \
  && apt-get clean \
  && rm -rf /var/lib/apt/lists/*

COPY /path/to/your/app /usr/src/app

ENV DBUS_SYSTEM_BUS_ADDRESS=unix:path=/host/run/dbus/system_bus_socket
ENV UDEV=true

CMD ["bash", "/usr/src/app/start.sh"]
42

Alright everyone I finally got this working. What a journey - you all have been incredibly helpful.

Once I upgraded my app to Electron 5 and essentially rolled back almost all of my dockerfile changes I was able to use the example posted by @zvin to change my dockerfile and get the touchscreen working. The last bit was rotating the touchscreen since we have our screen positioned vertically. Both the display and the touchscreen are rotated with fleet configuration.

Looking back I think the number of red herrings I ran into (such as installing systemd) were a large barrier to getting this set up.

43

Thank you for sharing the outcome! It will help other users who find this thread.