[Em3ritus]

Two board revisions ship under the one model number ESP32-2432S028, and only one of them
could run the published Vigil image.

• The classic micro-USB-only board (ESP32-2432S028R) is ILI9341.
• The later revision with a USB-C socket beside the micro-USB (the "CYD2USB") is ST7789.

The Vigil binds its panel driver at compile time, so cyd.bin only ever worked on the first kind.

The report

A user flashed the second kind and got a screen rotated 90 degrees with a band along one edge
never drawn. A video rules out the obvious causes: the UI renders coherently (fonts, sigils, the
two-column HOME grid, the yellow PAIR NEW NODE button, colours all correct) and touch still walks
the menus, so the firmware, the SPI link, the backlight and the XPT2046 are fine. Only the panel's
address mapping is wrong. A photo of the board settles the revision: two USB sockets.

What changed

Firmware. -DSIMULACRA_CYD_ST7789=1 selects esp_lcd_new_panel_st7789 (in-tree in ESP-IDF, no
new managed component) and drops the X mirror. Checked against DisplayConfig/CYD2USB/User_Setup.h
in witnessmenow/ESP32-Cheap-Yellow-Display:
every pin is identical, and so are the BGR element order, the 240x320 geometry, INVOFF and the
big-endian pixel order. The mirror is the one extra difference - TFT_eSPI writes MX|BGR into
MADCTL for an ILI9341 at rotation 0 but BGR alone for an ST7789, so keeping it would have given
mirror-written text.

Flasher. CI publishes a second image, firmware/cyd-st7789.bin. Both revisions identify as a
plain ESP32, so esp-web-tools cannot tell them apart, and handed two builds with one chipFamily
it would silently flash whichever came first. The page now asks which board you have, and
flash.js drops the build that does not match before anything is downloaded - and throws if two
builds for one chip ever survive the filter.

Docs. README hardware line and Recent updates, web/README.md board table, CHANGELOG.

Verification

• Both images build and merge under IDF v5.4, and each links only its own panel driver: 81
  ILI9341 references and no ST7789 in one, 62 ST7789 and no ILI9341 in the other.
• Each still carries the two SIMULACRA:CTRLSK blocks the browser patcher needs.
• Web suite green (36 tests, 1 skipped for unbuilt binaries), tools/tests green.
• Scripted browser run against the real page, serving the real images: for each choice exactly one
  ESP32 build survives, matching the pick, keyed ctrl_sk with both key blocks patched, every part
  a blob: URL; the flash button is withdrawn when the answer changes.

Not verified

No ST7789 board here, so that image is correct by construction and against the reference
config, not by having lit a panel.

One open question rides on the first field test. Nothing in this firmware sets the MADCTL MV bit,
so a 90 degree rotation is not something the ILI9341 driver asks for. The likely cause is that
driver's vendor init reaching a controller it was not written for - 0xB6 in particular, which
carries scan-direction bits and which the ESP-IDF ST7789 driver never sends at all. If that is
right, the clean ST7789 init clears the rotation by itself. If the panel is instead genuinely
transposed relative to the ILI9341 assumption, this image will also need swap_xy(true). Those two
are one reflash apart and cannot be told apart without the board.

Merging redeploys the flasher to Pages, which is what puts the image in front of the reporter to
settle it.

🤖 Generated with Claude Code