31f05ab057 fix(touch): stop LONG_PRESS repeating when the suppression deadline wraps (#11829)
* fix(touch): stop LONG_PRESS repeating when the suppression deadline wraps

TouchScreenBase::_start was one field doing two incompatible jobs. It held the
press-down timestamp, and then the LONG_PRESS handler overwrote it with
`millis() + 30000` to stop the event repeating for the rest of the hold. Every read
was a hand-rolled signed subtraction on time_t, and suppression worked only because
`time_t(millis()) - _start` came out around -30000.

Where time_t is 64 bits - the portduino host - that uint32_t sum wraps to a small
number while millis() is still just under 0xFFFFFFFF. The subtraction then goes
hugely positive instead of negative, the threshold test passes on every 20ms poll,
and each pass re-arms to another wrapped value. It keeps firing until millis()
itself wraps, up to ~30 s later: about 1500 TOUCH_ACTION_LONG_PRESS events injected
into InputBroker for one finger that never moved. Modelling the old expression
across press-start offsets puts the worst case at exactly 1500 for a 60 s hold,
where three is correct. On a 32-bit time_t build the signed wrap happens to keep
suppressing, so this is host-and-variant dependent rather than universal.

The zero-dodging helpers in src/UptimeClock.h are no use here: they map 0 to 1, and
1 reads as "long ago" exactly as 0 does. The defect is the overload, not the zero,
so the field is split by what it is actually asked:

  _pressStartMs             a past event time - how long has the finger been down
  _longPressSuppressed      is repeat suppression armed
  _longPressSuppressUntilMs when it expires, read only while the bool is set

Two fields for the suppression rather than one, for the reason Throttle.h's
TODO(deadline-type) gives: armed has to stay a separate question from passed. No
single value can stand in for "unarmed" here either, since deadlinePassed() reads 0
as long past below ~24.8 days of uptime and as far future above it. Nothing new uses
0 as a sentinel, so bin/lint-unset-sentinel-millis.sh needs no entry.

All three comparisons now go through Throttle - hasElapsed() for the two
elapsed-since-press questions, which also buys the full ~49.7 day range that a
stored event time gets, and deadlinePassed() for the suppression window.

Behaviour is preserved deliberately, including the part that is easy to miss: the
old `+ 30000` made a held finger re-report LONG_PRESS once every 30 s, not once per
touch. A bool latch would have been simpler and quietly narrowed that, so the
window is kept as LONG_PRESS_REPEAT_SUPPRESS_MS. Old and new were compared across
five wrap scenarios and agree everywhere except the wrap window the old code got
wrong. The tap-on-release suppression the old write also provided is not needed: a
hold long enough to reach here has duration >= TIME_LONG_PRESS, so the tap branch
already takes its else and clears _tapped.

One guard added while here. The RAK14014 deferred-tap window is TIME_LONG_PRESS - 50
and that subtraction is unsigned now, so a variant lowering TIME_LONG_PRESS below 50
would underflow it into a ~49.7 day wait and the deferred TAP would never fire. The
only override in the tree is t5s3_epaper at 500; a static_assert fails the build
instead of the touch panel.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

* style(touch): trim comments to the house limit

---------

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>
Co-authored-by: nomdetom <nomdetom@protonmail.com>
2026-09-14 09:34:31 +00:00
2026-09-14 07:27:39 +00:00

Meshtastic Logo

Meshtastic Firmware

GitHub release downloads CI CLA assistant Fiscal Contributors Vercel

meshtastic%2Ffirmware | Trendshift

Overview

This repository contains the official device firmware for Meshtastic, an open-source LoRa mesh networking project designed for long-range, low-power communication without relying on internet or cellular infrastructure. The firmware supports various hardware platforms, including ESP32, nRF52, RP2040/RP2350, and Linux-based devices.

Meshtastic enables text messaging, location sharing, and telemetry over a decentralized mesh network, making it ideal for outdoor adventures, emergency preparedness, and remote operations.

Get Started

Join our community and help improve Meshtastic! 🚀

Stats

Alt

S
Description
No description provided
Readme GPL-3.0
324 MiB
0 Stars 1 Watchers 0 Forks
Languages
C++ 72.7%
C 23.1%
Python 2.1%
Shell 1.5%
Batchfile 0.2%
Other 0.2%