My waveshare 5" hdmi/usb touchscreen died... another screen... no touch

Hardware
,
1

Hi folks,

Something seems to have happened to the HDMI controller on my waveshare 5" HDMI/USB (H) display… I’ve contacted the manufacturers … does the same thing on multiple machines, vanilla raspbian etc. … so for now, that’s dead.

in the mean time I’m trying my “BIQU BTT-HDMI5” touch display. I started with a fresh install of Raspbian and it worked without having to do anything … including touch.

On Zynthian, I’m struggling. The display works well, but the touch doesn’t… what’s weird is, if I do the following:

export DISPLAY=:0
sudo evtest /dev/input/event1 # this is the device "BIQU BTT-HDMI5"

and … I move my finger around the screen, I see output like this:

Event: time 1728656881.233104, -------------- SYN_REPORT ------------
Event: time 1728656881.257122, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 1950
Event: time 1728656881.257122, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 2517
Event: time 1728656881.257122, type 3 (EV_ABS), code 0 (ABS_X), value 1950
Event: time 1728656881.257122, type 3 (EV_ABS), code 1 (ABS_Y), value 2517
Event: time 1728656881.257122, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 0
Event: time 1728656881.257122, -------------- SYN_REPORT ------------
Event: time 1728656881.273106, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 1925
Event: time 1728656881.273106, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 2594
Event: time 1728656881.273106, type 3 (EV_ABS), code 0 (ABS_X), value 1925
Event: time 1728656881.273106, type 3 (EV_ABS), code 1 (ABS_Y), value 2594
Event: time 1728656881.273106, type 4 (EV_MSC), code 5 (MSC_TIMESTAMP), value 0

So this tells me the driver is working, the touch is working etc…

BUT… zynthian doesn’t respond to any touch, and the mouse doesn’t move.

Any thoughts on where I should look next to fix this?

2

The x & y values are rather high. I wonder if the screen is appearing as a second display that is offset. The resolutoin of that screen is 800*480 so you shouldn’t be getting x/y values in the thousands.

Do you have another display attached?

3

hmmm … nope. No other display attached. I’m trying now to move over to libinput driver…

(venv) root@zynthian:/home/mikef# xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ vc4-hdmi-0 id=8 [slave pointer (2)]
⎜ ↳ vc4-hdmi-1 id=9 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ pwr_button id=7 [slave keyboard (3)]
↳ vc4-hdmi-0 id=10 [slave keyboard (3)]
↳ vc4-hdmi-1 id=11 [slave keyboard (3)]
∼ BIQU BTT-HDMI5 id=6 [floating slave]

I notice that the BIQU BTT-HDMI5 is showing as a floating slave… Not sure if that’s a problem.

4

Also … I spotted this the /root/.xsession-errors:

(xfce4-panel:1185): dbind-WARNING **: 17:15:49.533: Couldn’t connect to accessibility bus: Empty address ‘’
xfce4-panel: Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER environment variable not defined

(x-window-manager:1127): xfwm4-WARNING **: 17:15:50.015: Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER environment variable not defined

(xfce4-panel:1185): xfce4-panel-CRITICAL **: 17:17:16.417: Name org.xfce.Panel lost on the message dbus, exiting.
Xsession: X session started for root at Fri 11 Oct 17:17:41 BST 2024
dbus-update-activation-environment: systemd --user not found, ignoring --systemd argument
dbus-update-activation-environment: setting DISPLAY=:1
localuser:root being added to access control list

5

Holy cow! …

(venv) root@zynthian:/home/mikef# xinput list-props “BIQU BTT-HDMI5”
Device ‘BIQU BTT-HDMI5’:
Device Enabled (155): 0
Coordinate Transformation Matrix (156): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
libinput Calibration Matrix (288): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
libinput Calibration Matrix Default (289): 1.000000, 0.000000, 0.000000, 0.000000, 1.000000, 0.000000, 0.000000, 0.000000, 1.000000
libinput Send Events Modes Available (290): 1, 0
libinput Send Events Mode Enabled (291): 0, 0
libinput Send Events Mode Enabled Default (292): 0, 0
Device Node (293): “/dev/input/event1”
Device Product ID (294): 1241, 32816
(venv) root@zynthian:/home/mikef# xinput enable “BIQU BTT-HDMI5”

