Hans Verkuil wrote: > On Thursday, March 24, 2011 08:28:31 Michael Jones wrote: >> Hi Laurent, >> >> On 03/23/2011 01:16 PM, Laurent Pinchart wrote: >>> Hi Michael, >>> >> [snip] >>>> >>>> Is there a policy decision that in the future, apps will be required to >>>> use libv4l to get images from the ISP? Are we not intending to support >>>> using e.g. media-ctl + some v4l2 app, as I'm currently doing during >>>> development? >>> >>> Apps should be able to use the V4L2 API directly. However, we can't implement >>> all that API, as most calls don't make sense for the OMA3 ISP driver. Which >>> calls need to be implemented is a grey area at the moment, as there's no >>> detailed semantics on how subdev-level configuration and video device >>> configuration should interact. > > We definitely need to discuss this in the near future. It's indeed a grey > area at the moment that needs to be clarified. I fully agree. >>> Your implementation of ENUM_FMT looks correct to me, but the question is >>> whether ENUM_FMT should be implemented. I don't think ENUM_FMT is a required >>> ioctl, so maybe v4l2src shouldn't depend on it. I'm interesting in getting >>> Hans' opinion on this. >>> >> >> I only implemented it after I saw that ENUM_FMT _was_ required by V4L2. >> From http://v4l2spec.bytesex.org/spec/x1859.htm#AEN1894 : >> "The VIDIOC_ENUM_FMT ioctl must be supported by all drivers exchanging >> image data with applications." > > If you can call S_FMT on a device node, then you also have to implement > ENUM_FMT. I think the issue here is that it's not possible (or feasible) to implement ENUM_FMT in a way applications would obtain the information they're interested in. Available pixel formats are dictated by the formats on links (validation must be done first in a generic case!) and in the case of OMAP 3 ISP there's always just one. S_FMT and TRY_FMT behave more or less the way applications like. The pixelformat or size may not change, though, and this information is also used to prepare the buffers. > I am assuming applications need to call S_FMT for omap3 video nodes, right? > Because that defines the result of the DMA engine. Or is the result always > fixed, based on the current pipeline configuration? In the latter case I > would still expect to see an ENUM_FMT, but one that just returns the current > format. And S/TRY_FMT would also return the current format. There are some options in the format that is not defined by the v4l2_mbus_pixelcode already. Padding is such and I don't think there should be anything else than that since the v4l2_mbus_pixelcode conversion and scaling takes places in the subdevs. Laurent? :-) Cheers, -- Sakari Ailus sakari.ailus@xxxxxxxxxxxxxxxxxxxxxxxxxx -- 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
