3 Commits

Include renames

Author	SHA1	Message	Date
tfaour	c0fefc19f1	Fix ee02 button-wakeup build: ext1 fallback for ESP32-S3 ... esp_sleep_enable_gpio_wakeup_on_hp_periph_powerdown() only exists on ESP32-C6 (SOC_GPIO_SUPPORT_HP_PERIPH_PD_SLEEP_WAKEUP), so the ee02 (ESP32-S3) build failed with implicit-declaration errors in {back,next,combo}_button.c once the epd13in3e driver's #error stopped masking it. Each button file now branches on that capability macro: the C6 path (devkit/xiao) is untouched, and ESP32-S3 uses esp_sleep_enable_ext1_wakeup_io() instead. The earlier ext1 attempt was rejected on C6 hardware because its pull resistor didn't hold across RTC_PERIPH power-down -- tracing the same path in ESP-IDF source shows gpio_config()'s pull_up_en already delegates to rtc_gpio_pullup_en() for RTC-capable pins on every non-original-ESP32 target, so the pull-up should already survive the same power-down on S3. The _io() variant is additive, so the three button files don't need cross-file mask coordination. Also widens the button GPIO Kconfig range for IDF_TARGET_ESP32S3 (0-21, matching its RTC-IO set) instead of the C6-shaped 0-7. Verified: ee02, devkit, and xiao all build clean end-to-end locally (native ESP-IDF v6.0, no Docker in this sandbox). NOT verified: whether this actually avoids the spurious-instant-wakeup bug on real EE02 hardware -- that failure mode was only ever confirmed empirically, not root-caused in a way a compile can check. continue-on-error stays on in CI's ee02 build step until that's confirmed.	2026-08-04 22:46:13 +00:00
tfaour	fcf3aec4c0	Move button actions to per-widget config, add hold-for-global-action ... Next/back button assignment moves from a frame-level "Button assignments" card into each widget's own gear-icon dialog, prefilled with a sane default at creation (photos/calendar -> advance/back, whiteboard/weather -> check_now, others -> none). At most one binding per (widget, button) now -- cross-widget execution order never mattered since each widget's action only touches its own state. New firmware capability: holding NEXT or BACK past a configurable duration (min 3s, server-side default) triggers a frame-wide action instead of the per-widget short-press one -- cycling saved layouts, refreshing all widgets, or freezing/unfreezing every photo widget (see app/global_actions.py). Firmware next/back checks gain the same hold-duration polling the combo button already had; the threshold comes from the previous wake's /frame/config fetch (persisted in NVS), since this wake's button decision happens before that request. Not done here: firmware/version.txt is intentionally left unbumped -- this hasn't been built or hardware-tested (no ESP-IDF toolchain in this environment), so no firmware release build should be triggered yet.	2026-07-27 22:09:33 +00:00
tfaour	3868d357ff	Add back-photo button; consolidate reset/manage onto one hold-duration button ... Back button (new GPIO0, POST /frame/back): the server now tracks a bounded history of previously-current photos (photo_queue.py), pushed to on every advance (auto or forced) and popped by back_forced() -- symmetric with advance, so pressing next afterwards returns to right where you were. frame_client.c's force_advance bool becomes a 3-way fetch_action_t (NORMAL/ADVANCE/BACK) threaded through the whole fetch path. Also folds the separate reset and manage buttons onto one pin (combo_button.c, replacing reset_button.c/manage_button.c entirely), disambiguated by hold duration: quick press shows the management menu (unchanged), ~3s hold-then-release soft-resets (esp_restart(), config kept -- new), ~15s hold factory-resets (today's old reset behavior, extended from 10s for clearer tier separation). Driven by a production board (Seeed XIAO ESP32-C6) exposing only 3 of the ESP32-C6's 8 deep-sleep-wakeup-capable GPIOs -- next/back keep their own dedicated pins where instant response matters most, everything else shares the third pin via timing instead of needing its own. Same three-pin layout now works on both the dev board and the production board. Fixed a fast-tap bug in combo_button_check() before shipping: it only did a live gpio_get_level() read to decide whether the button was pressed at all, so a press fast enough to already be released by the time boot reached that check was missed entirely (treated as "never pressed" rather than "quick press"). Added the same latched esp_sleep_get_gpio_wakeup_status() check the other buttons already use for exactly this reason.	2026-07-19 12:53:26 -04:00