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
