Deferred / late initialization of display components

[theNorr]

Component name

display

Link to component documentation on our website

https://esphome.io/components/display/

Describe the enhancement

Add an opt-in option to defer the setup/init of display components until the system is fully up and running (or until a defined “system ready” point), instead of initializing displays during early boot.

This would significantly improve stability for displays without an exposed RESET pin and for DSI / RGB / parallel displays that are sensitive to power-up timing and MCU reset behavior.

Use cases

I would like a way to defer the setup/initialization of display components until the system has reached a later, more stable phase.

Conceptually:

• The display component is still declared normally.
• However, its setup() (and therefore the display controller initialization) is deferred.
• Initialization occurs only after the rest of the system is up and running (e.g. after all other components have completed setup).

This would allow the display controller to see:

• a stable power and clock environment,
• a settled MCU state,
• avoid initialization during early boot or reset transitions.

This would significantly improve reliability for:

• displays without reset pins,
• repurposed consumer hardware, RGB / DSI / parallel display controllers (e.g. ST77xx class),
• devices where hardware modification is not possible.
• It would not replace proper hardware reset control, but it would improve cold-start determinism and reduce sporadic initialization failures in real-world scenarios.

Anything else?

This feature request is based on extensive real-world testing on a repurposed consumer device, not a theoretical use case.
The device uses an ST77916 display controller with no exposed RESET pin, which makes it particularly sensitive to early initialization during MCU boot.

I have documented the hardware and software context, including:

• pin definitions I've gathered from different sources from the actual company who made the actual product.
• The schematic
• The Display controller init sequence
• Multiple ESPHome / Home Assistant test commits showing different approaches and their effects, to some extent. It's been documented here and here.

References:
My repo.
A discussion with another developer, in regards to this specific device. It gives a better overall explanation of everything.

I am happy to provide additional logs, test builds, or help validate a potential implementation if needed.

[github-actions[bot]]

🏷️ I've automatically added the component: display label to help categorize this feature request.