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 |
So this PR won't solve this issue? |
My main reasoning is:
Regarding the PR, yeah I'm hoping that's a fix, but I haven't anything back from their support team to suggest that yet. Thanks, |
My basic understanding is (tho this may be completely wrong): From my findings, the rpi-ft5406 driver works perfectly with the touchscreen. However, my original issue is that it cannot be used with the modern camera system (in my case, with the imx477 driver) but only with the legacy camera. Do you have a testing device on hand where you could test whether the rpi-ft5406 works for you?
Yeah I wish, tho the panels are quite old. Hopefully the PR they sent in will fix this. |
|
#6566 is unrelated - that is for their new screens, not amending support for their old ones. rpi-ft5406 uses mailbox calls to the firmware to poll the touchscreen for when the firmware is also using the I2C interface (eg the legacy camera stack). If the Waveshare panel were a genuine EDT FT5x06 touch controller, then either will work quite happily. As I commented in #6538 (comment), I suspect that they are emulating it through a microcontroller, and that emulation is flawed. The same flaw would normally affect both drivers, so there is possibly something to investigate there. The two drivers do use slightly different approaches to communicating with the touch controller. There was a thread back in 2021 where DFRobot panels also tried to do the same, but implemented even less of the FT5x06 protocol to the point that it only worked with the firmware driver. Patches at https://patchwork.kernel.org/project/linux-input/patch/20211216233041.1220-4-tharvey@gateworks.com/ were suggested as a workaround there. If I were to investigate this (which I'm not overly planning on doing as it's not a Raspberry Pi product for me to support) then I'd probe the connections on the smaller 6 pin connector going into the panel (on the left in the photos above), as that is going to be the comms for touch. I'd expect to have power, ground, SDA, SCL, reset, and interrupt. Almost any oscilloscope these days will decode the I2C for you, so you can compare to the FT5x06 protocol. The main tell-tale I'm expecting is that when it fails you get no ACKs to any I2C read. That would match with my guess that it is a GT911 which has changed I2C address due to incorrect handling of the interrupt line. Once there is an understanding of exactly what the problem is within the display and why it's not giving correct touch data, then there can be discussion about possible workarounds in the kernel to mitigate the limitations (delays, amending I2C calls, or something else). |
Hi, thanks for the analysis. I personally possess no skills, or equipment to fix this issue, so I guess I'm out of luck. I would love to use the official display, but afaik it's only made in 7", and I need 5" max (my current 4.3" is ideal). |
|
I'd expect to have power, ground, SDA, SCL, reset, and interrupt.
I have one of those cheap usb logic analyzers so might try capturing a
"good" vs "bad" case and attach to this issue.
Do I just need the sda scl and Gnd? Or also the interrupt line?
Thanks
…On Thu, 2 Jan 2025 at 1:27 PM, kyngs ***@***.***> wrote:
#6566 <#6566> is unrelated -
that is for their new screens, not amending support for their old ones.
rpi-ft5406 uses mailbox calls to the firmware to poll the touchscreen for
when the firmware is also using the I2C interface (eg the legacy camera
stack). edt-ft5x06 is the kernel directly talking I2C to the touch panel.
If the Waveshare panel were a genuine EDT FT5x06 touch controller, then
either will work quite happily. As I commented in #6538 (comment)
<#6538 (comment)>,
I suspect that they are emulating it through a microcontroller, and that
emulation is flawed. The same flaw would normally affect both drivers, so
there is possibly something to investigate there.
The two drivers do use slightly different approaches to communicating with
the touch controller. There was a thread back in 2021
***@***.***/>
where DFRobot panels also tried to do the same, but implemented even less
of the FT5x06 protocol to the point that it only worked with the firmware
driver. Patches at
***@***.***/
were suggested as a workaround there.
If I were to investigate this (which I'm not overly planning on doing as
it's not a Raspberry Pi product for me to support) then I'd probe the
connections on the smaller 6 pin connector going into the panel (on the
left in the photos above), as that is going to be the comms for touch. I'd
expect to have power, ground, SDA, SCL, reset, and interrupt. Almost any
oscilloscope these days will decode the I2C for you, so you can compare to
the FT5x06 protocol. The main tell-tale I'm expecting is that when it fails
you get no ACKs to any I2C read. That would match with my guess that it is
a GT911 which has changed I2C address due to incorrect handling of the
interrupt line.
Once there is an understanding of exactly what the problem is within the
display and why it's not giving correct touch data, then there can be
discussion about possible workarounds in the kernel to mitigate the
limitations (delays, amending I2C calls, or something else).
Hi, thanks for the analysis. I personally possess no skills, or equipment
to fix this issue, so I guess I'm out of luck. I would love to use the
official display, but afaik it's only made in 7", and I need 5" max (my
current 4.3" is ideal).
A bit offtopic: do you have an idea if I can somehow get the imx477 and
rp-ft5406 drivers working together?
—
Reply to this email directly, view it on GitHub
<#6538 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABD2WXOZCEDDYP4YG4U7K532ISBVJAVCNFSM6AAAAABTVLJ54CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRXGE4TQMJYGI>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Yes, as you mentioned earlier, if the touch signals are active before the Bookworm system fully boots, the GT911 levels may behave abnormally, leading to occasional errors. We have adjusted the MCU program to handle this anomaly and are conducting comprehensive testing. We expect the results soon. Once the testing is complete and successful, we will do our utmost to provide appropriate after-sales support for affected customers. |
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-v8due to a CAN Bus issue on recent previous kernels.I am using the
dtoverlay=vc4-kms-v3doverlay 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: