Hi Hans,
We've misunderstood. When I was saying 'overengineered'
I did not mean your RFC.
I was taking about this:
#define V4L2_SEL_TGT_CROP_COMPOSE 0x0200
struct v4l2_selection {
__u32 type;
__u32 target;
__u32 flags;
union {
struct v4l2_rect r;
struct v4l2_ext_rect *pr;
};
__u32 flags2;
union {
struct v4l2_rect r2;
struct v4l2_ext_rect *pr2;
};
__u32 rectangles;
__u32 reserved[3];
};
This structure looks scary to me :).
>
> I disagree. I implemented it in vivi and it turned out to be quite easy.
>
> For the record: I'm talking about this RFC:
>
> http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/71822
>
>> I still does not solve problems with flipping and rotations, which may
>> have a huge impact on mulitrect cropping/composing limitations.
>
> My proposal will make that much easier as well since flipping, rotating,
> cropping and composing are all controls/properties that can be set
> atomically (a control cluster). So drivers can create a single function
> that can handle all the relationships in one place, and applications can
> set all of these with one VIDIOC_S_EXT_CTRLS call.
>
I think that your idea is quite good. Solve atomic configuration
in a different part of API (control cluster), not by making
properties larger.
As I said, there are multiple way to handle atomic configuration.
Using control API is one of them. Quite nice BTW :)
Regards,
Tomasz Stanislawski
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
