Hi Laurent,
On Sun, Mar 19, 2023 at 04:40:37PM +0200, Laurent Pinchart wrote:
> > >> diff --git a/include/uapi/linux/v4l2-subdev.h b/include/uapi/linux/v4l2-subdev.h
> > >> index 654d659de835..9f863240a458 100644
> > >> --- a/include/uapi/linux/v4l2-subdev.h
> > >> +++ b/include/uapi/linux/v4l2-subdev.h
> > >> @@ -233,6 +233,26 @@ struct v4l2_subdev_routing {
> > >> __u32 reserved[6];
> > >> };
> > >>
> > >> +/*
> > >> + * The client is aware of streams. Setting this flag enables the use of streams
> > >> + * and routing related ioctls and fields. If this is not set (which is the
> > >> + * default), all the 'stream' fields referring to the stream number will be
> > >> + * forced to 0 by the kernel, and routing related ioctls will return
> > >> + * -ENOIOCTLCMD.
> > >
> > > Do we need the latter ? Surely if userspace calls routing ioctls, it
> > > should be stream-aware.
> >
> > I think it makes the API more consistent. I don't think there's much use
> > for the routing ioctls without the stream field.
> >
> > I guess it depends on what V4L2_SUBDEV_CLIENT_CAP_STREAMS means. I
> > thought it means "client wants to use streams", but if we define it to
> > mean "client is aware of streams and has cleared the 'stream' fields",
> > then we can only do the field clearing.
>
> I would go for the second option, as that's the need we have at the
> moment, ensuring backward compatibility with the introduction of the
> streams field.
I'd prefer this, too. Defining it clearly what this actually means is
better as is configuring exactly what's needed --- in order to make it
easier to avoid passing garbage both ways between the user and the kernel
(where it may be a security issue as well).
--
Kind regards,
Sakari Ailus
