On Tue, Nov 10, 2026 at 02:30:51PM +0100, Hans Verkuil wrote:
> On 10/11/2026 13:33, Maxime Ripard wrote:
> > Hi Hans,
> > 
> > On Tue, Nov 10, 2026 at 01:08:05PM +0100, Hans Verkuil wrote:
> >> On 23/10/2026 14:26, Mattijs Korpershoek wrote:
> >>> Hi everyone,
> >>>
> >>> On Thu, Oct 01, 2026 at 14:55, Mattijs Korpershoek <mkorpershoek@kernel.org> wrote:
> >>>
> >>>> On media-centric camera pipelines, every entity is known at boot time
> >>>> and described statically (for example via device-tree).
> >>>>
> >>>> The V4L2 framework assumes that every entity of the camera
> >>>> pipeline is always present. This is a reasonable assumption for
> >>>> integrated cameras in laptops or phones. However, in automotive systems,
> >>>> cameras (e.g. rear-view or surround-view) can be damaged or disconnected.
> >>>> When the framework assumes all sensors are present, a single missing
> >>>> camera can prevent the entire pipeline from operating.
> >>>
> >>> This series has been discussed at the Camera & ISP "unconference" in
> >>> Pragues (during Linux Plumbers)
> >>>
> >>> The notes can be found here:
> >>> https://lore.kernel.org/linux-media/20261021224119.GA383235@killaraus.ideasonboard.com/T/#u
> >>
> >> What is missing in this discussion is how userspace can indicate that it
> >> actually can handle partially instantiated pipelines.
> >>
> >> Today if one or more parts do not come up, the devices nodes are also not
> >> created. This is typically exactly what you want.
> > 
> > That's very arguable? We have plenty of other examples where we allow to
> > show a software representation of something that isn't available in
> > hardware, starting with virtually any memory buffer allocation, but also
> > disabled CPUs, swapped pages, etc.
> > 
> > For things a bit more related to drivers, things like USB root hubs are
> > also pretty analogous. The "root" device will always be created, even if
> > devices connected to it are non-functional, missing or whatever. It's
> > the primary interface that these devices might or might not attach to.
> > 
> > So it's a bit hard to understand why the device nodes not showing up is
> > exactly what we always want.
> 
> It's simply how V4L2 works today: video devices do not appear until
> all components are instantiated.

Sure but that's exactly what we're trying to change.

> Most video devices consist of multiple devices (bridges, i2c devices,
> etc.) and unless all are found and initialized, you can't capture. So
> bridge drivers postpone creating the video/media devices until
> everything is there.
> 
> That also means that applications can safely assume that if a video device appears,
> it is functioning.

Ish. The only safe assumption you can make about this is that it was
functional at probe time. Anything after that is very much up in the
air. If the device broken after probe for example, or if we have no way
to tell if it's functional to begin with, that assumption is no longer
true. So sure, that's what applications have been doing so far because
there was no better way to do it, but I wouldn't qualify it as a "safe"
assumption.

> If we add fault tolerance, and you allow video devices to appear even if they are
> not functioning (or partially functioning), then that contract breaks.
>
> > 
> >> But here you allow partial instantiation, and how does userspace
> >> signal that? It must be an 'opt-in' mechanism, but how is that done?
> >> There are no devices yet, so that can't be used, so what alternatives
> >> are there?
> >>
> >> We've been discussion Fault Tolerant V4L2 for many years now, and every time
> >> I raise this issue, but I never received any proposals.
> >>
> >> This must be solved.
> > 
> > Is there any way to? You're saying at the same time that we must not
> > create the device, but that an application would need to signal to that
> > device that it can indeed be created. It's a circular dependency that
> > cannot be solved on a per-device basis.
> > 
> > During the meeting, we had a discussion that the media device should be
> > created as a "skeleton", and then as other devices probe they would fill
> > in the blanks. How would that not work? Also what is your main concern
> > exactly that makes you ask to not do that in the first place (or make it
> > opt-in)?
> 
> Applications today assume that everything works when the device nodes appear.
> 
> If you change the behavior, then they just see a skeleton driver and how
> would they know that they need to wait until all components are found and
> it is ready for use? Or what to do if some parts are faulty?

I really think that this discussion is not solely about probe. It's
something we discussed during the meeting, but I think we should try to
handle "my device was broken at probe" and "my device became broken
while the system was up" exactly the same way.

And while it's true that our assumptions currently deal with the former
fine, we just don't deal at all with the second, and everything you're
saying here could still happen.

So, to answer your questions, I think it's entirely application
specific. A video-conferencing application would error out or might want
to wait forever for its only relevant sensor to show up. A multi-stream
dashboard in a car would just show a blank screen and show the other
streams. I'm not sure we should (or can) come up with a policy at the
kernel level.

> One solution might be that bridge drivers capable of fault tolerant behavior would
> create a /sys entry called 'v4l-fault-tolerance' (just an example) somewhere.
> 
> Applications that can handle this can find that entry and write '1' to it.
> After that the driver will start creating devices even if not everything is
> available. Without it it will just block (the current behavior).
>
> It's also tied to your use-case: for the same hardware your use-case might be
> fine with the current situation (non-fault-tolerant), or you want to enable it.
> 
> There might be other ways to implement this: e.g. a module option or a Kconfig
> option.

Yeah, I guess that could work

> Also note that systemd opens video nodes as they are created. It used to use
> v4lctl for that, but that might be integrated now.
> 
> So that should keep working. I think it just calls QUERYCAP, so that is likely
> to just work.
> 
> Regardless, I want to see an RFC for this, demonstrating that someone has
> thought about it. If you think this can be done safely without an opt-in mechanism,
> then explain so in the RFC.

ACK. Thanks!
Maxime