Hi all, On Tue, Feb 28, 2023 at 05:40:23PM +0200, Tomi Valkeinen wrote: > Add new ioctls to set and get subdev client capabilities. Client in this > context means the userspace application which opens the subdev device > node. > > For now we only add a single flag, V4L2_SUBDEV_CLIENT_CAP_STREAMS, which > indicates that the client is streams-aware. > > The reason for needing such a flag is as follows: > > Many structs passed via ioctls, e.g. struct v4l2_subdev_format, contain > reserved fields (usually a single array field). These reserved fields > can be used to extend the ioctl. The userspace is required to zero the > reserved fields. > > We recently added a new 'stream' field to many of these structs, and the > space for the field was taken from these reserved arrays. The assumption > was that these new 'stream' fields are always initialized to zero if the > userspace does not use them. This was a mistake, as, as mentioned above, > the userspace is required to zero the _reserved_ fields. In other words, > there is no requirement to zero this new stream field, and if the > userspace doesn't use the field (which is the case for all userspace > applications at the moment), the field may contain random data. > > This shows that the way the reserved fields are defined in v4l2 is, in > my opinion, somewhat broken, but there is nothing to do about that. > > To fix this issue we need a way for the userspace to tell the kernel > that the userspace has indeed set the 'stream' field, and it's fine for > the kernel to access it. This is achieved with the new iotcl, which the > userspace should usually use right after opening the subdev device node. > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen@xxxxxxxxxxxxxxxx> Any thoughts on this? I think this is ready to be merged. -- Regards, Sakari Ailus
