Hi Hans, On Mon, Dec 1, 2014 at 11:26 PM, Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> wrote: > Hi Prabhakar, > > On Sunday 30 November 2014 21:30:35 Prabhakar Lad wrote: >> On Sun, Nov 30, 2014 at 9:16 PM, Laurent Pinchart wrote: >> > On Sunday 30 November 2014 21:05:50 Prabhakar Lad wrote: >> >> On Sat, Nov 29, 2014 at 7:12 PM, Laurent Pinchart wrote: >> >> > Hi Prabhakar, >> >> >> >> [Snip] >> >> >> >>>>> Sure. That's a better choice than removing the config option >> >>>>> dependency of the fields struct v4l2_subdev. >> >>> >> >>> Decoupling CONFIG_VIDEO_V4L2_SUBDEV_API from the availability of the >> >>> in-kernel pad format and selection rectangles helpers is definitely a >> >>> good idea. I was thinking about decoupling the try format and >> >>> rectangles from v4l2_subdev_fh by creating a kind of configuration store >> >>> structure to store them, and embedding that structure in v4l2_subdev_fh. >> >>> The pad-level operations would then take a pointer to the configuration >> >>> store instead of the v4l2_subdev_fh. Bridge drivers that want to >> >>> implement TRY_FMT based on pad-level operations would create a >> >>> configuration store, use the pad-level operations, and destroy the >> >>> configuration store. The userspace subdev API would use the >> >>> configuration store from the file handle. >> >> >> >> are planning to work/post any time soon ? Or are you OK with suggestion >> >> from Hans ? >> > >> > I have no plan to work on that myself now, I was hoping you could >> > implement it ;-) >> >> OK will implement it. >> >> Can you please elaborate a more on this "The userspace subdev API would use >> the configuration store from the file handle." > > Basically, > > 1. Create a subdev pad configuration store structure to store the formats and > selection rectangles for each pad. > > 2. Embed an instance of that structure in v4l2_subdev_fh. > > 3. Modify the subdev pad ops to take a configuration store pointer instead of > a file handle pointer. > > The userspace API implementation (v4l2-subdev.c) would then pass &fh->store to > the pad operations instead of fh. > > Bridge drivers that need to implement TRY_FMT on top of pad ops would create a > temporary store (or temporary stores when multiple subsdevs are involved), > call the pad ops with a pointer to the temporary store to propagate TRY > formats, destroy the store(s) and return the resulting format. > > Is that clear ? > Yes thank you, I'll soon shoot a RFC version. Regards, --Prabhakar Lad -- 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