[Pironman5 Pro Max] TFT display shows white screen — no TFT support found in pironman5 1.3.7

[sk-cmd-saka]

Hello,

I recently set up a Pironman5 Pro Max with Raspberry Pi 5 and Raspberry Pi OS (Bookworm, 64-bit), and the TFT display remains white at all times.

Environment:

• Hardware: Pironman5 Pro Max
• SBC: Raspberry Pi 5
• OS: Raspberry Pi OS Bookworm 64-bit
• pironman5 version: 1.3.7 (installed via official install script)

What I confirmed:

• The TFT is detected as a display by the system
• Touch input from the TFT is recognized
• OLED is working correctly
• SPI is enabled in /boot/firmware/config.txt (dtparam=spi=on)
• pironman5 service is active and running
• No errors in systemctl status pironman5

What I found:
Searching the installed source files, there appears to be no TFT-related code in pironman5 1.3.7:

grep -r "tft\|TFT\|lcd\|LCD" /opt/pironman5/ --include="*.py" -l

No pironman5-specific files were returned.

Also, the latest release on GitHub appears to be 1.2.21, while the install script installed 1.3.7 — could this be a pre-release or development version?

Question:
Is TFT display support planned or currently under development for Pironman5 Pro Max? Is there any additional configuration or package required to enable it?

Thank you!

[Renton776]

@saka — adding a deep dive on this. TL;DR up top, evidence below.

TL;DR

• install.py (branch pro-max, HEAD 5f83b6a, dated 2026-04-15) does NOT effectively modify /boot/firmware/config.txt — the setup_config_txt() mechanism exists but is a no-op because the relevant settings dict is commented out (details below)
• The sunfounder-pironman5promax.dtbo shipped with the install does NOT configure DSI — only I2C, SPI, GPIO IR receiver, and PWM fan (decompiled fragment list below)
• The 4.3" panel is intended to be auto-detected via EDID over I2C with display_auto_detect=1 (Pi OS default). Confirmed by CNX Software's professional review of the Pro Max
• Three distinct failure modes are being conflated across issues Pironman 5 pro max with 4.3" screen that will not power on. #54, [Pironman5 Pro Max] TFT display shows white screen — no TFT support found in pironman5 1.3.7 #60, and forum threads #4460 / #4618 — table below

Source verification

install.py modifies config.txt? Effectively no.

# install.py:54-58 (branch pro-max @ 5f83b6a)
# 'config_txt': {
#     'dtparam': ['i2c_arm=on', 'spi=on'],
#     ...
# },

The config_txt settings dict is commented out at lines 54-58. As a result, when sf_installer.setup_config_txt() (defined at tools/sf_installer.py:569, called at tools/sf_installer.py:720) runs, it returns early because the internal self.config_txt dict is empty. The function executes on every install but is a no-op.

Empirically: no .bak of config.txt is created during install, and display_auto_detect=1 remains untouched on a fresh Pi OS Bookworm install.

sunfounder-pironman5promax.dtbo configures DSI? No.

Decompiled with dtc -I dtb -O dts /boot/firmware/overlays/sunfounder-pironman5promax.dtbo, the fragments are:

fragment@0  → target = <&i2c1>          /* I2C bus 1 */
fragment@1  → target = <&spi0>          /* SPI */
fragment@2  → target-path = "/" ... fan /* PWM fan node */
fragment@3  → target = <&rp1_pwm1>      /* PWM controller */
fragment@4  → target-path = "/" ... ir-receiver@d  /* gpio-ir-receiver, GPIO 13 */
fragment@5  → target-path = "/" ... gpio_ir_pins@d /* IR receiver pin config */

No DSI fragment, no panel, panel-dsi, simple-panel, or backlight node. So even if a user adds dtoverlay=sunfounder-pironman5promax to config.txt (which the install script does NOT do), it has zero effect on the 4.3" DSI panel.

None of the variants under pironman5/variants/ include DSI/panel/TFT/touchscreen/backlight entries either:

grep -rn -iE "dsi|panel|tft|touchscreen|backlight|display" pironman5/variants/
# → 0 matches

External validation of the intended behaviour

