Hi Scott,
Scott Jiang wrote:
I would expect that the combination of v4l2_mbus_framefmt +
v4l2_dv_timings
gives you the information you need.
I can solve this problem in HD, but how about SD? Add a fake
dv_timings ops in SD decoder driver?
No, you add g/s_std instead. SD timings are set through that API. It is
not so
much that you give explicit timings, but that you give the SD standard.
And from
that you can derive the timings (i.e., one for 60 Hz formats, and one for
50 Hz
formats).
Yes, it's a solution for decoder. I can convert one by one. But how
about sensors?They can output VGA, QVGA or any manual resolution.
My question is why we can't add these blanking details in
v4l2_mbus_framefmt? This structure is used to describe frame format on
media bus. And I believe blanking data also transfer on this bus. I
know most hardwares don't care about blanking areas, but some hardware
such as PPI does. PPI can capture ancillary data both in herizontal
and vertical interval. Even it works in active video only mode, it
expects to get total timing info.
Since I don't know what you are trying to do, it is hard for me to give
a good answer.
So first I'd like to know if this is related to the adv7842 chip? I think
you are talking about how this is done in general, and not specifically in
relationship to the adv7842. At least, I can't see how/why you would
hook up a sensor to the adv7842.
Yes, I want to have a general solution.
Sensor configuration is a separate topic, and something I am not an
expert on. People like Sakari Ailus and Laurent Pinchart know much
more about that than I do.
I know that there is some support for blanking through low-level image
source
controls:
http://hverkuil.home.xs4all.nl/spec/media.html#image-source-controls
This is experimental and if this is insufficient for your requirements than
I suggest posting a message where you explain what you need, CC-ing the
people
I mentioned,
Most of these APIs are quite new and by marking them as experimental we can
make changes later if it turns out it is not good enough.
I remember I have discussed this topic with Sakari before but without
working out a solution.
In conclusion, my current solution is:
if (HD)
dv_timings
else if (SD)
fill in according to PAL/NTSC timings
else
get control of V4L2_CID_HBLANK/V4L2_CID_VBLANK
I guess this can solve my problem. But it's a bit complicated. If
v4l2_mbus_framefmt contains thes members, it's convenient and simple.
Adding horizontal and vertical blanking as fields to struct
v4l2_mbus_framefmt was discussed long ago --- I even sent a patch doing
that AFAIR. It'd have been a simple solution, yes. The resulting
discussion concluded, however, that as the horizontal or vertical
blanking are not really a property of the image format, and generally
only affect timing (frame rate, they do not belong to this struct.
Also changing them while streaming is almost always possible (except in
your case, I believe) whereas the rest of the fields are considered
static. It'd be difficult for the user to know which fields can be
actually changed while streamon, and which can't.
For these reasons (AFAIR) we chose to use controls instead.
I think the right solution to the problem when it comes to sensors, is
to mark these controls busy from the bridge driver if the bridge
hardware can't cope with changes in blanking. The control framework
doesn't support this currently but it might not be that much of work to
implement it. Such feature would definitely have to be used with care.
Hans, what do you think?
Kind regards,
--
Sakari Ailus
sakari.ailus@xxxxxx
--
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
