>> >> > 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.
Thanks, Scott -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
