| Message ID | 20240401233725.2401-1-laurent.pinchart@ideasonboard.com |
|---|---|
| State | Accepted |
| Commit | 34d7bf1c8e59f5fbf438ee32c96389ebe41ca2e8 |
| Headers | show |
| Series | media: v4l2-subdev: Fix stream handling for crop API | expand |
On 02/04/2024 23:11, Laurent Pinchart wrote: > On Tue, Apr 02, 2024 at 03:23:03PM +0000, Sakari Ailus wrote: >> 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. :-) > > I tend to agree, even if that's only a slight preference. Tomi, if > you're fine with this, I'll update the patch. I'm fine with it. So we now should move the 'stream' field back to reserved, and add documentation saying that [GS]_CROP works differently than the other ioctls? Tomi
diff --git a/drivers/media/v4l2-core/v4l2-subdev.c b/drivers/media/v4l2-core/v4l2-subdev.c index 4c6198c48dd6..45836f0a2b0a 100644 --- a/drivers/media/v4l2-core/v4l2-subdev.c +++ b/drivers/media/v4l2-core/v4l2-subdev.c @@ -732,6 +732,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg, memset(&sel, 0, sizeof(sel)); sel.which = crop->which; sel.pad = crop->pad; + sel.stream = crop->stream; sel.target = V4L2_SEL_TGT_CROP; rval = v4l2_subdev_call( @@ -756,6 +757,7 @@ static long subdev_do_ioctl(struct file *file, unsigned int cmd, void *arg, memset(&sel, 0, sizeof(sel)); sel.which = crop->which; sel.pad = crop->pad; + sel.stream = crop->stream; sel.target = V4L2_SEL_TGT_CROP; sel.r = crop->rect;
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. Fixes: 2f91e10ee6fd ("media: subdev: add stream based configuration") Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> --- drivers/media/v4l2-core/v4l2-subdev.c | 2 ++ 1 file changed, 2 insertions(+) base-commit: 39cd87c4eb2b893354f3b850f916353f2658ae6f