touch: retry + hard-reset when FT5426 boots into wedged 0xff state

After a long bench session of taps + power cycles, the FT5426 on this
unit started returning dev_mode=0xff on every read. The polling loop
interpreted that as 15 simultaneous touches forever (td_status bits
0..3 all set), wedged `was_down=true` permanently, and no tap or
long-press ever fired — the screen looked dead.

Two layers of defence in touch_init:
  1. retry the dev_mode read up to 10 × 30 ms in case the chip is just
     slow to come up after PC_RST_TP_N is released.
  2. if still stuck, pulse PC_RST_TP_N via a new
     display_touch_reset_pulse() helper (drop reset for 20 ms then
     release + 50 ms settle), then retry the read another 10 × 30 ms.

Plus a polling-loop sanity check: an FT5x06 supports max 5 simultaneous
points, so a TD_STATUS lower-nibble value > 5 is bogus and the poll
cycle is skipped. That keeps a wedged chip from producing phantom
"15 touches" reports if it slips into 0xff during runtime.

If both attempts still report 0xff, we log loudly and let the polling
task run — it harmlessly drops cycles via the >5 sanity check. Wake
still works via POST /state from Scrypted; this only disables touch
gestures on a hardware-stuck boot.

1 files changed, 5 insertions, 0 deletions

diff --git a/main/display.h b/main/display.h
index 9092efb..cb2b913 100644
--- a/main/display.h
+++ b/main/display.h
@@ -27,6 +27,11 @@ esp_err_t display_set_brightness(uint8_t brightness_0_100);
 esp_err_t display_sleep(void);
 esp_err_t display_wake(void);
 
+// Pulse the touch IC's reset line (PC_RST_TP_N) via the panel MCU. Used
+// by touch_init() when the FT5426 boots into a wedged state and refuses
+// to leave dev_mode=0xff.
+esp_err_t display_touch_reset_pulse(void);
+
 // Blit an RGB565 source image to the panel, applying the current
 // orientation. Source dimensions must match the effective resolution:
 //   portrait  -> src is 480x800 (rotated 90° CW into the 800x480 panel)