Hi Laurent On Thu, 29 Sep 2011, Laurent Pinchart wrote: > Hi Guennadi, > > On Thursday 29 September 2011 10:44:14 Guennadi Liakhovetski wrote: > > On Thu, 29 Sep 2011, Laurent Pinchart wrote: > > > On Thursday 29 September 2011 10:18:31 Guennadi Liakhovetski wrote: > > > > Drivers, that can be built and work with and without > > > > CONFIG_VIDEO_V4L2_SUBDEV_API, need the v4l2_subdev_get_try_format() and > > > > v4l2_subdev_get_try_crop() functions, even though their return value > > > > should never be dereferenced. Also add convenience macros to init and > > > > clean up subdevice internal media entities. > > > > > > Why don't you just make the drivers depend on > > > CONFIG_VIDEO_V4L2_SUBDEV_API ? They don't need to actually export a > > > device node to userspace, but they require the in-kernel API. > > > > Why? Why should the user build and load all the media controller stuff, > > buy all the in-kernel objects and code to never actually use it? Where > > OTOH all is needed to avoid that is a couple of NOP macros? > > Because the automatic compatibility layer that will translate video operations > to pad operations will need to access pads, so subdevs that implement a pad- > level API need to export it to the bridge, even if the bridge is not MC-aware. I might be missing something, but it seems to me, that if CONFIG_VIDEO_V4L2_SUBDEV_API is not defined, no pads are exported to the user space (and you mean a compatibility layer in the user space, don't you?), so, noone will be able to accesss them. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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