CNX Software's review (April 2026): https://www.cnx-software.com/2026/04/18/pironman-5-pro-max-review-a-raspberry-pi-5-tower-pc-case-with-integrated-video-and-audio-capabilities-ups-kit/

"I hadn't changed anything in the OS configuration so far, and the display worked out of the box with touchscreen function."

So design intent is confirmed: panel auto-detected via EDID, no manual overlay needed.

Failure mode taxonomy

Three distinct symptoms across the open threads. Lumping them together slows diagnosis:

Mode	Symptom	Reported in	Most likely cause
A	Backlight flashes briefly, then off, no touch	#54	FPC cable seating, or USB-PD power negotiation
B	Backlight ON, white screen, touch works	#60 (this), forum #4618	Panel powered + touch IC init OK, display controller init incomplete
C	Fully black, no backlight, no touch	forum #4460 (some reports)	display_auto_detect=0, or wrong manual dtoverlay loading wrong panel driver

For mode B (this issue): EDID auto-detection is partial — backlight power rail ON (white = lit panel without image data), touch IC at I2C 0x38 fully initialized, but the display controller's init sequence isn't being applied.

Diagnostic checklist

# 1. config.txt sanity
grep -nE "^[# ]*display_auto_detect|dtoverlay|dtparam" /boot/firmware/config.txt

# 2. Kernel DSI state
kmsprint | grep -A 3 DSI
ls /sys/class/backlight/ 2>/dev/null
ls /dev/fb*

# 3. Wayland compositor view
wlr-randr

# 4. I2C devices on the panel bus
sudo i2cdetect -y 11    # expected: 0x38 (touch FT5x06, "UU"=kernel-claimed), 0x45 (backlight, "UU"=kernel-claimed)
sudo i2cdetect -y 1     # expected: 0x3c (OLED, free)

# 5. Kernel logs for panel/dsi/backlight events
dmesg | grep -iE "dsi|panel|backlight|simple-framebuffer" | tail -40

# 6. Service health (sanity check)
sudo systemctl status pironman5.service --no-pager | head -15

Expected outputs on a working setup:

• display_auto_detect=1 uncommented in config.txt
• No dtoverlay=vc4-kms-dsi-* or panel-related lines
• kmsprint lists Connector 0 (36) DSI-2 (connected) at 800x480@60Hz
• /sys/class/backlight/11-0045/ exists, brightness matches max_brightness
• wlr-randr shows DSI-2 enabled at 800x480
• i2cdetect -y 11 shows 38 and 45 (both as UU)
• i2cdetect -y 1 shows 3c
• /dev/fb1 exists and is drm-rp1-dsidrmf
• dmesg shows the panel driver attaching cleanly

Anti-patterns observed in the wild

These appear in user attempts (some borrowed from generic DSI troubleshooting blogs) but DON'T fix the Pro Max panel and can break working setups:

- # display_auto_detect=1                          # disabling this breaks EDID-based auto-detection
- dtoverlay=vc4-kms-dsi-waveshare-panel,4_0_inch   # wrong panel driver, sends incompatible init seq
- dtoverlay=sunfounder-pironman5promax             # has no effect on DSI (see decompiled fragments above)

If any of these are present in config.txt, removing them and ensuring display_auto_detect=1 is active is step 1.

Asks for @saka and others on this thread

If anyone hitting the white-screen failure mode could share the output of the diagnostic checklist above (especially items 2, 4, and 5), it would help confirm whether this is:

• a config.txt issue (manual overlay residue from earlier troubleshooting)
• a kernel/firmware regression in panel driver attach
• something hardware-specific (FPC ribbon batch, panel revision)

I'll cross-reference findings here.

---

For what it's worth: setup is fully functional on my side now — DSI + touch + OLED + fans + RGB all working. 🍺

[sk-cmd-saka]

@Renton776

Thank you for your detailed analysis.
It is possible that the monitor, not the system, is malfunctioning.
We are currently preparing a new monitor and FPC cable.

Before reinstalling the OS, please check the following:
Should I use Raspberry Pi OS Bookworm (Debian 12)?
Or is Trixie (Debian 13) also supported?
Does display_auto_detect=1 work correctly?

[sk-cmd-saka]

This issue was caused by a malfunction in the monitor, and no changes were required to the code itself. Thank you for your confirmation.