Re: [PATCH] V4L: add convenience macros to the subdevice / Media Controller API

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

 



Hi Guennadi,

On Tuesday 06 December 2011 13:04:00 Guennadi Liakhovetski wrote:
> On Tue, 6 Dec 2011, Laurent Pinchart wrote:
> > On Tuesday 06 December 2011 09:40:41 Guennadi Liakhovetski wrote:
> > > On Thu, 29 Sep 2011, Laurent Pinchart wrote:
> > > > 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.
> > 
> > No, I meant a compatibility layer in kernel space. Basically something
> > like (totally untested)
> 
> Aha, so, a "future" layer.
> 
> > int v4l2_subdev_get_mbus_format(struct v4l2_subdev *sd, struct
> > v4l2_mbus_framefmt *format)
> > {
> > 
> > 	struct v4l2_subdev_format fmt;
> > 	int ret;
> > 	
> > 	ret = v4l2_subdev_call(sd, video, g_mbus_fmt, format);
> > 	if (ret != ENOIOCTLCMD)
> 
> you mean "-E..."
> 
> > 		return ret;
> > 	
> > 	fmt.pad = 0;
> > 	fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
> > 	fmt.format = *format;
> > 	
> > 	ret = v4l2_subdev_call(sd, pad, get_fmt, NULL, &fmt);
> > 	if (ret < 0 && ret != ENOIOCTLCMD)
> 
> You, probably, actually mean "if (!ret)"
> 
> > 		*format = fmt.format;
> > 	
> > 	return ret;
> > 
> > }
> > 
> > Or the other way around, trying pad::get_fmt before video::g_mbus_fmt.
> 
> Ok, I understand what you mean now. Any idea when this layer is going to
> be implemented?

As soon as someone needs it and works on it I guess :-) I can give it a try, 
but I'm pretty busy at the moment. Do you have driver(s) that would be good 
test candidates for that ?

-- 
Regards,

Laurent Pinchart
--
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