3 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	c4cd9b73e8	Invalidate the tracked display CRC when a non-photo screen is drawn ... The QR onboarding and "CONNECTING..." status screens write to the panel through a separate path that never touched the last-displayed-photo CRC added in the previous commit. That left it stale relative to what's actually on screen after either one draws -- most visibly after a factory reset: reprovisioning and reconnecting could fetch a photo whose CRC happened to match the one from before the reset, skip the refresh, and leave the QR code frozen on screen indefinitely. Both screens now invalidate the tracked CRC right after drawing, so the next photo fetch is always guaranteed to actually refresh.	2026-07-18 23:59:48 -04:00
tfaour	a518cbdbaf	Add post-connect status screen with WiFi/server checklist ... After a successful home WiFi connect, frame_client_run() now redraws the panel as a two-row checklist (WiFi row with a checkmark, server row) so the connection sequence is visible on-device rather than only in serial logs. Refreshes once with the server row pending, probes the tools server with a plain HTTP HEAD (any response, even 404, confirms the socket-level connection works -- there's no real server yet), then refreshes again with the final result. Two refreshes rather than one to actually show staged progress, at the cost of the extra refresh time inherent to this panel. Also fixes a second hardware-verified bug in the same area: on a failed STA connect falling back to provisioning, wifi_init_softap()'s esp_wifi_init() call was aborting with ESP_ERR_INVALID_STATE, because frame_wifi_connect_sta() only stopped the WiFi driver on failure rather than fully deinitializing it (and destroying the STA netif) before handing back control.	2026-07-18 14:08:19 -04:00