>>>>> 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. -- 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