drm_fb_xrgb8888_to_gray2(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ drm_fb_xrgb8888_to_gray2 πŸ’…

okay so bestie, this is a page from the Kernel API Manual and it's literally all about drm_fb_xrgb8888_to_gray2 β€” the glow-up function that takes your XRGB8888 pixels and turns them into gray2. no cap, that's the whole vibe. πŸŽ€


🌸 NAME 🌸

drm_fb_xrgb8888_to_gray2 β€” Convert XRGB8888 to gray2 ✨


πŸ¦‹ SYNOPSIS πŸ¦‹

void drm_fb_xrgb8888_to_gray2 (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 );

like, that's the whole signature, copy-pasted with love 🫢


πŸ’– ARGUMENTS πŸ’–

  • dst β€” Array of gray2 destination buffer. this is where the magic lands, bestie πŸ’«
  • dst_pitch β€” Array of numbers of bytes between the start of two consecutive scanlines within dst; it can be NULL if scanlines are stored next to each other. so like, NULL is fine here, no stress 🫢
  • src β€” Array of XRGB8888 source buffers. the originals, the main characters πŸ‘‘
  • fb β€” DRM framebuffer. the whole picture, literally πŸ–ΌοΈ
  • clip β€” Clip rectangle area to copy. only this little window gets invited to the party πŸŽ€
  • state β€” Transform and conversion state. it's giving "carry-on luggage for the conversion" ✨

πŸ”₯ DESCRIPTION πŸ”₯

So this function copies parts of a framebuffer to display memory and converts the color format during the process. Destination and framebuffer formats must match β€” like, they HAVE to match, that's not optional, periodt. πŸ’…

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 same index, same plane, everyone in their assigned seat, iconic behavior πŸͺ‘

⚠️ Heads up bestie: this function does not apply clipping on dst (i.e. the destination is at the top-left corner). no sneaky clipping, it just goes. 😭

The first pixel (upper left corner of the clip rectangle) will be converted and copied to the two first bits (LSB) in the first byte of the gray2 destination buffer. so the very first pixel gets the two LSBs of byte zero, that's the arrangement, that's the law πŸ“œβœ¨

And if the caller requires that the first pixel in a byte must be located at an x-coordinate that is a multiple of 8, then the caller must take care itself of supplying a suitable clip rectangle. like, that's a you problem, bestie β€” this function is not doing that math for you πŸ™ˆ

DRM doesn't have native gray2 support. (i know. tragic. πŸ’€) Drivers can use this function for gray2 devices that don't support XRGB8888 natively. Such drivers can announce the commonly supported XR24 format to userspace and use this function to convert to the native format. so you flex XR24 to userspace and quietly do the conversion on the back end β€” main character energy, honestly πŸ‘‘


🌈 SEE ALSO 🌈

Kernel file ./drivers/gpu/drm/drm_format_helper.c

and all these besties right here, the whole group chat 🫢:


πŸŽ€ sign-off πŸŽ€

so this page lives in ./drivers/gpu/drm, and it's dated October 2026 β€” yes, the future, we're ahead of schedule, slay ⭐ that's the whole manpage, you ate it up, ily, go convert some pixels bestie πŸ’œπŸŒΈ


πŸ“¦ where this page comes from