Re: [ANNOUNCEMENT] Camera & ISP at Linux Plumbers Conference

[Bryan O'Donoghue <bod@kernel.org>]

On 19/09/2026 23:29, Laurent Pinchart wrote:
>> V4L2 owning sensor -> inline engine is already supported and won't
>> change. For subsequent steps though each stage hands off in-kernel
>> without having to involve userspace.
> That's fences, isn't it ?

Perhaps fences in v4l will do exactly the job I want. I'm more 
investigating than specifically pushing a solution.

My understanding of drm benefits are:

- drm_sched
   job scheduling based on dependency fences

- dma_resv
   fencing, sync

- syncobj
   user-space sync primitives which can be
   shared with say a compositor

- TDR
   Builtin fault tolerance.

Probably the best thing to do is to implement both a v4l and drm wrapper 
around the functionality and use it in anger.

There'd be no specific barrier to implementing a libcamera pipeline 
around a DRM device, I mean that's what gpuisp is even if its wrappered 
up in mesa so.. :)

Nicolas mentioned the idea of implementing codec drivers in DRM for 
reasons similar to the above.

Anyway I'm curious to know what the DRM advocates and detractors would 
say about that. It's a question I have not an assertion.

For an inline ISP where you connect a sensor to a CSI block the 
media-graph seems like a nice well defined thing.

The offline ISP I'm describing - truthfully has elements of codec and 
elements of ISP.

Probably the only way to really know is to experiment and see what falls 
out.

---
bod