BOOT long-hold to power off (blocked: two hardware measurements first)

[iamankushpandit]

What

Hold the BOOT key for ~2 s and the console powers down; hold it again to
bring it back.

This is blocked on two hardware measurements, not on design. Both can be
answered in an evening, and if either comes back badly this issue should be
closed rather than implemented. Filing it so the reasoning is not re-derived.

The problem: there is no "off" on this board

There is no soft-power circuit. BoardProfile has no power-enable pin and the
E32R28T-1 does not wire one — the TP4054 charger feeds the rail directly. The
only true off is the physical switch or unplugging the cell.

So "off" can only mean esp_deep_sleep_start(), and that is a different
promise from the one the word makes.

Measurement 1 — what does deep sleep actually cost?

The datasheet's ~10 µA is for the ESP32 alone. On these boards the LDO, the
USB-UART bridge and the backlight circuit stay powered, and CYD-class boards
commonly measure in milliamps.

A "power off" that flattens the pack overnight is a promise to a parent that
the device then breaks. pio run -e batdiag exists precisely for this kind of
question and already reads the same battery profile the product does.

Specifically check the backlight. TFT_BL is GPIO21 on the E32R28T-1, and
GPIO21 is not an RTC GPIO on the ESP32 — it cannot be held during deep
sleep. It floats, and whether the panel actually goes dark depends on the
board's own pull. "The CPU stopped" is not the same claim as "the screen is off
and the current dropped".

Measurement 2 — does a held BOOT wake into the app, or into download mode?

GPIO0 is RTC-capable (RTC_GPIO11), so esp_sleep_enable_ext0_wakeup(GPIO_NUM_0, 0)
is available. But GPIO0 low at reset is the ROM's serial-download strap, and a
deep-sleep wake goes through a reset with the key still physically held.

If it lands in download mode, the device looks bricked to the owner and this
approach is dead on this board. Test it before writing anything.

If both come back clean

• ext0 fires on level, so any brush of the key wakes the chip. Wake with the
  panel still off, poll for the hold duration, and go straight back to sleep if
  it was a tap — that avoids paying displayWake()'s ~120 ms for every nudge.
• Deep sleep loses RAM, so "on" is a cold boot back to the profile picker, not
  resumeUnderlyingScreen(). Scores and settings are safe in NVS; an
  in-progress game is not. That is arguably correct for a real power-off, but it
  means the gesture ends the game — so it wants the hold-with-progress-bar
  idiom the lock screen already uses (src/engine/AppRuntimeLock.cpp), not a
  silent blackout.
• pollBootButton() (src/hal/BoardButton.cpp) deliberately does not time the
  press, and the runtime acts on the press edge. Both have to change
  together: you cannot go home on the press and also decide later that the same
  press was the start of a hold.

The fallback worth considering instead

If the measurements rule out power-off, long-hold → lock is the graceful
alternative. BrainoApp::lockAndSleepNow() already exists and already does the
right thing: a physical "put it away" key, none of the hardware risk.

Explicitly not this issue

Making the ordinary idle timeout use deep sleep. Wiring a wake source would
make that possible, but it would break the stated invariant that
resumeUnderlyingScreen() returns you to exactly the screen, profile and
orientation you left. Keeping touch-wake panel sleep for idle and letting only
this deliberate gesture lose state is the cleaner split — two mechanisms, two
honest promises.