vb2_prepare_buf(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… vb2_prepare_buf(9) β€” Kernel API Manual edition πŸ’…

πŸŽ€ NAME πŸŽ€

vb2_prepare_buf β€” Pass ownership of a buffer from userspace to the kernel. That's the whole serve: userspace hands the buffer over, kernel takes the wheel. πŸ‘‘


✨ SYNOPSIS ✨

okay bestie, the call looks exactly like this, no cap:

int vb2_prepare_buf (struct vb2_queue *q , struct media_device *mdev ,
       struct v4l2_buffer *b );

🫢 ARGUMENTS 🫢

  • q β€” pointer to struct vb2_queue with videobuf2 queue. This is the videobuf2 queue situation, iconic.
  • mdev β€” pointer to struct media_device, may be NULL. Not a typo, bestie, NULL is allowed here. πŸ™ˆ
  • b β€” buffer structure passed from userspace to v4l2_ioctl_ops->vidioc_prepare_buf handler in driver.

πŸ”₯ DESCRIPTION πŸ”₯

Should be called from the v4l2_ioctl_ops->vidioc_prepare_buf ioctl handler of a driver. Like, that's its whole main-character entrance. ✨

This function:

  1. verifies the passed buffer.
  2. calls vb2_ops->buf_prepare callback in the driver (if provided), in which driver-specific buffer initialization can be performed.
  3. if b->request_fd is non-zero and mdev->ops->req_queue is set, then bind the prepared buffer to the request.

The return values from this function are intended to be directly returned from v4l2_ioctl_ops->vidioc_prepare_buf handler in driver. So don't get creative with them β€” hand them straight back. πŸ’…


🌈 SEE ALSO 🌈

go read these too, they're all part of the lore:


mwah πŸ’‹ β€” source/version ./include/media, date October 2026, page vb2_prepare_buf(9). bye bestie, go prepare those buffers 🫢

πŸ“¦ where this page comes from