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
