Re: extend v4l2_mbus_framefmt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed 20 June 2012 12:25:09 Sakari Ailus wrote:
> 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?

That's already supported for a long time. If the control flag V4L2_CTRL_FLAG_GRABBED
is set, then the control is marked busy.

There aren't many drivers that use this flag, but some do.

Regards,

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


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux