STRUCT DMX_DEMUX(9)

✨ NAME ✨

okay so this is struct dmx_demux from the Kernel API Manual, aka the structure that contains the demux capabilities and callbacks 💅 that's the whole assignment bestie: capabilities + callbacks, all bundled in one iconic little struct.

think of it as the main character of the demux world — every demux out there has one of these, and it's where the kernel goes "hey, what can you do, and who do I call when I need something done?" 🎀

---

🌸 SYNOPSIS 🌸

here's the whole thing, laid out exactly how it lives in the headers — no cap, this is verbatim:

struct dmx_demux {
    enum dmx_demux_caps capabilities;
    struct dmx_frontend *frontend;
    void *priv;
    int (*open)(struct dmx_demux *demux);
    int (*close)(struct dmx_demux *demux);
    int (*write)(struct dmx_demux *demux, const char __user *buf, size_t count);
    int (*allocate_ts_feed)(struct dmx_demux *demux, struct dmx_ts_feed **feed, dmx_ts_cb callback);
    int (*release_ts_feed)(struct dmx_demux *demux, struct dmx_ts_feed *feed);
    int (*allocate_section_feed)(struct dmx_demux *demux, struct dmx_section_feed **feed, dmx_section_cb callback);
    int (*release_section_feed)(struct dmx_demux *demux, struct dmx_section_feed *feed);
    int (*add_frontend)(struct dmx_demux *demux, struct dmx_frontend *frontend);
    int (*remove_frontend)(struct dmx_demux *demux, struct dmx_frontend *frontend);
    struct list_head *(*get_frontends)(struct dmx_demux *demux);
    int (*connect_frontend)(struct dmx_demux *demux, struct dmx_frontend *frontend);
    int (*disconnect_frontend)(struct dmx_demux *demux);
    int (*get_pes_pids)(struct dmx_demux *demux, u16 *pids);
};

🦋 meet the members (16 of them, all slaying)

let's do a little roll call so nothing gets lost, k? every single field, right here, no skipping 🙈

• enum dmx_demux_caps capabilities; — the capabilities field, typed enum dmx_demux_caps. it's literally the struct's whole personality.
• struct dmx_frontend *frontend; — a pointer to a struct dmx_frontend. yes girl, frontend, in a demux struct, we love a crossover episode.
• void *priv; — the classic void *priv private-data slot. every good struct has one 🫶
• int (*open)(struct dmx_demux *demux); — the open callback. takes the demux, returns an int.
• int (*close)(struct dmx_demux *demux); — the close callback. also demux in, int out. the matching set, periodt.
• int (*write)(struct dmx_demux *demux, const char __user *buf, size_t count); — the write callback, and it's giving const char __user *buf plus a size_t count. note the __user — that buffer is coming from userspace, iykyk 👀
• int (*allocate_ts_feed)(struct dmx_demux *demux, struct dmx_ts_feed **feed, dmx_ts_cb callback); — allocates a TS feed. double pointer on struct dmx_ts_feed **feed so the caller gets the handle back, plus a dmx_ts_cb callback. iconic.
• int (*release_ts_feed)(struct dmx_demux *demux, struct dmx_ts_feed *feed); — the cleanup counterpart. single pointer this time, struct dmx_ts_feed *feed. balance ✨
• int (*allocate_section_feed)(struct dmx_demux *demux, struct dmx_section_feed **feed, dmx_section_cb callback); — same energy as the TS one but for sections: struct dmx_section_feed **feed and a dmx_section_cb callback.
• int (*release_section_feed)(struct dmx_demux *demux, struct dmx_section_feed *feed); — releases it. struct dmx_section_feed *feed, one int return. we stan a matching pair 💖
• int (*add_frontend)(struct dmx_demux *demux, struct dmx_frontend *frontend); — adds a frontend. takes the demux and a struct dmx_frontend *frontend.
• int (*remove_frontend)(struct dmx_demux *demux, struct dmx_frontend *frontend); — removes one. same args, same int. add/remove, the duo of all time.
• struct list_head *(*get_frontends)(struct dmx_demux *demux); — ok this one is chef's kiss: it's a function pointer that returns a struct list_head *. note the signature — it takes only demux, and it hands you back a list head. 🔥
• int (*connect_frontend)(struct dmx_demux *demux, struct dmx_frontend *frontend); — connect a frontend. demux + struct dmx_frontend *frontend, returns int.
• int (*disconnect_frontend)(struct dmx_demux *demux); — and here's the little plot twist: disconnect_frontend takes only the demux. no frontend argument. she doesn't need one. main character energy fr fr 💅
• int (*get_pes_pids)(struct dmx_demux *demux, u16 *pids); — the last one, and it's giving u16 *pids. hands you pids via pointer, returns int. a closer. 🌈

