Re: [ANNv4] Media Summit on May 26th in Nice, France

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

On Tue, Apr 14, 2026 at 01:55:20PM -0400, Nicolas Dufresne wrote:
> Hey,
> 
> Le mardi 14 avril 2026 à 11:42 +0300, Laurent Pinchart a écrit :
> > Let's not reproduce the design mistakes made in the V4L2 M2M framework.
> > 
> > I also think you need to decouple the context handling and scheduling in
> > two separate components. They need to work together, but shouldn't be
> > bundled into a monolithic system. Very importantly, a driver should be
> > able to implement contexts with the multi-context helpers, and implement
> > custom scheduling itself.
> 
> Note that the v4l2_m2m_dev is juts miss-named, it does not wrap a specific dev
> instance anymore. I'll rename and clean that up eventually, but I agree its not
> meant for your purpose, and it will be a good fight to use. Its already a pretty
> big miss-fit for stateful codec, which don't really have the notion of "active
> central job". Jacopo's proposal is to have multi-context MC (as you already
> know), making the media device as the central source of context, so I think
> that's a path in the right direction.
> 
> But I'll be honest, I would see a future where we actually drop (or break down
> into pieces) VB2, which is I read you well, its not miss-aligned with your say.

I won't object :-) vb2 was designed as a midlayer, and that causes
headaches (I'm thinking in particular about how .start_streaming() is
delayed until buffers get queued). I have less issues with vb2 than with
the M2M midlayer, as vb2 gets less in the way, but I think we should
overall favour for new developments smaller helpers that drivers can
assemble based on their needs over monolithic midlayers.

-- 
Regards,

Laurent Pinchart