On 20/03/2023 10:15, Sakari Ailus wrote:
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).
I think this makes sense. I'll simplify the patch regarding this flag.
Tomi