heads up bestie: that's the whole struct as written — capabilities field, frontend pointer, priv, and all those callbacks. the deep lore on what each one actually does is coming in the next part, so don't go anywhere 💀

✨ MEMBERS ✨

Okay bestie, this is the actual meat of struct dmx_demux — every single field and function pointer, no skips, let's go 💅

• capabilities — a bitfield of capability flags. that's it, that's the whole vibe ✨
• frontend — the front-end that's connected to the demux 🫶
• priv — a pointer to the private data of the API client. it's giving "my stuff, don't touch" 🙈
• open — this function reserves the demux for use by the caller and, if necessary, initializes the demux. when the demux isn't needed anymore, you call close. it should be possible for multiple clients to access the demux at the same time — so the implementation should increment the demux usage count when open is called and decrement it when close is called. the demux function parameter holds a pointer to the demux API and instance data. It returns: 0 on success; -EUSERS, if maximum usage count was reached; -EINVAL, on bad parameter.
• close — okay so the original text here is literally a copy of the open description (iconic of it, honestly 😭), but the actual deets: when the demux is no longer needed, this function should be called. multiple clients can access the demux at the same time, so the implementation should increment the demux usage count when open is called and decrement it when close is called. the demux function parameter holds a pointer to the demux API and instance data. It returns: 0 on success; -ENODEV, if demux was not in use (e. g. no users); -EINVAL, on bad parameter.
• write — this function hands the demux driver a memory buffer containing TS packets. instead of receiving TS packets from the DVB front-end, the demux driver software will read packets from memory 📥 any clients of this demux with active TS, PES or Section filters will receive filtered data via the Demux callback API (see 0). the function returns when all the data in the buffer has been consumed by the demux. demux hardware typically cannot read TS from memory — if that's the case, memory-based filtering has to be implemented entirely in software, no cap 💀 The demux function parameter holds a pointer to the demux API and instance data. The buf function parameter holds a pointer to the TS data in kernel-space memory. The count function parameter holds the length of the TS data. It returns: 0 on success; -ERESTARTSYS, if mutex lock was interrupted; -EINTR, if a signal handling is pending; -ENODEV, if demux was removed; -EINVAL, on bad parameter.
• allocate_ts_feed — allocates a new TS feed, which is used to filter the TS packets carrying a certain PID. the TS feed normally corresponds to a hardware PID filter on the demux chip 🎯 The demux function parameter holds a pointer to the demux API and instance data. The feed function parameter holds a pointer to the TS feed API and instance data. The callback function parameter holds a pointer to the callback function for passing received TS packet. It returns: 0 on success; -ERESTARTSYS, if mutex lock was interrupted; -EBUSY, if no more TS feeds is available; -EINVAL, on bad parameter.
• release_ts_feed — releases the resources allocated with allocate_ts_feed. any filtering in progress on the TS feed should be stopped before calling this function, bestie, don't skip that step 🛑 The demux function parameter holds a pointer to the demux API and instance data. The feed function parameter holds a pointer to the TS feed API and instance data. It returns: 0 on success; -EINVAL on bad parameter.
• allocate_section_feed — allocates a new section feed, i.e. a demux resource for filtering and receiving sections. on platforms with hardware support for section filtering, a section feed is directly mapped to the demux HW. on other platforms, TS packets are first PID filtered in hardware and a hardware section filter then emulated in software 🧚 the caller obtains an API pointer of type dmx_section_feed_t as an out parameter — using this API the caller can set filtering parameters and start receiving sections. The demux function parameter holds a pointer to the demux API and instance data. The feed function parameter holds a pointer to the TS feed API and instance data. The callback function parameter holds a pointer to the callback function for passing received TS packet. It returns: 0 on success; -EBUSY, if no more TS feeds is available; -EINVAL, on bad parameter.
• release_section_feed — releases the resources allocated with allocate_section_feed, including allocated filters. any filtering in progress on the section feed should be stopped before calling this function 🙏 The demux function parameter holds a pointer to the demux API and instance data. The feed function parameter holds a pointer to the TS feed API and instance data. It returns: 0 on success; -EINVAL, on bad parameter.
• add_frontend — registers a connectivity between a demux and a front-end, i.e., it indicates that the demux can be connected via a call to connect_frontend to use the given front-end as a TS source. the client of this function has to allocate dynamic or static memory for the frontend structure and initialize its fields before calling this function. this function is normally called during the driver initialization. the caller must not free the memory of the frontend struct before successfully calling remove_frontend — like, do not do that, fr fr 🌸 The demux function parameter holds a pointer to the demux API and instance data. The frontend function parameter holds a pointer to the front-end instance data. It returns: 0 on success; -EINVAL, on bad parameter.
• remove_frontend — indicates that the given front-end, registered by a call to add_frontend, can no longer be connected as a TS source by this demux. the function should be called when a front-end driver or a demux driver is removed from the system. if the front-end is in use, the function fails with the return value of -EBUSY. after successfully calling this function, the caller can free the memory of the frontend struct if it was dynamically allocated before the add_frontend operation ✨ The demux function parameter holds a pointer to the demux API and instance data. The frontend function parameter holds a pointer to the front-end instance data. It returns: 0 on success; -ENODEV, if the front-end was not found, -EINVAL, on bad parameter.
• get_frontends — provides the APIs of the front-ends that have been registered for this demux. any of the front-ends obtained with this call can be used as a parameter for connect_frontend. the include file demux.h contains the macro DMX_FE_ENTRY for converting an element of the generic type struct list_head * to the type struct dmx_frontend * 🦋 the caller must not free the memory of any of the elements obtained via this function call — hands off, those aren't yours 💅 The demux function parameter holds a pointer to the demux API and instance data. It returns a struct list_head pointer to the list of front-end interfaces, or NULL in the case of an empty list.
• connect_frontend — connects the TS output of the front-end to the input of the demux 🔌 a demux can only be connected to a front-end registered to the demux with the function add_frontend. it may or may not be possible to connect multiple demuxes to the same front-end, depending on the capabilities of the HW platform. when not used, the front-end should be released by calling disconnect_frontend. The demux function parameter holds a pointer to the demux API and instance data. The frontend function parameter holds a pointer to the front-end instance data. It returns: 0 on success; -EINVAL, on bad parameter.
• disconnect_frontend — disconnects the demux and a front-end previously connected by a connect_frontend call ✂️ The demux function parameter holds a pointer to the demux API and instance data. It returns: 0 on success; -EINVAL on bad parameter.
• get_pes_pids — get the PIDs for DMX_PES_AUDIO0, DMX_PES_VIDEO0, DMX_PES_TELETEXT0, DMX_PES_SUBTITLE0 and DMX_PES_PCR0 🎀 The demux function parameter holds a pointer to the demux API and instance data. The pids function parameter holds an array with five u16 elements where the PIDs will be stored. It returns: 0 on success; -EINVAL on bad parameter.

---

🌈 SEE ALSO 🌈

Kernel file ./include/media/demux.h enum ts_filter_type(9), struct dmx_ts_feed(9), struct dmx_section_filter(9), struct dmx_section_feed(9), dmx_ts_cb(9), dmx_section_cb(9), enum dmx_frontend_source(9), struct dmx_frontend(9), enum dmx_demux_caps(9), DMX_FE_ENTRY(9)

---

okay that's the whole page, you ate that 👑 this lil beauty lives in ./include/media and the version is from October 2026, page struct dmx_demux(9) — go forth and demux, bestie, you've got this 💖✨