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/[email protected]/ 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. |
|
Thanks for the update @Eng027! Much appreciated.
Do you expect the fix to be purely in the MCU/GT911? In other words any impacted device would require a hardware modification fix? Alternatively perhaps a way of upgrading the MCU's FW? Or is there likely a "software workaround" in the kernel? Thanks, Matt |
|
I found that touching the panel (and hence triggering some comms) before the device driver (edt_ft5x06) is loaded will trigger this issue. I guess the touch controller fails to receive ack or similar condition and then refuses to behave. Waveshare support have been looking at this since I reported it to them almost a year ago and have recently said this can only be fixed with a hardware change, replacing the controller chip which requires desoldering the old and soldering the new - quite drastic. It is a shame that the chip can't be reset by the driver. In case anyone is struggling to reproduce the issue, here is my workflow to trigger the fault:
This only occurs on RPi5. RPi4 does not suffer this issue. What diagnostics could I perform to assist the driver maintainer to possibly implement a software workaround? |
|
I have this same issue with the same LCD on Pi 4B, and am in a similar situation as the OP in terms of number of units in distant places. I can faithfully recreate this issue on my touchscreen. According to dmesg, I am using the ft5x06 driver. I am in contact with Waveshare support but they have not provided any details to me yet, only asking clarifying questions. Commenting here to keep track and hopefully shine more light on this issue. Based on my mechanical configuration, many users inadvertently touch the touchscreen while plugging in power. I can ask them not to, but that is very poor product design. |
I'll stress that this is not an issue that is under Raspberry Pi's control, and is an issue in the Waveshare panel.
Please be aware that editing comments does not notify participants on an issue. I'd therefore read your original post which didn't have this comment, and only saw it due to dsamarin1's update today. Others are reporting that they have the issue on Pi4. Are you sure you can't reproduce on Pi4? |
|
Hi @6by9, I totally appreciate this isn't a Raspberry Pi org problem, it is a 3rd party vendor problem. There doesn't seem to be any open discussion happening elsewhere online for us to latch on to, since Waveshare doesn't have user forums, and their official support communications (wiki, email) are lacking. Would be great if those of us having this issue could continue to collaborate here! Latest email reply to me from Waveshare:
|
|
I have validated that this also affects RPi4 but the boot process / timing on my OS differs so it is less likely to occur during boot. If I unload driver, touch screen then load driver, the fault occurs. This is true with legacy driver. Waveshare have informed me that this is due to an error in their interface chip (probably their EDT FT5x06 clone) and a fix involves replacing the chip. They are sure this cannot be resolved with software. |
|
For me, it occurs on Pi 4B, at all times. No matter the timing. |
|
I have the ability to de/solder such a chip. I'll ask them if they can send me one or two to test. If the chip looks the same, presumably this means they solved it with a firmware update perhaps? I wonder if this means we could create a jig to reflash the chip in-situ. |
|
I had an update in January (which I only skim read at the time unfortunately) and was advised that they may be able to send a programmer with firmware update to address the issue, rather than resolding chips. I'm awaiting a response to the email. I unfortunately recently was made redundant due to the company I did this work for leaving the New Zealand market, so please excuse me for being less intentional on this issue than previously. |
Yeah I assume that they only changed the firmware. To be fair, they did ask me upfront whether I could solder the chip myself, and I told them yes. (I kinda expected it would be smth like atmega328 size, not a few mm) Reprogramming the chip in place would be best, but I don't posses a programmer to do so. |
|
Hi all, I've spent some time today trying to understand the WSTPA0 (Waveshare Touch Panel A0) chip. I thought I'd share my findings here. WSTPA0 Pin out information:
FFC = 6 Pin Flat Flex Connector 1 - FFC5 - INT 11 - x TP (Test Points): 4 - 14 - ??? I then soldered on several wires and connected up my cheap logic analyzer.
As per the GT911 Datasheet and Programming Guide, we see it use Write Address 0xBA, and Read Address 0xBB: I then recorded a good case VS bad case i2c capture (Note, bad case is following the "finger touch during boot up process", not necessarily the same "bad case" I first reported in this issue) You can use PulseView to open them. What I don't understand:
Thanks, Matt |
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: