Hi
>I am sending this again because apparently I sent it originally from my
>personal email by mistake.
>
>---------------
>
>
>Hi Hans!
>
>I have been working on testing this lately as you know.
>
> From the example you've added to vivid, i.e.:
>
>+static const struct v4l2_ctrl_config vivid_ctrl_u32_dyn_array = {
>+ .ops = &vivid_user_gen_ctrl_ops,
>+ .id = VIVID_CID_U32_DYN_ARRAY,
>+ .name = "U32 Dynamic Array",
>+ .type = V4L2_CTRL_TYPE_U32,
>+ .flags = V4L2_CTRL_FLAG_DYNAMIC_ARRAY,
>+ .def = 50,
>+ .min = 10,
>+ .max = 90,
>+ .step = 1,
>+ .dims = { 100 },
>+};
>+
>
>+ v4l2_ctrl_new_custom(hdl_user_gen, &vivid_ctrl_u32_dyn_array, NULL);
>
>
>I was under the impression that it'd be enough to pass the id and
>V4L2_CTRL_FLAG_DYNAMIC_ARRAY in the config before calling
>v4l2_ctrl_new_custom. Apparently that's not the case though, because
>v4l2_ctrl_fill will then set its own flags if I understood correctly, i.e.:
>
>
> if (name == NULL)
> v4l2_ctrl_fill(cfg->id, &name, &type, &min, &max, &step,
> &def,&flags)
>
><snip>
>
> *name = v4l2_ctrl_get_name(id);
> *flags = 0
>
>
><snip>
Yeah - I spotted that too. Its not too hard to write a full config but
it would be nicer not to.
>To be honest, I didn't quite understand whether you wanted individual
>drivers to signal they want to treat a given control as a dynamic array
>or whether I should add that flag in the switch statement in
>v4l2_ctrl_fill, thereby enabling this feature by default for all drivers
>that use that control if I understood correctly.
>
>If the former, I was expecting to communicate it to userspace via a menu
>control, e.g. for h264 and cedrus:
>
>enum v4l2_stateless_h264_decode_mode {
> V4L2_STATELESS_H264_DECODE_MODE_SLICE_BASED, /* i.e. a single
>slice per request */
> V4L2_STATELESS_H264_DECODE_MODE_FRAME_BASED,
>+ V4L2_STATELESS_H264_DECODE_MODE_SLICE_ARRAY_BASED, /* i.e. an array
>of slices per request */
> };
>
>@@ -56,6 +56,7 @@ static const struct cedrus_control cedrus_controls[] = {
> {
> .cfg = {
> .id = V4L2_CID_STATELESS_H264_SLICE_PARAMS,
>+ .flags = V4L2_CTRL_FLAG_DYNAMIC_ARRAY,
> },
> .codec = CEDRUS_CODEC_H264,
> },
>@@ -86,7 +87,7 @@ static const struct cedrus_control cedrus_controls[] = {
> {
> .cfg = {
> .id = V4L2_CID_STATELESS_H264_DECODE_MODE,
>- .max = V4L2_STATELESS_H264_DECODE_MODE_SLICE_BASED,
>+ .max = V4L2_STATELESS_H264_DECODE_MODE_SLICE_ARRAY_BASED,
> .def = V4L2_STATELESS_H264_DECODE_MODE_SLICE_BASED,
> },
> .codec = CEDRUS_CODEC_H264,
My test code (for ffmpeg & the rpi H265 decoder) used the same ID and
the caller tested to see if V4L2_CTRL_FLAG_DYNAMIC_ARRAY was set on the
control. If it was then it sent slice headers in a block otherwise it
sent them one at a time and as it happens the driver will work just fine
if the array control is used to send slices in (say) groups of 16. This
worked well for me, and was the simplest coding solution, as I had to
cope with both cases at both ends anyway. This probably isn't "the V4L2
way" though
Regards
John Cox
