Hi Ricardo,
On Fri, Sep 06, 2013 at 10:30:18AM +0200, Ricardo Ribalda Delgado wrote:
> Hi Sylvester
>
> Thanks for your response
>
> Unfortunately, the v4l2_crop dont have any reserved field :(
Don't worry about v4lw_crop. we have selections now. :-)
> struct v4l2_crop {
> __u32 type; /* enum v4l2_buf_type */
> struct v4l2_rect c;
> };
>
> And changing that ABI I dont think is an option.
>
> What about a new call: G/S_READOUT .that uses a modified
> v4l2_selection as you propose?
Could this functionality be added to the ex$sting selection API, with a
possible extension in a for of a new field, say, "id" to tell which one is
being changed?
> That call selects the readable areas from the sensor.
>
> The new structure could be something like:
>
> #define SELECTION_BITMAP 0xffffffff
> #define SELECTION_RESET 0xfffffffe
> #define SELECTION_MAX_AREAS 32
> struct v4l2_selection {
> __u32 type;
> __u32 target;
> __u32 flags;
> union {
> struct v4l2_rect r;
> __u32 bitmap;
> };
> __u32 n;
> __u32 reserved[8];
> };
>
> n chooses the readout area to choose, up to 32.
>
> When n is == 0xffffffff the user wants to change the bitmap that
> selects which areas are enabled.
> When the bitmap is 0x0 all the sensor is read.
> When the bitmap is 0x5 the readout area 0 and 2 are enabled.
>
> When the bitmap is set to a value !=0, the driver checks if the
> combination of readout areas is supported by the sensor/readout logic
> and returns -EINVAL if not.
>
> The g/s_crop API still works as usual.
>
> Any comment on this? Of course the names should be better chosen, this
> is just a declaration of intentions.
I think the functionality you're describing is highly peculiar. I have to
say that, as Sylwester noted, it bears resemblance to the AF windows so the
solution could be same as well.
I think earlier on (say perhaps a year and a half) ago it was proposed to
use bitmask controls with selections to tell which IDs are valid. What would
you think about that?
It's also always possible to use private controls, too.
--
Kind regards,
Sakari Ailus
e-mail: sakari.ailus@xxxxxx XMPP: sailus@xxxxxxxxxxxxxx
--
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
