drm_fb_xrgb8888_to_bgr888(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… drm_fb_xrgb8888_to_bgr888(9) β€” the Kernel API Manual glow-up πŸŽ€

okay bestie, so this page lives in the Kernel API Manual (section 9, dry land for kernel functions) and it's literally about drm_fb_xrgb8888_to_bgr888 β€” one tiny function doing the color-format glow-up from XRGB8888 to BGR888 on your clip buffer. it's giving "backstage wardrobe change but for pixels" ✨


🌸 NAME 🌸

drm_fb_xrgb8888_to_bgr888 β€” Convert XRGB8888 to BGR888 clip buffer πŸ’–

no cap, that's the whole vibe: pixel format makeover, clip buffer edition.


✨ SYNOPSIS ✨

void drm_fb_xrgb8888_to_bgr888 (struct iosys_map *dst , const unsigned
int *dst_pitch , const struct iosys_map *src , const struct
drm_framebuffer *fb , const struct drm_rect *clip , struct
drm_format_conv_state *state );

six params, zero drama (okay maybe a little drama, it's a void function so nothing comes back, she just does the work and leaves πŸ’…).


🫢 ARGUMENTS 🫢

  • dst β€” Array of BGR888 destination buffers. this is where the glow-up lands, bestie πŸŽ€
  • dst_pitch β€” Array of numbers of bytes between the start of two consecutive scanlines within dst; can be NULL if scanlines are stored next to each other. so like, the gap between rows β€” and if there's no gap, just pass NULL and breathe 🌸
  • src β€” Array of XRGB8888 source buffers. the before picture πŸ’–
  • fb β€” DRM framebuffer. the main character of this whole operation πŸ‘‘
  • clip β€” Clip rectangle area to copy. only this lil window gets copied, periodt βœ‚οΈ
  • state β€” Transform and conversion state. the behind-the-scenes lore πŸ¦‹

πŸ’œ DESCRIPTION πŸ’œ

so what she actually does: this function copies parts of a framebuffer to display memory and converts the color format during the process. like a two-in-one, highkey efficient, we love to see it πŸ”₯

Destination and framebuffer formats must match. not "should", must β€” this is not a drill 🚨

the parameters dst, dst_pitch and src refer to arrays. Each array must have at least as many entries as there are planes in fb's format. Each entry stores the value for the format's respective color plane at the same index. so like, keep your arrays long enough for every plane, and keep the indices lined up β€” same index, same plane, no mixing 🧚

⚠️ heads up bestie: this function does not apply clipping on dst (i.e. the destination is at the top-left corner). so the clipping already happened conceptually β€” dst starts at the top-left corner and she just writes. don't expect extra clipping magic on the destination side, okay? 😭

Drivers can use this function for BGR888 devices that don't natively support XRGB8888. literally built for the devices that can't speak XRGB8888 natively β€” she translates, she slays πŸ’…


🌈 SEE ALSO 🌈

the whole friend group, fr fr β€” you're gonna want to know all of them:


and that's the page, bestie 🫢 this one ships out of ./drivers/gpu/drm, dated October 2026, and it's the Kernel API Manual's own drm_fb_xrgb8888_to_bgr888(9) β€” go convert something iconic πŸ’…βœ¨

πŸ“¦ where this page comes from