drm_driver_legacy_fb_format(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸŽ€ drm_driver_legacy_fb_format(9) πŸŽ€

okay so bestie, this page is straight out of the Kernel API Manual and it's literally about turning legacy vibes into a fourcc code. stay with me πŸ’…


✨ NAME ✨

drm_driver_legacy_fb_format β€” compute drm fourcc code from legacy description

🌸 SYNOPSIS 🌸

uint32_t drm_driver_legacy_fb_format (struct drm_device *dev , uint32_t bpp , uint32_t depth );

πŸ¦‹ ARGUMENTS πŸ¦‹

  • dev β€” DRM device
  • bpp β€” bits per pixels
  • depth β€” bit depth per pixel

πŸ’– DESCRIPTION πŸ’–

So what it does is compute a drm fourcc pixel format code for whatever bpp/depth values you hand it. No cap.

But here's the tea: unlike drm_mode_legacy_fb_format, this one actually looks at the driver's mode_config. And depending on the drm_mode_config.quirk_addfb_prefer_host_byte_order flag, it returns either little endian byte order or host byte order framebuffer formats. iconic behavior tbh 🫢

🌈 SEE ALSO 🌈

Kernel file ./drivers/gpu/drm/drm_fourcc.c, drm_mode_legacy_fb_format(9), drm_driver_color_mode_format(9), drm_format_info(9), drm_get_format_info(9), drm_format_info_block_width(9), drm_format_info_block_height(9), drm_format_info_bpp(9), drm_format_info_min_pitch(9)


and that's the whole page, bestie πŸ“ shoutout to the source ./drivers/gpu/drm, version/date October 2026, and drm_driver_legacy_fb_format(9) itself β€” we ate and left no crumbs πŸ‘‘πŸ’œ

πŸ“¦ where this page comes from