STRUCT MEDIA_DEVICE(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

✨ NAME ✨

okay bestie, this is struct media_device(9) from the Kernel API Manual β€” section 9, bestie, keep up β€” and it's literally the page for a media device struct. It's giving "abstract high-level media device" main character energy, and we're gonna go through every single member, no cap. πŸ’…


πŸŽ€ SYNOPSIS πŸŽ€

       struct media_device {
           struct device *dev;
           struct media_devnode *devnode;
           char model[32];
           char driver_name[32];
           char serial[40];
           char bus_info[32];
           u32 hw_revision;
           u64 topology_version;
           u32 id;
           struct ida entity_internal_idx;
           int entity_internal_idx_max;
           struct list_head entities;
           struct list_head interfaces;
           struct list_head pads;
           struct list_head links;
           struct list_head entity_notify;
           struct mutex graph_mutex;
           struct media_graph pm_count_walk;
           void *source_priv;
           int (*enable_source)(struct media_entity *entity, struct
       media_pipeline *pipe);
           void (*disable_source)(struct media_entity *entity);
           const struct media_device_ops *ops;
           struct mutex req_queue_mutex;
           atomic_t num_requests;
           atomic_t num_request_objects;
           struct dentry *media_dir;
           atomic_t request_id;
        };

πŸ’… Members πŸ’…

  • dev β€” Parent device. The whole "who's your parent" situation. 🫢
  • devnode β€” Media device node. The node for the media device.
  • model β€” Device model name. This is the model-name moment.
  • driver_name β€” Optional device driver name. If you don't set it, calls to MEDIA_IOC_DEVICE_INFO return dev->driver->name. This is needed for USB drivers for example, because otherwise they'll all appear as if the driver name was "usb". 😭
  • serial β€” Device serial number (optional).
  • bus_info β€” Unique and stable device location identifier. Stable and unique, periodt.
  • hw_revision β€” Hardware device revision.
  • topology_version β€” Monotonic counter for storing the version of the graph topology. Should be incremented each time the topology changes. Lowkey important: if topology changes, bump it. ⭐
  • id β€” Unique ID used on the last registered graph object.
  • entity_internal_idx β€” Unique internal entity ID used by the graph traversal algorithms.
  • entity_internal_idx_max β€” Allocated internal entity indices.
  • entities β€” List of registered entities.
  • interfaces β€” List of registered interfaces.
  • pads β€” List of registered pads.
  • links β€” List of registered links.
  • entity_notify β€” List of registered entity_notify callbacks.
  • graph_mutex β€” Protects access to struct media_device data. Literally the bodyguard. πŸ’ͺ
  • pm_count_walk β€” Graph walk for power state walk. Access serialised using graph_mutex.
  • source_priv β€” Driver Private data for enable_source/disable_source handlers.
  • enable_source β€” Enable Source Handler function pointer.
  • disable_source β€” Disable Source Handler function pointer.
  • ops β€” Operation handler callbacks.
  • req_queue_mutex β€” Serialise the MEDIA_REQUEST_IOC_QUEUE ioctl w.r.t. other operations that stop or start streaming.
  • num_requests β€” number of associated requests.
  • num_request_objects β€” number of associated request objects.
  • media_dir β€” DebugFS media directory.
  • request_id β€” Used to generate unique request IDs.

🌸 Description 🌸

This structure represents an abstract high-level media device. It allows easy access to entities and provides basic media device-level support. The structure can be allocated directly or embedded in a larger structure. So yes, bestie, you can have it standalone or tucked inside a bigger struct β€” both are valid. πŸ¦‹

The parent dev is a physical device. It must be set before registering the media device. Do not skip this. It's a must, fr fr.

model is a descriptive model name exported through sysfs. It doesn't have to be unique. So no pressure to be one-of-a-kind, it's just a descriptive name. πŸ’–

enable_source is a handler to find source entity for the sink entity and activate the link between them if source entity is free. Drivers should call this handler before accessing the source.

disable_source is a handler to find source entity for the sink entity and deactivate the link between them. Drivers should call this handler to release the source.

Use-case: find tuner entity connected to the decoder entity and check if it is available, and activate the link between them from enable_source and deactivate from disable_source. That's the whole little tuner-decoder situation, iykyk. πŸ‘‘

🚨 NOTE 🚨

Bridge driver is expected to implement and set the handler when media_device is registered or when bridge driver finds the media_device during probe. Bridge driver sets source_priv with information necessary to run enable_source and disable_source handlers. Callers should hold graph_mutex to access and call enable_source and disable_source handlers.

πŸ¦‹ SEE ALSO πŸ¦‹


that's the whole page, bestie β€” source/version: ./include/media, date: October 2026. go off, you've got this πŸ’œπŸŒΈ

πŸ“¦ where this page comes from