STRUCT GB_CAMERA_OPS(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… struct gb_camera_ops(9) πŸ’…

okay bestie, welcome to the Kernel API Manual (section 9, very demure, very kernel) β€” today we're doing struct gb_camera_ops, which is literally the Greybus camera operations table. It's what the Greybus camera driver uses to expose operations to the host camera driver. think of it as the group chat between the two of them 🫢


✨ SYNOPSIS ✨

struct gb_camera_ops {
    ssize_t (*capabilities)(void *priv, char *buf, size_t len);
    int (*configure_streams)(void *priv, unsigned int *nstreams,
unsigned int *flags, struct gb_camera_stream *streams, struct
gb_camera_csi_params *csi_params);
    int (*capture)(void *priv, u32 request_id, unsigned int streams,
unsigned int num_frames, size_t settings_size, const void *settings);
    int (*flush)(void *priv, u32 *request_id);
 };

like yes, the indentation is a little feral, that's just how it is, we don't fix it πŸ’€


πŸŽ€ Members πŸŽ€

  • capabilities β€” this one retrieves the camera capabilities and stashes them in the buffer, with the caller providing the size in the size parameter, and the effective capabilities size gets returned from the function. and if the buffer size is too small to hold the capabilities? it returns an error and the buffer is left completely untouched, no cap πŸ™…β€β™€οΈ
  • configure_streams β€” negotiate the configuration and get the module ready for video capture. the caller says how many streams it wants in the nstreams argument, and the matching stream configs go in the streams argument. you can set the GB_CAMERA_IN_FLAG_TEST flag to test a configuration without applying it β€” otherwise the module actually applies it. the module is allowed to decide to modify the requested configuration, including using a different number of streams. and when that happens the modified config won't be applied, the GB_CAMERA_OUT_FLAG_ADJUSTED flag gets set on return, and the modified configuration and number of streams get stored in streams and array. also, in all cases the module returns its CSI-2 bus parameters in the csi_params structure ✨
  • capture β€” submits a capture request. the request_id you pass must be unique and higher than the IDs of all the previously submitted requests (no cap, that's the rule πŸ“ˆ). the streams argument says which streams the request affects, in the form of a bitmask, with bits corresponding to the configured streams indexes. if the request contains settings, the specified by the settings_size argument β€” otherwise the settings argument should be set to NULL and settings_size to 0 🫑
  • flush β€” flushes the capture requests queue. it returns the ID of the last request that will processed by the device before it stops transmitting video frames. and heads up 🚨: all queued capture requests with IDs higher than the returned ID get dropped, just like that, without being processed πŸ’€

🌈 SEE ALSO 🌈

  • Kernel file ./drivers/staging/greybus/gb-camera.h β€” go read it, iykyk
  • struct gb_camera_stream(9)
  • struct gb_camera_csi_params(9)
  • struct gb_camera_module(9)

and that's the whole page, bestie! πŸ¦‹ this came to you straight from ./drivers/staging/greybus, dated October 2026, and honestly it ate πŸ’– periodt ✨

πŸ“¦ where this page comes from