[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1680188.7K1XCBdsCk@avalon>
Date: Sun, 30 Nov 2014 23:16:48 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Prabhakar Lad <prabhakar.csengg@...il.com>
Cc: Hans Verkuil <hverkuil@...all.nl>,
linux-media <linux-media@...r.kernel.org>,
Hans Verkuil <hans.verkuil@...co.com>,
Sakari Ailus <sakari.ailus@...ux.intel.com>,
LKML <linux-kernel@...r.kernel.org>,
Sakari Ailus <sakari.ailus@....fi>
Subject: Re: [PATCH] media: v4l2-subdev.h: drop the guard CONFIG_VIDEO_V4L2_SUBDEV_API for v4l2_subdev_get_try_*()
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
;-)
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists