-
Notifications
You must be signed in to change notification settings - Fork 5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Waveshare 5inch Capacitive DSI Touchscreen - Touch not always working on boot #6538
Comments
Buster will have been running with the firmware based drivers by default. The kernel will be talking to the touch controller over I2C assuming it is an EDT FT5406 or 100% compatible. I don't know what Waveshare have used on their display. The fact the product page says 5 points of touch implies it isn't an FT5406, as those generally support 10 points. I do happen to have one of those displays, so will have a quick look. |
It may not be the cause of the problem, but this message suggests that the power supply is inadequate for the load during boot. |
Reproduced. If I were to hazard an educated guess, then I'd suspect that the touch controller is actually a GT911. On that chip the I2C address is set by the state of the IRQ line at boot, and then it changes from being an input to an output in order to function as the IRQ signal. |
Thank you @6by9 for your analysis and feedback! I have passed this on to @waveshare support, as well as your ability to reproduce. I'm hoping they engage in this thread soon. Their support had asked me if I was willing to replace/resolder the chips on impacted boards however I have these in remote locations with some quite frustrated users. I personally do not see this as a solution as I'm not the only user facing this problem, and it needs a real fix by them to address. If there was an interrupt active just before reboot, then the GT911 will have been pulling it high It's worth noting I often see this on first boot (i.e. power has also just been connected). In terms of the main chips: Note, only screens 1 & 2 & 3 have been tested below, but listing 4 showing the variation of chips used Screen 1 - QC17 Sticker ICN6211 A56456 2126 WSDIA2 2220 Screen 2 - QC17 Sticker ICN6211 D00090 2130 WSDIA2 2220 Screen 3 - QC-18 Sticker WSDIA (Can't easily read the rest) Screen 4 - QC01 Sticker ICN6211 A56456 2126 WSDIA2 2208 I should also add that my Pis are running 32bit Bookworm, rather than 64bit. I'm also using X instead of Wayland due to other Touchscreen issues currently in labwc (labwc/labwc#2373), and I didn't want to leave the Pis on Wayfire as I'm not sure how much longer that's going to be supported. Thanks, Matt |
Just to update Waveshare's latest response:
I will update the thread with any more info. Unfortunately Waveshare are suggesting either replacing the chips or screen replacement, with unfortunately neither choice an option for me. |
I wonder if this PR is for the replacement? #6566 |
Describe the bug
Hi,
Firstly, I'm aware this may not be the most appropriate place to raise this issue, however feel it has the right coverage of individuals to assist in troubleshooting and narrowing down what might be going wrong. I have also sent this thread to Waveshare support as currently I've been told from them to only "not touch the screen during bootup" which is not my issue.
I have about 20x RPI 4s using the https://www.waveshare.com/5inch-dsi-lcd-b.htm screen
I've found since updating a number of these Pis from Buster to Bookworm that I'm frequently getting the touch driver failing to register any touch input after booting up the Pi.
Typically a restart or complete disconnect/reconnect of RPI power result in the touch working on the next boot, however this has become a bit of a nightmare for reliability with end-users of our internal tool.
I'm not sure what the last kernel was that didn't appear to have issues, however I've had to update to
6.6.62+rpt-rpi-v8
due to a CAN Bus issue on recent previous kernels.I am using the
dtoverlay=vc4-kms-v3d
overlay which is what @waveshare say to use on their wiki, however from other posts on the forum I understand that waveshare ideally should be using their own dtoverlay rather than the same one as the official RPI screens.I strongly suspect I'm hitting the same problem or similar issue as #6298
I also have attempted to run
evtest
(with results below), however in the same case as @kyngs there are no logs/debug when touching the screen.evtest logs
Is there anything further I can do for troubleshooting or assisting with testing towards a potential fix?
I believe this is a software issue, and not hardware due to many of my screens/rpi4 combos not having touch issues prior to the bookworm update.
Thanks,
Matt
Steps to reproduce the behaviour
Device (s)
Raspberry Pi 4 Mod. B
System
/boot/firmware/config.txt
Logs
dmesg
Additional context
No response
The text was updated successfully, but these errors were encountered: