Skip to content

Add ESP32 env + bugfixes#28

Merged
jonasniesner merged 2 commits into
mainfrom
esp32
May 20, 2026
Merged

Add ESP32 env + bugfixes#28
jonasniesner merged 2 commits into
mainfrom
esp32

Conversation

@jonasniesner

Copy link
Copy Markdown
Member

No description provided.

@jonasniesner jonasniesner merged commit ceac02e into main May 20, 2026
1 check passed
@jonasniesner jonasniesner deleted the esp32 branch June 5, 2026 09:28
jonasniesner pushed a commit that referenced this pull request Jul 6, 2026
MJ-16: The compressed direct-write path emitted generic {0xFF, 0xFF} error
frames, so a failing command was unidentifiable. The published spec says error
frames are 0xFF followed by the command code ({0xFF, cmd}). Make the firmware
conform by setting the second byte to the failing command's low byte, matching
the existing {0xFF, 0x72} gray4 END frame.

Sites (src/display_service.cpp):
- handleDirectWriteCompressedData length-overflow guard -> {0xFF, 0x71} (DATA)
- handleDirectWriteCompressedData zlib-stream failure    -> {0xFF, 0x71} (DATA)
- handleDirectWriteStart decompressed-size mismatch      -> {0xFF, 0x70} (START)
- handleDirectWriteStart initial zlib-stream failure     -> {0xFF, 0x70} (START)
- handlePartialWriteStart zero logical-size guard        -> {0xFF, 0x76} (PARTIAL START)
- handleDirectWriteEnd compressed final-flush failure    -> {0xFF, 0x72} (END)

Backward-compatible with updated clients: py-opendisplay PR #120's
is_compressed_failure_frame() accepts both {0xFF, 0xFF} and {0xFF, 0x70} for the
compressed-START fallback, and the website direct-write handler (PR #28) treats
any leading-0xFF frame as an error.


Claude-Session: https://claude.ai/code/session_012g2e8mr132vcizx92WsgiR

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant