Hi Philipp, On Tue, Feb 21, 2017 at 09:50:23AM +0100, Philipp Zabel wrote: ... > > > Then there's the issue where, if you have this setup: > > > > > > camera --> csi2 receiver --> csi --> capture > > > > > > and the "csi" subdev can skip frames, you need to know (a) at the CSI > > > sink pad what the frame rate is of the source (b) what the desired > > > source pad frame rate is, so you can configure the frame skipping. > > > So, does the csi subdev have to walk back through the media graph > > > looking for the frame rate? Does the capture device have to walk back > > > through the media graph looking for some subdev to tell it what the > > > frame rate is - the capture device certainly can't go straight to the > > > sensor to get an answer to that question, because that bypasses the > > > effect of the CSI frame skipping (which will lower the frame rate.) > > > > > > IMHO, frame rate is just another format property, just like the > > > resolution and data format itself, and v4l2 should be treating it no > > > differently. > > > > > > > I agree, frame rate, if indicated/specified by both sides of a link, > > should match. So maybe this should be part of v4l2 link validation. > > > > This might be a good time to propose the following patch. > > I agree with Steve and Russell. I don't see why the (nominal) frame > interval should be handled differently than resolution, data format, and > colorspace information. I think it should just be propagated in the same > way, and there is no reason to have two connected pads set to a > different interval. That would make implementing the g/s_frame_interval > subdev calls mandatory. The vast majority of existing drivers do not implement them nor the user space expects having to set them. Making that mandatory would break existing user space. In addition, that does not belong to link validation either: link validation should only include static properties of the link that are required for correct hardware operation. Frame rate is not such property: hardware that supports the MC interface generally does not recognise such concept (with the exception of some sensors). Additionally, it is dynamic: the frame rate can change during streaming, making its validation at streamon time useless. -- Regards, Sakari Ailus e-mail: sakari.ailus@xxxxxx XMPP: sailus@xxxxxxxxxxxxxx _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
