Summary
The jd79665_750_bwry panel entry (id 1011, GDEM075F52 / JD79665AA controller) never produces any visible response - no flicker, no partial refresh, nothing - when driven from a Seeed XIAO ESP32-S3-based board (TRMNL 7.5" OG DIY Kit). All configurable fields (pins, driver, resolution, color scheme, power) have been triple-checked against the Toolbox UI, the exported JSON, and the raw protocol YAML spec, and are correct. The most likely remaining cause is a hardcoded busy-pin polarity assumption in the driver that isn't exposed as a configurable field.
Hardware
Board: Seeed XIAO ESP32-S3-based TRMNL 7.5" OG DIY Kit
Panel: Waveshare GDEM075F52 (JD79665AA controller, 800x480, B/W/R/Y)
Pins (confirmed working under ESPHome, see below): reset=38, busy=4, dc=10, cs=44, clk=7, data=9
Config used
No TRMNL-specific board preset exists in the Toolbox, so I started from the Seeed EE04 preset and manually corrected every pin field to match this board's actual wiring. Verified three times, at three different levels:
Toolbox UI (screenshot of filled-in display packet fields)
Exported/re-imported JSON, decoded byte-by-byte against the packet layout
The raw ble_proto YAML spec itself, to confirm display (packet 32) genuinely has no busy-pin-invert field anywhere in the protocol (only binary_inputs, i.e. buttons, has an invert bitfield - unrelated to the display)
Also found and fixed a real inconsistency left over from the EE04 preset: device_flags bit 0 (pwr_pin - "device has external power management for display etc.") was still set while the actual pwr_pin value was 0xFF (not present). Cleared that flag since this board has no separate power-enable GPIO. Did not resolve the issue on its own.
Symptom
Config reads back correctly after write (Canvas size set from device: 800x480, Color scheme automatically set to: B/W + Red + Yellow (3)), but sending a test image always fails:
PIPE_WRITE probe: START compressed=true total=96000B
No PIPE_WRITE START response within timeout; falling back to legacy direct write
Error sending to display: Direct write ack timeout (start)
No flicker at all on the panel. The device sometimes stops accepting new BLE connections afterward until power-cycled.
Experimental confirmation (busy-pin polarity)
I have this exact panel working reliably under ESPHome, using tsunglung/esphome_epaper as the display driver. Getting it to work required two non-default settings:
yaml
busy_pin:
number: GPIO4
inverted: true
reset_pin: GPIO38
reset_duration: 200ms # default (200ms is actually the documented default; a different implicit value in this firmware may differ)
To isolate the variable, I removed only inverted: true (everything else identical - same board, same pins, same panel) and reflashed. Result: the display goes completely unresponsive, no flicker at all - the exact same symptom seen on OpenDisplay. Restoring inverted: true immediately fixes it again. This strongly suggests the OpenDisplay firmware's jd79665_750_bwry driver has a hardcoded busy-pin polarity assumption that doesn't match this board's actual signal.
Possible root cause: board reference mismatch
Digging into TRMNL's own official firmware (usetrmnl/trmnl-firmware), the Seeed XIAO ESP32-S3 "OG DIY Kit" is defined as its own distinct board type (BOARD_XIAO_EPAPER_DISPLAY / BOARD_XIAO_EPAPER_DISPLAY_3CLR) - there is no 4-color (BWYR) board definition for it at all. The only 4-color board (BOARD_TRMNL_4CLR, using bb_epaper panel EP75YR_800x480) targets a completely different board (the original ESP32-C3 TRMNL, not the Seeed ESP32-S3 XIAO kit). It's plausible the jd79665_750_bwry panel entry was only ever validated against that ESP32-C3 reference design, and this exact combination (Seeed XIAO ESP32-S3 + 4-color GDEM075F52) has simply never been tested anywhere - not a misconfiguration on my end.
Ask
Is there a way to override busy-pin polarity that I'm missing, anywhere in the protocol/firmware?
If not, could jd79665_750_bwry (or panel entries generally) get a configurable busy-pin-invert option, similar to what binary_inputs already has for buttons?
Alternatively, if this driver was indeed only validated against the ESP32-C3 BOARD_TRMNL_4CLR reference, a note in the Toolbox about which reference board a panel entry was tested against would help others avoid the same trial-and-error.
Happy to provide additional logs, the exported JSON config, or test further changes if that helps narrow this down.
Summary
The jd79665_750_bwry panel entry (id 1011, GDEM075F52 / JD79665AA controller) never produces any visible response - no flicker, no partial refresh, nothing - when driven from a Seeed XIAO ESP32-S3-based board (TRMNL 7.5" OG DIY Kit). All configurable fields (pins, driver, resolution, color scheme, power) have been triple-checked against the Toolbox UI, the exported JSON, and the raw protocol YAML spec, and are correct. The most likely remaining cause is a hardcoded busy-pin polarity assumption in the driver that isn't exposed as a configurable field.
Hardware
Board: Seeed XIAO ESP32-S3-based TRMNL 7.5" OG DIY Kit
Panel: Waveshare GDEM075F52 (JD79665AA controller, 800x480, B/W/R/Y)
Pins (confirmed working under ESPHome, see below): reset=38, busy=4, dc=10, cs=44, clk=7, data=9
Config used
No TRMNL-specific board preset exists in the Toolbox, so I started from the Seeed EE04 preset and manually corrected every pin field to match this board's actual wiring. Verified three times, at three different levels:
Toolbox UI (screenshot of filled-in display packet fields)
Exported/re-imported JSON, decoded byte-by-byte against the packet layout
The raw ble_proto YAML spec itself, to confirm display (packet 32) genuinely has no busy-pin-invert field anywhere in the protocol (only binary_inputs, i.e. buttons, has an invert bitfield - unrelated to the display)
Also found and fixed a real inconsistency left over from the EE04 preset: device_flags bit 0 (pwr_pin - "device has external power management for display etc.") was still set while the actual pwr_pin value was 0xFF (not present). Cleared that flag since this board has no separate power-enable GPIO. Did not resolve the issue on its own.
Symptom
Config reads back correctly after write (Canvas size set from device: 800x480, Color scheme automatically set to: B/W + Red + Yellow (3)), but sending a test image always fails:
PIPE_WRITE probe: START compressed=true total=96000B
No PIPE_WRITE START response within timeout; falling back to legacy direct write
Error sending to display: Direct write ack timeout (start)
No flicker at all on the panel. The device sometimes stops accepting new BLE connections afterward until power-cycled.
Experimental confirmation (busy-pin polarity)
I have this exact panel working reliably under ESPHome, using tsunglung/esphome_epaper as the display driver. Getting it to work required two non-default settings:
yaml
busy_pin:
number: GPIO4
inverted: true
reset_pin: GPIO38
reset_duration: 200ms # default (200ms is actually the documented default; a different implicit value in this firmware may differ)
To isolate the variable, I removed only inverted: true (everything else identical - same board, same pins, same panel) and reflashed. Result: the display goes completely unresponsive, no flicker at all - the exact same symptom seen on OpenDisplay. Restoring inverted: true immediately fixes it again. This strongly suggests the OpenDisplay firmware's jd79665_750_bwry driver has a hardcoded busy-pin polarity assumption that doesn't match this board's actual signal.
Possible root cause: board reference mismatch
Digging into TRMNL's own official firmware (usetrmnl/trmnl-firmware), the Seeed XIAO ESP32-S3 "OG DIY Kit" is defined as its own distinct board type (BOARD_XIAO_EPAPER_DISPLAY / BOARD_XIAO_EPAPER_DISPLAY_3CLR) - there is no 4-color (BWYR) board definition for it at all. The only 4-color board (BOARD_TRMNL_4CLR, using bb_epaper panel EP75YR_800x480) targets a completely different board (the original ESP32-C3 TRMNL, not the Seeed ESP32-S3 XIAO kit). It's plausible the jd79665_750_bwry panel entry was only ever validated against that ESP32-C3 reference design, and this exact combination (Seeed XIAO ESP32-S3 + 4-color GDEM075F52) has simply never been tested anywhere - not a misconfiguration on my end.
Ask
Is there a way to override busy-pin polarity that I'm missing, anywhere in the protocol/firmware?
If not, could jd79665_750_bwry (or panel entries generally) get a configurable busy-pin-invert option, similar to what binary_inputs already has for buttons?
Alternatively, if this driver was indeed only validated against the ESP32-C3 BOARD_TRMNL_4CLR reference, a note in the Toolbox about which reference board a panel entry was tested against would help others avoid the same trial-and-error.
Happy to provide additional logs, the exported JSON config, or test further changes if that helps narrow this down.