5 Commits

Include renames

Author	SHA1	Message	Date
tfaour	474b92a282	Add server-side support for a second panel (13.3in Spectra 6 / EE02) and scaffold its firmware target ... Server: Frame.panel_type (new column + migration) is auto-derived from the device's reported board (X-Frame-Board), never user-set -- the panel is a property of the hardware, not a picker in the UI. image_pipeline's packing/render pipeline is parameterized by panel geometry instead of hardcoded 800x480 globals, with the real confirmed 13.3in geometry (1600x1200) registered alongside the original 7.3in panel. Existing 7.3in frames are unaffected (column default + board mapping both resolve to the original panel). Board identifiers are also renamed (devkit/xiao -> devkit_esp32c6/ xiao_esp32c6, plus new "ee02") since the EE02 board also carries a XIAO module -- "xiao" alone stopped disambiguating hardware. The server keeps accepting the legacy bare names indefinitely for already-flashed devices. Firmware: scaffolds a third build target (ee02, ESP32-S3 -- a real chip-target change, not just a same-chip Kconfig variant like xiao) and a new epd13in3e driver component skeleton. The actual panel init/LUT/ refresh register sequence isn't ported from vendor demo code yet (none was available), so that component deliberately fails to compile (#error) rather than risk sending unverified register values to real hardware -- devkit/xiao are unaffected and build identically to before. CI's ee02 build step is continue-on-error for the same reason.	2026-08-04 20:08:22 +00:00
tfaour	ad1fa99064	Fix firmware release workflow: build against ESP-IDF v6.0, not v5.3 ... The build container was pinned to espressif/idf:release-v5.3, but the firmware is actually developed against v6.0.2 (this machine's $IDF_PATH). That gap caused real compile failures in CI -- esp_sleep_enable_gpio_wakeup_on_hp_periph_powerdown and ESP_NETIF_CAPTIVEPORTAL_URI are both newer than v5.3 has, plus a transitive stdbool.h include that changed between versions -- none of it a real bug in the source.	2026-07-21 21:41:36 -04:00
tfaour	ecc5b8d197	Fix firmware release workflow: docker cp instead of a bind-mount ... The runner's job workspace lives in a named Docker volume, not a real host path, so a nested docker run -v "\$PWD:/workspace" bind-mounted an empty directory when talking to the host daemon (which has no notion of paths inside the calling container) -- build_for_board.sh: No such file or directory. docker create/cp/start streams the checkout into the build container through the Docker API instead, which works regardless of what backs either side's workspace.	2026-07-21 21:35:30 -04:00
tfaour	9e630c0c6e	Fix firmware release workflow: run checkout outside the ESP-IDF container ... espressif/idf:release-v5.3 has no Node.js, and actions/checkout (a Node action) runs inside whatever container: the job specifies -- it failed immediately with "node: not found" on the first real run. Checkout now runs on the plain runner; only the two build steps spin up the ESP-IDF image themselves via docker run, using the runner's already-mounted docker socket.	2026-07-21 21:32:00 -04:00
tfaour	94d67f7767	Firmware CI releases + Gitea auto-update in the server ... New Gitea Actions workflow builds both board variants and publishes them as release assets whenever firmware/version.txt is bumped. The server can now poll that repo's releases (next to the existing manual upload) and either surface an "Update frame" button or, with "Automatically apply updates" checked, stage the new build itself -- the frame still only updates on its own next wake either way.	2026-07-21 19:25:08 -04:00