3 Commits

Include renames

Author	SHA1	Message	Date
tfaour	e870898490	Refine manage overlay: US/CAN state abbreviations, share-QR caption, and an escalating second menu with named-face labels ... Two rounds of follow-up work on the manage-button overlay: 1. Location formatting: US/Canada now show abbreviated state/province ("CA", "ON") instead of the full name, other countries show the full country name, and each is its own line (was one line, now wraps to two) so longer international place names have more room without threatening to overlap the top-right QR box. The bottom-left share QR also gets a "SCAN TO DOWNLOAD" caption. 2. Escalating menu: pressing the manage button again while its overlay is already up adds a second level -- each Immich-identified person's name labeled next to their face in the photo (using Immich's own face recognition/People data, no detection/recognition added to this project). A third press exits immediately instead of waiting out the 30s auto-revert timer. No new Immich API needed -- GET /api/faces already embeds a nullable person.name per face; new server/app/face_labels.py maps a named face's box into the final 800x480 frame's pixel space (reusing crop-box math extracted from image_pipeline.py's face-aware cropping). Capped at 4 named faces, sized to a real firmware RAM budget: each label is its own malloc'd overlay region on the device, alongside the 4 fixed corner regions already in use. New GET /frame/face-labels returns a flattened fixed-slot JSON shape (not a real array) so firmware's existing flat-scalar parser can read it without needing an actual array parser. No persistent state needed for the escalation itself -- it's all local control flow within one continuous awake session (frame_client.c's run_management_menu()).	2026-07-19 09:09:06 -04:00
tfaour	a358045cea	Fix "Show next" staleness bug; add location/date/share-QR to manage overlay ... Two changes, bundled since they landed in the same session and touch overlapping files: 1. Fix: "Show next" sent the browser's full queue snapshot to POST /api/queue/reorder, which hard-rejected if the server's queue had shifted since the last fetch (e.g. right after a queue-length trim). New POST /api/queue/promote moves one photo to the front authoritatively, with no dependency on client staleness. /reorder itself is now tolerant too -- unrecognized IDs are dropped and missing ones appended, instead of rejecting the whole request. 2. Feature: the manage button's overlay now also shows the photo's location (top-left, only if Immich reverse-geocoded it from GPS EXIF), the date it was taken (bottom-right), and a QR code (bottom- left) linking to a 30-minute public Immich share link -- created lazily when someone actually scans it, not when the button's pressed. New server endpoints GET /frame/photo-info and GET /frame/share/{asset_id} (scoped to the frame's current/queued photos, not any arbitrary Immich asset). Firmware-side, the overlay mechanism generalizes from one spliced region to up to four (manage_qr_overlay.c), each its own small buffer, still never holding the full frame in RAM.	2026-07-19 01:28:25 -04:00
tfaour	f74085cedf	Add third button: "scan to manage" QR overlay on the current photo ... Pressing the manage button (GPIO1) overlays a small QR code -- "SCAN TO MANAGE" -- in the top-right corner of whatever photo is currently on screen, linking to the server's config page, then reverts to the plain photo after 30 seconds. The overlay is spliced into the existing streaming fetch as chunks pass through (frame_client.c's http_read_fn), rather than buffering the full 192,000-byte frame in RAM: only the small overlay rectangle itself (~30KB) is ever held in memory, generated via new stride-parameterized drawing helpers (epd_draw_*_ex in epd_draw.c) that let the existing QR/text drawing code target an arbitrarily-sized buffer instead of a full-frame one. epd7in3e.c is untouched -- it has no idea an overlay exists.	2026-07-19 00:50:07 -04:00