drm_fb_helpe...itial_config(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ NAME ✨

okay so bestie, this is drm_fb_helpe...itial_config β€” it's literally the function that sets up a sane initial connector configuration for you πŸ’… (yes, "sane" is doing a lot of work there, but we love her).

quick heads-up, this page lives in the Kernel API Manual πŸŽ€ so you know exactly what kind of chaos you're signing up for.


🌸 SYNOPSIS 🌸

int drm_fb_helper_initial_config (struct drm_fb_helper *fb_helper );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • fb_helper β€” the fb_helper device struct, aka the little guy you hand over so she can do her thing 🫢

πŸ’– DESCRIPTION πŸ’–

So here's the vibe: she scans the CRTCs and connectors and tries to pull together an initial setup for you ✨. At the moment β€” and yes, at the moment, things may change β€” this is a cloned configuration across all heads, with a new framebuffer object as the backing store. iconic behavior fr fr.

Also important: this registers the fbdev, which means userspace can now call into the driver through the fbdev interfaces πŸ‘‘.

She'll call down into the drm_driver.fbdev_probe callback so the driver can allocate and initialize the fbdev info structure and the drm framebuffer that backs the fbdev. And good news: drm_fb_helper_fill_info is right there as a helper to set up simple default values for the fbdev info structure 😌.

πŸ’€ HANG DEBUGGING πŸ’€

okay this part is the main character of the horror movie, pay attention 😭

When you have fbcon support built-in or already loaded, this function will do a full modeset to set up the fbdev console. But because of a locking misdesign in the VT/fbdev subsystem, that entire modeset sequence has to be done while holding console_lock. And until console_unlock is called, no dmesg lines will be sent out to consoles β€” not even serial console. Not one. Not a single one πŸ™ˆ.

Which means: when your driver crashes, you will see absolutely nothing except a system stuck in this function, with no further output. Any kind of printk you place within your own driver or in the drm core modeset code will also never show up. she's silent. she's mysterious. she's debugging hell πŸ’€

Standard debug practice is to run the fbcon setup without taking the console_lock as a hack, so you can actually see backtraces and crashes on the serial line πŸ‘€. You do that by setting the fb.lockless_register_fb=1 kernel cmdline option.

The other option is to just disable fbdev emulation entirely, since very likely the first modeset from userspace will crash in the same way β€” and that's even easier to debug πŸŽ€. Do that by setting the drm_kms_helper.fbdev_emulation=0 kernel cmdline option.

ngl bestie, if you're seeing a hang with zero output, it's probably not you. it's the lock. it's always the lock. 🫢

⭐ RETURN ⭐

Zero if everything went ok, nonzero otherwise. that's it, that's the whole vibe check 😌


🌈 SEE ALSO 🌈


and that's the page bestie!! πŸŽ€βœ¨ this one's from ./drivers/gpu/drm, dated October 2026, and yeah the title really is drm_fb_helpe...itial_config(9) because the man page tooling ate the middle of it πŸ˜­πŸ’– go forth and modeset responsibly πŸ¦‹πŸ’…

πŸ“¦ where this page comes from