This is a write-up about a problem and solution that might affect other devs using a PiTFT Plus.
I've been developing a project involving a Raspberry Pi 5 running Bookworm Lite and running pygame to display graphics on a PiTFT Plus. So far, it's gone well, but touch input has been tricky. The pygame touch interface is poorly developed, so I've been using evdev, which has been much more reliable.
One issue that I've been trying to track down is the occasional unresponsiveness of the touchscreen to touch input, even though LCD output is fine. Whenever that has occurred, I've noticed that the problem persists until I reboot - sometimes more than once - and then the touchscreen is responsive again. I tried various ways of tracking it down, including capturing and comparing dmesg output to see if an error message was occurring on the problematic boot cycles, but nothing came up.
Today, I figured out the problem. I was using evdev to grab /dev/input/event3 , but during a cycle where touch input wasn't working, I found a way to check what that device was connected to (by examining evdev.InputDevice('/dev/input/event3').info) and was surprised to find it mapped to hdmi0. Meanwhile, the chip for the PiTFT was mapped to /dev/input/event6. Further experimentation revealed that the mapping of the PiTFT Plus touch input was mapped arbitrarily to different event streams on each boot cycle. Huh.
Some comments from years ago (2021 and earlier) revealed that a lot of people instead read from /dev/input/touchscreen, which I presume was consistently mapped to touch input instead of randomly-selected /dev/input/event_ devices, but it looks like Raspberry Pi OS has done away with that mapping.
Based on this discovery, I found that examining the .info.bustype of all of the input devices revealed only one that was set to const 24, which appears to correspond to the touchscreen chip. So this logic works for now:
...followed by reading and handling events from touch.read(). It's not graceful, but it appears to work consistently.
I've been developing a project involving a Raspberry Pi 5 running Bookworm Lite and running pygame to display graphics on a PiTFT Plus. So far, it's gone well, but touch input has been tricky. The pygame touch interface is poorly developed, so I've been using evdev, which has been much more reliable.
One issue that I've been trying to track down is the occasional unresponsiveness of the touchscreen to touch input, even though LCD output is fine. Whenever that has occurred, I've noticed that the problem persists until I reboot - sometimes more than once - and then the touchscreen is responsive again. I tried various ways of tracking it down, including capturing and comparing dmesg output to see if an error message was occurring on the problematic boot cycles, but nothing came up.
Today, I figured out the problem. I was using evdev to grab /dev/input/event3 , but during a cycle where touch input wasn't working, I found a way to check what that device was connected to (by examining evdev.InputDevice('/dev/input/event3').info) and was surprised to find it mapped to hdmi0. Meanwhile, the chip for the PiTFT was mapped to /dev/input/event6. Further experimentation revealed that the mapping of the PiTFT Plus touch input was mapped arbitrarily to different event streams on each boot cycle. Huh.
Some comments from years ago (2021 and earlier) revealed that a lot of people instead read from /dev/input/touchscreen, which I presume was consistently mapped to touch input instead of randomly-selected /dev/input/event_ devices, but it looks like Raspberry Pi OS has done away with that mapping.
Based on this discovery, I found that examining the .info.bustype of all of the input devices revealed only one that was set to const 24, which appears to correspond to the touchscreen chip. So this logic works for now:
Code:
device_number = Nonefor i in range(0, 10): try: d = evdev.InputDevice(f'/dev/input/event{i}') if d.info.bustype == 24: device_number = i break except: passif device_number is not None: touch = evdev.InputDevice(f'/dev/input/event{device_number}') touch.grab()Statistics: Posted by sfsdfd — Sun Jan 12, 2025 2:36 am