xinput enable “BIQU BTT-HDMI5”

and I have a working touch screen!

… until I rebooted…

have added it into my /root/.xsessionrc … but that doesn’t work ;(

1 Like
6

maybe to put it somewhere into the main x config…?

7

yes… BUT WHERE??? :wink:

dammit … so close!

8

Right … I pinned down the line of code in multitouch.py that is disabling my touchscreen…

           devices = glob("/dev/input/event*")
        for device in devices:
            try:
                idev = InputDevice(device)
                idev_caps = idev.capabilities()
                # Look for the first device supporting multi-touch
                if idev_caps[ecodes.EV_ABS][ecodes.ABS_Z][0] == ecodes.ABS_MT_SLOT:
                    self.max_x = idev_caps[ecodes.EV_ABS][ecodes.ABS_X][1].max
                    self.max_y = idev_caps[ecodes.EV_ABS][ecodes.ABS_Y][1].max
                    self._f_device = open(device, 'rb', self.EVENT_SIZE)
                    for libinput in self.xinput("--list").split("\n"):
                        if idev.name in libinput and "slave  pointer" in libinput:
                            device_id = libinput.split("id=")[1].split()[0]
***

> #                            self.xinput("disable", device_id)

***
                            break
                    break
            except:
                pass

This tells me that there are other pointer devices and the one I want isn’t first in the list. At least I understand what’s happening now. (kind of).

(venv) root@zynthian:/home/mikef# grep pointer /var/log/Xorg.0.log
[     6.576] (II) event2  - vc4-hdmi-0: device is a pointer
[     6.601] (II) event2  - vc4-hdmi-0: device is a pointer
[     6.602] (II) event4  - vc4-hdmi-1: device is a pointer
[     6.629] (II) event4  - vc4-hdmi-1: device is a pointer

now to figure out how to prevent pointer:vc4-hdmi-0 & pointer:vc4-hdmi1 from getting added

9

Ok … I dunno … I’ve just commented out the line in the /zynthian/zynthian-ui/zyngui/multitouch.py … I realize this will get overwritten with updates… but at least it’s got me working for now. I have a DSI screen on it’s way from the US … but will probably only see it in a month or two.

10

Hi

//zynthian/config/zynthian_custom_config.sh

don’t forget to chmod a+x, this script is executed as root during startup and it will not be deleted from testing(vangelis) on. In latest stable(oram), it will be deleted as soon as you write something from webconf and you will have to restore it, for example cp from a backup you made earlier.

(EDIT: your solution of commenting out this line in multitouch.py is perfect. it just works, please disregard what I wrote here earlier.)
(EDIT of EDIT: No, just deleting that one line in multitouch.py makes the touch functional, until one scales the pattern editor, then further pattern editors would load forever or tapping the Zynswitch for it will provoke ERROR CUIA zynswitch: (10,‘5’) or similar. )

I had a similar issue with a Waveshare screen, so I installed uhubctl

sudo apt-get install uhubctl

and put into zynthian_custom_config.sh

#!/bin/bash
iw reg set DE
uhubctl -l 3 -p 2 -a 0

The -p 2 means lower black USB port on the Pi 5, that’s where my display is connected, -p 1 would be the upper port, -l 3 is USB 2.0 hub on the black ports.
This is different from the previous approach of shutting down entire -l 3, as with the recent updates, it would disable USB 2.0 completely, except for the Waveshare touchscreen (some serious bug in all this).
Re-enabling with -a 1 would re-establish the bug of a non-functional touchscreen, so the port is intentionally powered down, but is will be kept alive.

The iw reg set DE is necessary if you want to connect WiFi to an AP on channels 12 or 13 or some 802.11a channels and if you want normal transmit power.
The raspi-config WiFi locale will be overwritten and deleted on booting Zynthian, so I restore it on every boot with this little hack…
Choose your own reg domain / locale for your country.

1 Like
11

@infinitymodular what hardware configuration do you have? What Raspberry Pi? I have not seen any of my RPi fail to detect a touchscreen as the first slave pointer. I will try with my USB touch later but knowing what platform you have will help. Give as much detail of your rig as you can so that we have a better chance of understanding the issue.

It is strange (to me at least) that hdmi is showing as a pointer. I guess there is a mechanism for passing pointer info ov er the hdmi data channel. We could block this but we should consider whether someone may want to use it, e.g. with a hdmi connected touchscreen that carries the touch data over the hdmi data link. We could add something to config in webconf.

This is probably best tracked in a bug report. Raise one from the “Report Issue” button in webconf to capture the hardware config in the template.

@fussl you should raise a feature request for a user script that is not overwritten during boot. I think @jofemodo has pointed at one in the past but we may want another that runs before / after zynthian starts. We could add hooks in the service to run these scripts that do nothing by default.

12

@riban, My setup is super simple… RBPi5 - 4GB + BTT-HDMI5 Touch display…. That’s it.

The display is the classic HDMI + USB. The touch is handled over USB. Since commenting the line that disables /dev/event* pointers in the multitouch.py script. Everything now works. So I think for a temporary fix, this is probably fine for now. I’ve set the display up as WaveShare 5 HDMI+USB:

hdmi_force_hotplug=1
hdmi_drive=1
hdmi_group=2
hdmi_mode=87
hdmi_cvt=800 480 60 6 0 0 0
dtoverlay=vc4-kms-v3d-pi5

And I’m using the libinput driver for the touch by configuration in the /etc/X11/xorg.conf.d :

(venv) root@zynthian:/etc/X11/xorg.conf.d# cat 99-touchscreen.conf
Section “InputClass”
Identifier “Touchscreen”
MatchIsTouchscreen “on”
MatchProduct “6”
Driver “libinput”
EndSection

Section “InputClass”
Identifier “6”
MatchIsPointer “on”
MatchDevicePath “/dev/input/event*”
Driver “libinput”
EndSection

(venv) root@zynthian:/etc/X11/xorg.conf.d# xinput
⎡ Virtual core pointer id=2 [master pointer (3)]
⎜ ↳ Virtual core XTEST pointer id=4 [slave pointer (2)]
⎜ ↳ BIQU BTT-HDMI5 id=6 [slave pointer (2)]
⎜ ↳ vc4-hdmi-0 id=8 [slave pointer (2)]
⎜ ↳ vc4-hdmi-1 id=9 [slave pointer (2)]
⎣ Virtual core keyboard id=3 [master keyboard (2)]
↳ Virtual core XTEST keyboard id=5 [slave keyboard (3)]
↳ pwr_button id=7 [slave keyboard (3)]
↳ vc4-hdmi-0 id=10 [slave keyboard (3)]
↳ vc4-hdmi-1 id=11 [slave keyboard (3)]

It would seem that multitouch.py has logic to disable all libinput slave pointers… I’m not sure of the logic behind this. I have commented out the line that disables the devices. And now everything works… perhaps because evdev driver is being used by default.

devices = glob(“/dev/input/event*”)
for device in devices:
try:
idev = InputDevice(device)
idev_caps = idev.capabilities()

Look for the first device supporting multi-touch

if idev_caps[ecodes.EV_ABS][ecodes.ABS_Z][0] == ecodes.ABS_MT_SLOT:
self.max_x = idev_caps[ecodes.EV_ABS][ecodes.ABS_X][1].max
self.max_y = idev_caps[ecodes.EV_ABS][ecodes.ABS_Y][1].max
self._f_device = open(device, ‘rb’, self.EVENT_SIZE)
for libinput in self.xinput(“–list”).split(“\n”):
if idev.name in libinput and “slave pointer” in libinput:
device_id = libinput.split(“id=”)[1].split()[0]
# self.xinput(“disable”, device_id)
break
break
except:
pass

13

Touchscreen issues have been partly remedied in Testing Vangelis.
@jofemodo there is still an issue: