Re: [PATCH v2 01/10] media: v4l2-core: Introduce state management for video devices

[Mauro Carvalho Chehab <mchehab+huawei@kernel.org>]

Em Fri, 19 Sep 2025 15:25:53 +0530
Jai Luthra <jai.luthra@ideasonboard.com> escreveu:

> Similar to V4L2 subdev states, introduce state support for video devices
> to provide a centralized location for storing device state information.
> This includes the current (active) pixelformat used by the device and
> the temporary (try) pixelformat used during format negotiation.

I didn't look at the patch series yet, so I may be just jumping too
fast here, but storing "try" attempts doesn't seem the right thing to
do.

Btw, IMHO, the first patch on this series should be against documentation,
where you would be describing not only the new feature with the supported 
states, but also the state machine transitions that are supported,
preferably with some graphs.

So, before actually looking on any code changes, I'd like to see a clear
description of this new feature, what it is proposing to address, how
and what impacts (if any) this would bring to userspace.

The current diffstat:

 include/media/v4l2-ctrls.h                         |   5 +-
 include/media/v4l2-dev.h                           |  84 +++++
 include/media/v4l2-fh.h                            |   2 +
 include/media/v4l2-ioctl.h                         | 238 ++++++-------
 include/media/v4l2-mem2mem.h                       |  48 ++-
 include/media/videobuf2-v4l2.h                     |  33 +-

implies that this affects for now only Documentation/driver-api/media/...

> In the
> future, this may be extended or subclassed by device drivers to store
> their internal state variables.
> 
> Also introduce a flag for drivers that wish to use this state
> management. When set, the framework automatically allocates the state
> during device registration and stores a pointer to it within the
> video_device structure.
> 
> This change aligns video devices with V4L2 subdevices by storing
> hardware state in a common framework-allocated structure. This is the
> first step towards enabling the multiplexing of the underlying hardware
> by using different software "contexts", each represented by the combined
> state of all video devices and V4L2 subdevices in a complex media graph.

... but when you mention "contexts", I'm assuming that you're aiming
at either userspace API changes and/or behavoral changes that will
affect uAPI as well.

Thanks,
Mauro