Thanks, Vaibhav Hiremath
> > > > APPROACH 3 - > > ---------- > > > > ..... > > > > (Any other approach which I could not think of would be > appreciated) > > > > > > I would prefer second approach, since this will provide standard > > interface to applications independent on underneath hardware. > > > > There may be many number of such configuration parameters required > for > > different such devices, we need to work on this and come up with > some > > standard capability fields covering most of available devices. > > > > Does anybody have some other opinions on this? > > Any suggestions will be helpful here, > > FYI: I have very little time to look at this for the next 2-3 weeks. > As you > know I'm working on the last pieces of the v4l2_subdev conversion > for 2.6.30 > that should be finished this week. After that I'm attending the > Embedded > Linux Conference in San Francisco. > > But I always thought that something like this would be just a > regular video > device that can do both 'output' and 'capture'. For a resizer I > would > expect that you set the 'output' size (the size of your source > image) and > the 'capture' size (the size of the resized image), then just send > the > frames to the device (== resizer) and get them back on the capture > side. > [Hiremath, Vaibhav] Yes, it is possible to do that. Hans, I went through the link referred by Sergio and I think we should inherit some implementation for CODECs here for such devices. V4L2_BUF_TYPE_CODECIN - To access the input format. V4L2_BUF_TYPE_CODECOUT - To access the output format. It makes sense, since such memory-to-memory devices will mostly being used from codecs context. And this would be more clear from user application. And as acknowledged by you, we can use VIDIOC_S_FMT for setting parameters. One thing I am not able to convince myself is that, using "priv" field for custom configuration. I would prefer and recommend capability based interface, where application will query the capability of the device for luma enhancement, filter coefficients (number of coeff and depth), interpolation type, etc... This way we can make sure that, any such future devices can be adapted by this framework. Hans, Have you get a chance to look at Video-Buf layer issues I mentioned in original draft? > Regards, > > Hans > > -- > Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
