Official Raspberry Pi 7" Touchscreen Display (v1.1) -- Touch Does Not Work with Bookworm on RPi4 (32-bit or 64-bit)

[seandop]

On a fresh install of the latest Bookworm image from the Raspberry Pi Imager (default config.txt settings), the 7" official display works just fine as a monitor, but touch input is completely unrecognized. If I edit the config.txt to use the fkms driver rather then the kms driver, the touch input is acknowledged by the desktop interface, but the "click" action is not recognized.

apt update && apt full-upgrade and rpi-update have not changed this behavior. I have tried this on both the latest 32-bit Bookworm image and the latest 64-bit Bookworm image.

Installing the "legacy" Bullseye images also results in the same default behavior. With Bullseye, changing the driver to fkms allows for a fully-functional touchscreen (the "click" action is recognized), unlike for Bookworm.

If I instead install the latest Buster image, the touchscreen functions as expected.

I have a vague understanding that the graphics stack has undergone change over the past few years in an effort to move away from x11, and it appears that (at least on a RPi4), that the driver that is currently packaged in Bookworm loads the LCD display properly, but not the edt-ft5x06 driver.

I'm happy to provide any logs or other troubleshooting information. Thanks in advance for any help!

[lurch]

I've just tested this myself, and it all seems to be working fine "out of the box".
I wrote the latest version of Raspberry Pi OS 64-bit onto an SD-card using Raspberry Pi Imager, and selected "No" when asked if I wanted to apply customisation settings. I booted it up in a Raspberry Pi 4 Model B connected to power, Ethernet, a USB mouse & keyboard (just to be on the safe side - but I didn't need them) and a Touch Display 1.
I was able to navigate the entirety of the first-boot-wizard using just the touchscreen (although entering the second password-confirmation was slightly tricky), and when the Pi rebooted the desktop was fully responsive to touch events - I didn't have to edit any config files. I could even open up Terminal by clicking on it's icon, and the on-screen keyboard automatically appears. I can also connect an HDMI monitor and the touchscreen continues working perfectly.

Can you please confirm that you're using totally out-of-the box settings on a freshly-written image of the 2024-11-19 version of Raspberry Pi OS? Can you also confirm exactly what hardware you have attached to your Raspberry Pi 4?

EDIT: Forgot to mention, but I was using Bookworm.

[seandop]

Thanks for the quick reply! Before I go through and do this again... I noticed that you mentioned a "Touch Display 1". When I look at the picture of the board in your link, it reads "Raspberry Pi Display v1.0". Mine reads "Raspberry Pi Display v1.1". Is that difference significant enough to be relevant here?

[6by9]

No, lurch is distinguishing between the 800x480 https://www.raspberrypi.com/products/raspberry-pi-touch-display/ vs the new 720x1280 https://www.raspberrypi.com/products/touch-display-2/

Please check the kernel logs for any errors (dmesg).

[seandop]

Ok, I just gave it all another shot with no improvement unfortunately.

I downloaded and "burned" the latest version of Bookwork 64-bit (2024-11-19) via the Raspberry Pi Imager via a Windows PC onto the microSD card.

I was previously using customization settings. This time I clicked "No" and went absolutely "stock".

I did connect a USB keyboard this time, but I could not quickly locate a wired-mouse (I'm not sure I even own one anymore). The keyboard did allow me to get through the setup wizard. Still no touch response even once the wizard completed.

No additional hardware is installed on the Pi other than the USB keyboard and the Touch Display 1 (powered via the two wires from the Pi's GPIO header). I manually setup WiFi after the initial setup wizard, so I have nothing connected to the Ethernet jack either.

I then enabled SSH and ran apt update && apt full-upgrade and did a hard reboot. No change.

Just to leave no stone unturned, I ran rpi-update and did another hard reboot. Still no change.

I would start to think that this is a hardware issue, except that I was able to make the display work completely yesterday using Buster, and "sort-of" work in Bookworm.

Full dmesg output attached. Do you guys see any smoking guns here?
dmesg.txt

[lurch]

I'll have to check my own dmesg log when I'm back in the office tomorrow as a comparison, but I do see that your log says:

[    9.377989] edt_ft5x06 10-0038: touchscreen probe failed
[    9.378730] edt_ft5x06: probe of 10-0038 failed with error -5

I also see that your "Logitech G510s Gaming Keyboard" is appearing as multiple input devices, which might make investigating this trickier. Could you please disconnect that keyboard and post the dmesg log that you get after the next reboot? Thanks.

[seandop]

I'll have to check my own dmesg log when I'm back in the office tomorrow as a comparison, but I do see that your log says:

[    9.377989] edt_ft5x06 10-0038: touchscreen probe failed
[    9.378730] edt_ft5x06: probe of 10-0038 failed with error -5

I also see that your "Logitech G510s Gaming Keyboard" is appearing as _multiple
dmesg.txt
_ input devices, which might make investigating this trickier. Could you please disconnect that keyboard and post the dmesg log that you get after the next reboot? Thanks.

Yeah, sorry about that. It has a mic and headphone jack on the keyboard. I've removed it entirely and attached here is the updated dmesg. Nothing else is attached to the RPi now, other than the display and power cord.

dmesg.txt

[6by9]

For some reason the kernel has failed to communicate with the touch controller.

Could you try running sudo rmmod edt-ft5x06 and then sudo modprobe edt-ft5x06 which will retry the communication attempt?
The touch controller reset line is controlled by the microcontroller on the display board via I2C, but that shouldn't be an issue as the driver has all documented required delays implemented.

[seandop]

For some reason the kernel has failed to communicate with the touch controller.

Could you try running sudo rmmod edt-ft5x06 and then sudo modprobe edt-ft5x06 which will retry the communication attempt? The touch controller reset line is controlled by the microcontroller on the display board via I2C, but that shouldn't be an issue as the driver has all documented required delays implemented.

This worked! Single tap, double-tap, and tap-and-hold are all working correctly on the desktop interface. Definitely a step in the right direction here.

[lurch]

Just for the sake of comparison, here's the dmesg result from my Pi 4 if I boot it up with nothing other than a power-supply and Touch Display attached:
dmesg.txt

[6by9]

As I've said, the driver delays by the documented time between having set the reset GPIO before trying to talk over I2C to the touch controller.

https://www.displayfuture.com/Display/datasheet/controller/FT5x06.pdf figure 3-8 shows Tpon, which is then listed as 300ms in table 3-5.
In the driver you have RESET_DELAY_MS defined as 300ms, and then when the GPIO is cleared we wait that period.

I've made a quick patch that extends that delay and see whether that helps in your case - raspberrypi/linux#6515
Once CI has completed in about 45mins, you should be able to run sudo rpi-update pulls/6515 to get that kernel and see if it helps. Normal guidance on not doing this with a critical Pi, or having backed everything up first.

[seandop]

Interestingly, that patch did not appear to help (sudo rpi-update did complete with no errors and I did a soft reboot, and then a hard reboot via pulling out the power cord afterwards). I still had to remove and re-add the kernel module after all of this to get it to function. I see that you extended the reset delay from 300 to 500 ms. I don't know if it'd be beneficial to try an absurdly long delay, just for the sake of experiment (like 5000 ms?)

[lurch]

Interestingly, that patch did not appear to help (sudo rpi-update did complete with no errors and I did a soft reboot, and then a hard reboot via pulling out the power cord afterwards).

Just to double-check, can you please report the output of uname -a ? Do you still see the identical messages about probe of 10-0038 failed with error -5 in dmesg?

[seandop]

uname -a reports the following:

Linux raspberrypi 6.6.63-v8+ #1 SMP PREEMPT Wed Dec 4 18:14:19 UTC 2024 aarch64 GNU/Linux

I do still receive that same probe failure message in dmesg. In addition, there's also edt_ft5x06 10-0038: supply iovcc not found, using dummy regulator earlier in the log. Is this relevant?

Edit: Nvm to the second log entry regarding the dummy regulator. I see that's in your dmesg, too.

[seandop]

I did re-flash the bootloader back to the "factory default" version, power cycled a few times (both soft and hard), and then flashed again with rpi-update pulls/6515 and power cycled a few times (both soft and hard) and still no luck. Removing and re-adding the kernel module still results in an immediate fix.