DRM FB emulation initialisation leaving the display disabled

[Dave Stevenson]

Hi Thomas (and everyone else)

Maxime has suggested you're the person for DRM framebuffer emulation.

I'm getting some unexpected behaviour when there are multiple DRM
drivers in play. In this case it happens to be vc4 and the tiny
hx8357d SPI display driver, but this affects most of the tiny DRM
drivers and also the DSI and DPI outputs on the Pi5.
We get different behaviour depending on whether vc4 or hx8357d
initialises first.

If hx8357d loads first and registers as /dev/fb0 through the fb
emulation, then we get fbcon enabling the display and putting the
emulated framebuffer on it. vc4 then loads, registers /dev/fb1, and
through the hotplug handler it enables the display
(drm_fb_helper_hotplug_event calls, drm_fb_helper_set_par, which calls
__drm_fb_helper_restore_fbdev_mode_unlocked).

If vc4 loads first and claims /dev/fb0, fbcon initalises and enables
the display. hx8357d then loads and registers as /dev/fb1. fbcon is
not configured for that fb, and there is no subsequent hotplug event
(SPI displays aren't hotpluggable), so we have a fully configured
framebuffer exposed to userspace but the display itself isn't enabled
so we don't see anything :-(
Open and close /dev/dri/card1 and the lastclose hook calls
drm_fb_helper_restore_fbdev_mode_unlocked and we get the display
enabled.

Is it intentional that we're left in this limbo state with the display
not enabled if fbcon isn't enabled on a framebuffer?

We're trying to get people to transition from the fbdev drivers to DRM
equivalents, but this seems to be a backwards step if there is an
extra step required to get the display enabled. Many users are still
just using the framebuffer.

Any input is much appreciated.

Thanks,
  Dave