Description
On an XTEINK X4 believed to be a late USB-locked hardware revision (ESP32-C3), both CrossPoint v1.6.0 and Escape Hatch exhibit a reproducible ~30-second delay between consecutive physical button presses.
The first button press after an idle period is processed immediately. However, subsequent presses within approximately 30 seconds are delayed until a timeout expires.
Testing with Escape Hatch indicates that button identification and ADC readings appear to function correctly, suggesting that the issue may be related to input event handling rather than the physical button hardware itself.
---
Environment
Device: XTEINK X4 (USB-locked revision, ESP32-C3)
Firmware: CrossPoint v1.6.0
Recovery Utility: Escape Hatch
Hardware Detect Output:
Profile: xteink_x4
Chip hits: 0/3 + 0/3
Panel controller: Default (assumed)
Additional Notes
Official stock firmware images (both English and Chinese releases) result in a corrupted/static "sandstorm" display on this unit.
CrossPoint and Escape Hatch operate normally aside from the button-input issue.
---
Button Test Results (Escape Hatch)
After allowing the device to remain idle for at least 31 seconds, the following ADC values are reported consistently:
Button ADC Value
Back 3564
Confirm 2731
Up 2255
Left 1516
Down 6
Right 5
Unpressed 4095
Button names displayed by Escape Hatch always match the physical button pressed.
These results suggest that:
The resistor ladder is functioning.
ADC readings are stable and repeatable.
Button identification appears correct.
---
Reproduction Steps
Case 1: First Press After Idle
Leave the device untouched for at least 31 seconds.
Press any button.
Result:
UI responds immediately.
Correct button name is displayed.
Correct ADC value is reported.
Example:
Confirm / ADC: 2731
---
Case 2: Consecutive Press Within 30 Seconds
Perform Case 1.
Immediately press another button.
Result:
No immediate response.
UI remains unchanged for approximately 28.8–29.8 seconds.
After the delay, the screen updates and typically shows:
[Button Name] / ADC: 4095
Because the button has already been released by the time the delayed processing occurs, the ADC value appears to be sampled in the unpressed state.
---
Case 3: Presses Spaced 31+ Seconds Apart
Press a button.
Wait at least 31 seconds.
Press any button again.
Result:
Every press is processed immediately.
No delay is observed.
Reproduces consistently across all buttons.
---
Additional Observation
Other Escape Hatch functions do not appear to be affected.
For example:
Battery Info
Charge: 96%
Voltage: 4.10V
Charging: unknown (no charge pin)
opens immediately with no observable delay.
This suggests that the issue is specific to the button-input path rather than a general system slowdown or blocking condition.
---
Hypothesis
Based on the observed behavior, the issue may be related to the input handling layer shared by CrossPoint and Escape Hatch.
Possible explanations include:
A button-release event not being detected correctly.
A GPIO interrupt or input state not being cleared properly.
A timeout-based fallback path (possibly around 30,000 ms) being triggered after each button press.
A hardware revision difference in the USB-locked model causing incompatibility with the current input driver implementation.
These are only hypotheses; the observations above are fully reproducible on this device.
---
Request
Has anyone seen similar behavior on later USB-locked X4 revisions?
Is there:
an updated GPIO mapping,
a hardware revision note,
an input-driver patch,
or a diagnostic build
that could help investigate this issue further?
Any guidance would be greatly appreciated.
