Portrait mode on the parallel RGB panels driven by ESP32-S3 and ESP32-P4 boards gets cheaper in ESPHome. Pull request #20905 by Hasan Khalil (gongloo), merged into the development branch on 16 October 2026 at 23:39 UTC by clydebarrow, changes how the mipi_rgb display driver handles rotation. It is due in ESPHome 2026.11, and existing YAML does not need to change.

Where the memory went

RGB panels on these chips scan horizontally along the ribbon cable, and their controllers have no MADCTL register that could swap the axes in hardware. So mipi_rgb told LVGL it had no hardware rotation. With rotation: 90 or 270, LVGL then allocated an intermediate rotation buffer in PSRAM (typically 96 KB to 768 KB), transposed the pixels into it, and copied them once more into the scanout framebuffer. Every redraw crossed the PSRAM bus three times.

In ESPHome, LVGL's draw buffer defaults to the full frame. On an 800x480 panel in RGB565 that is 768 KB, and rotation added another 768 KB next to the draw buffer and the scanout buffer, about 2.3 MB of PSRAM in total.

One pass instead of three

The driver now gets the panel's DMA framebuffer from ESP-IDF and writes rotated pixels straight into it in one pass, for 0°, 90°, 180° and 270°. For 90° and 270° it writes sequentially, so PSRAM cache lines fill one after another. It also reports hardware rotation to LVGL, which hands rotation to the driver and never creates its own buffer.

A default setup gets 768 KB of PSRAM back. The author also measured a tuned case on an ESP32-S3 CrowPanel 5.0" (800x480 RGB TFT, octal PSRAM) with buffer_size: 12.5%:

  • peak render time fell from 193.4 ms to 125.1 ms, and the average from 24.3 ms to 17.8 ms;
  • the 96 KB rotation buffer disappeared, and free PSRAM grew from 5,575 KB to 5,669 KB.

Configs that draw with a display lambda: or pages: rather than LVGL keep their off-screen back buffer, allocated on the first draw, so they stay flicker-free. LVGL-only configs never allocate it.

The change builds on #20752 and #20757, which stopped ESPHome from applying axis transforms that these pure RGB panels do not have but left them on the slow software path. The it8951 e-paper driver already used the same direct approach.

Who will notice

Mostly people who run an RGB panel in portrait orientation with LVGL. The freed PSRAM can go to images, fonts or audio buffers on the same board, and on the author's panel the slowest redraws got about a third faster.