drm_fb_helpe...itial_config(9)
β¨ 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 π
- Kernel file
./drivers/gpu/drm/drm_fb_helper.c fbdev helpers(9)drm_fb_helper_restore_fbdev_mode_unlocked(9)drm_fb_helper_blank(9)drm_fb_helper_prepare(9)drm_fb_helper_unprepare(9)drm_fb_helper_init(9)drm_fb_helper_unregister_info(9)drm_fb_helper_fini(9)drm_fb_helper_deferred_io(9)drm_fb_helper_set_suspend(9)drm_fb_helper_set_suspend_unlocked(9)drm_fb_helper_setcmap(9)drm_fb_helper_ioctl(9)drm_fb_helper_check_var(9)drm_fb_helper_set_par(9)drm_fb_helper_pan_display(9)drm_fb_helper_fill_info(9)drm_fb_helper_hotplug_event(9)drm_fb_helper_gem_is_fb(9)
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
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms