DRM FB emulation initialisation leaving the display disabled

Thomas Zimmermann tzimmermann at suse.de
Thu Oct 12 07:03:36 UTC 2023


Hi Dave

Am 11.10.23 um 17:52 schrieb 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.

What you're describing sounds like the recent bug report at

   https://gitlab.freedesktop.org/drm/amd/-/issues/2649

which had similar symptoms with amdgpu. IIRC the console didn't 
initialize if the DRM hotplugging event happened before fbdev emulation 
was ready. DRM's fbdev code would then not see the hotplugged connector.

Do you have commit 27655b9bb9f0 ("drm/client: Send hotplug event after 
registering a client") in your tree? (It's been ported into various 
stable branches as well.)

Best regard
Thomas

> 
> 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

-- 
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20231012/648a829b/attachment.sig>


More information about the dri-devel mailing list