Moi, On Tue, Apr 02, 2024 at 12:11:30PM +0300, Tomi Valkeinen wrote: > On 02/04/2024 11:46, Sakari Ailus wrote: > > On Tue, Apr 02, 2024 at 11:44:07AM +0300, Laurent Pinchart wrote: > > > On Tue, Apr 02, 2024 at 08:20:22AM +0000, Sakari Ailus wrote: > > > > Moi, > > > > > > > > On Tue, Apr 02, 2024 at 02:37:25AM +0300, Laurent Pinchart wrote: > > > > > When support for streams was added to the V4L2 subdev API, the > > > > > v4l2_subdev_crop structure was extended with a stream field, but the > > > > > field was not handled in the core code that translates the > > > > > VIDIOC_SUBDEV_[GS]_CROP ioctls to the selection API. Fix it. > > > > > > > > The field is indeed in the UAPI headers. But do we want to support the CROP > > > > IOCTL for streams? Shouldn't the callers be using the [GS]_SELECTION > > > > instead? > > > > > > They should, but if the field is there, we should support it :-) The > > > alternative is to remove it. It will cause failures in v4l2-compliance > > > that we'll need to handle though. > > > > I'd prefer to stick to selections here, this is new functionality so > > [GS]_CROP support isn't required. I don't have a strong opinion on the > > matter though. > > Maybe it's easier to just support the stream field, instead of making > [GS]_CROP the odd case which looks like it should support streams, but then > doesn't... It's an old IOCTL already replaced by the [GS]_SELECTION. I mainly write kernel space software but overall I think it's better if we can provide a single API for controlling cropping instead of two with similar functionality, of which the user then should choose from. It should be also documented in this context if we choose support [GS]_CROP. So I believe we have less work to do and have a better result if we just drop the stream field there. :-) -- Terveisin, Sakari Ailus
