Hi Peter, On Mon, Jul 21, 2014 at 02:35:39PM +0200, Peter Meerwald wrote: > how can I query the supported pixel format(s) of a sensor connected via > media-ctl and exposed via /dev/videoX > > there is > VIDIOC_ENUM_FMT (which fails) > and > VIDIOC_SUBDEV_ENUM_MBUS_CODE (which works, but on a subdev, not on > /dev/videoX) > > v4l2_subdev_video_ops has .enum_mbus_fmt (this is SoC camera stuff?) > > v4l2_subdev_pad_ops has .enum_mbus_code > > > the application just sees /dev/videoX and cannot do VIDIOC_ENUM_FMT > what is the logic behind this? > shouldn't a compabatibility layer be added turning VIDIOC_ENUM_FMT into > VIDIOC_SUBDEV_ENUM_MBUS_CODE? The issue has been that enumerating should not change the state of the device. Within a single device node things are fine, but in this case the media bus pixel code at the other end of the link affects the result of the enumeration. There hasn't been really a solution for this in the past; what has been discussed as possible options have been (at least to my recollection) but none has been implemented: 1) Use the media bux pixel code from the other end of the link. As there is no common file handle to share the state with, the link configuration and setting the media bus pixel code are necessary state changes before the enumeration can take place, and the two must not be changed during the it. This breaks the separation between configuration and enumeration. (There has been a patch to the omap3isp driver which essentially did this long time ago AFAIR.) 2) Use a reserved field in struct v4l2_fmtdesc to tell the pixel code. This way enumeration can stay separate from configuration and is probably easier for the user space as well. I vote for this: it's clean, simple and gets the job done. Feel free to submit a patch. :-) I could do this as well but it might take some time. Driver support is another matter. -- Kind regards, Sakari Ailus e-mail: sakari.ailus@xxxxxx XMPP: sailus@xxxxxxxxxxxxxx -- 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
