On 12/19/2013 02:30 PM, Tomasz Stanislawski wrote:
> 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 :).
Ah, yes. Implementing this as properties works much better.
And multi-selection can be done simply by making an array of crop and
compose rectangles.
Regards,
Hans
>
>>
>> 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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
