Re: [PATCH] media: videodev2: add V4L2_FMT_FLAG_NO_SOURCE_CHANGE

[Maxime Jourdan]

Hi Tomasz,

On Tue, Oct 9, 2018 at 9:59 AM Tomasz Figa <tfiga@xxxxxxxxxxxx> wrote:
>
> Hi Maxime,
>
> On Thu, Oct 4, 2018 at 10:38 PM Maxime Jourdan <mjourdan@xxxxxxxxxxxx> wrote:
> >
> > When a v4l2 driver exposes V4L2_EVENT_SOURCE_CHANGE, some (usually
> > OUTPUT) formats may not be able to trigger this event.
> >
> > Add a enum_fmt format flag to tag those specific formats.
> >
> > Signed-off-by: Maxime Jourdan <mjourdan@xxxxxxxxxxxx>
> > ---
> >  Documentation/media/uapi/v4l/vidioc-enum-fmt.rst | 5 +++++
> >  include/uapi/linux/videodev2.h                   | 5 +++--
> >  2 files changed, 8 insertions(+), 2 deletions(-)
> >
> > diff --git a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> > index 019c513df217..e0040b36ac43 100644
> > --- a/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> > +++ b/Documentation/media/uapi/v4l/vidioc-enum-fmt.rst
> > @@ -116,6 +116,11 @@ one until ``EINVAL`` is returned.
> >        - This format is not native to the device but emulated through
> >         software (usually libv4l2), where possible try to use a native
> >         format instead for better performance.
> > +    * - ``V4L2_FMT_FLAG_NO_SOURCE_CHANGE``
> > +      - 0x0004
> > +      - The event ``V4L2_EVENT_SOURCE_CHANGE`` is not supported
> > +       for this format.
> > +
> >
> >
> >  Return Value
> > diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
> > index 3a65951ca51e..a28acee1cb52 100644
> > --- a/include/uapi/linux/videodev2.h
> > +++ b/include/uapi/linux/videodev2.h
> > @@ -723,8 +723,9 @@ struct v4l2_fmtdesc {
> >         __u32               reserved[4];
> >  };
> >
> > -#define V4L2_FMT_FLAG_COMPRESSED 0x0001
> > -#define V4L2_FMT_FLAG_EMULATED   0x0002
> > +#define V4L2_FMT_FLAG_COMPRESSED       0x0001
> > +#define V4L2_FMT_FLAG_EMULATED         0x0002
> > +#define V4L2_FMT_FLAG_NO_SOURCE_CHANGE 0x0004
>
> I think it indeed makes sense. I'd suggest submitting this patch
> together with the series that adds the affected driver, though, since
> we'd be otherwise just adding a dead API.
>
> Also, it would be good to refer to it from the Decoder Interface
> documentation. Depending on which one gets in earlier, you might
> either want to base on it or I'd add a note myself.
>
> Best regards,
> Tomasz

Agreed on both points. If your documentation makes it in before, I'll
update it within the patch. We'll have time to sync on that anyway in
the coming weeks.

Maxime